Hi Dick, thanks for the questions. > If I am reading the oauth-spiffe draft correctly, the AS must have a pre-existing relationship with the SPIFFE Issuer, correct?
Yes, the AS has to trust the SPIFFE Issuer, and for the purposes of this draft, it is pre-configured (or at least, out of scope of this draft, we wanted to focus on registration first) This is what we see most commonly, at least at the moment. I can envision that in the future there are mechanisms for a more dynamic way to setup and configure trust, but that is probably a separate draft in itself. I am interested to hear about options to do this "trust establishment" more dynamically, especially if this is something others are interested in as well. > Assuming that is correct, it looks to me like the advantage of SPIFFE is abstracting key management for clients out of the AS. Am I understanding this correctly? Yes, it externalises the task of identifying clients (through attestation) and then lifecycle management of credentials (X.509 and JWT) from the AS. As you point out, a big benefit is that it removes the need for client secret management (and helps contain the disastrous proliferation of secrets every enterprise is trying to deal with at the moment in an automated fashion). Cheers Pieter On Wed, Jun 25, 2025 at 7:11 PM Dick Hardt <[email protected]> wrote: > Hey Pieter > > If I am reading the oauth-spiffe draft correctly, the AS must have a > pre-existing relationship with the SPIFFE Issuer, correct? > > Assuming that is correct, it looks to me like the advantage of SPIFFE is > abstracting key management for clients out of the AS. Am I understanding > this correctly? > > On Wed, Jun 25, 2025 at 4:20 AM Pieter Kasselman <[email protected]> wrote: > >> Hi fellow OAuth Working Group members >> >> Below are two individual drafts that explore ways to simplify OAuth >> client registration (and as a bonus avoid proliferating client secrets). >> >> The drafts were inspired by a post from Dmitry Telegin that described the >> idea of using SPIFFE credentials to simplify client registration while >> simultaneously avoiding the need for client secrets [2] and in parallel >> renewed interest in using Dynamic Client Registration with protocols like >> the model Context Protocol (MCP) [3]. >> >> Taking inspiration from these ideas, and discussion, we prepared two >> drafts to start a conversation on ways to simplify client registration in >> dynamic, rapidly scaling, environments with an additional benefit of >> avoiding additional secret proliferation while leveraging existing deployed >> infrastructure. It is conceivable that these concepts can be generalised to >> other workload credentialing systems that are widely deployed, or may be >> deployed in the future. >> >> 1. OAuth Client Registration on First Use with SPIFFE: >> https://datatracker.ietf.org/doc/draft-kasselman-oauth-spiffe/ >> 2. OAuth 2.0 Dynamic Client Registration with Trusted Issuer Credentials: >> >> https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-issuer-token/ >> >> We are looking forward to hearing from others that are exploring ways to >> simplify client registration. >> >> Pieter, Dag and Ismael >> >> [1] https://datatracker.ietf.org/doc/html/rfc7591 >> [2] >> https://mailarchive.ietf.org/arch/msg/oauth/XHjZCP0H14QLsPoiCGnptTKmNp4/ >> [3] >> https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#dynamic-client-registration >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
