Thanks John I suppose you could setup a kind of a backchannel between SPIFFE issuers and OAuth authorization servers. One reason I would be hesitant about that is latency and consistency in these very large distributed environments spread out across many data centers around the world. You really want to avoid data synchronisation problems in these large scale environments, and given the dynamic nature of these workloads, it is simpler to just have the workload "registered" with the Oauth when it shows up at the AS. That way there is one less thing you need to worry about keeping in sync, and one less point of failure. It's a resiliency thing.
As for implicit vs dynamic - perhaps the word we are looking for is automatic. The main thing is we don't want manual steps in this process, especially if some other issuer already attested and credentialed a workload/client. Cheers Pieter On Thu, Jun 26, 2025 at 3:55 PM stable.pseudonym <stable.pseudo...@gmail.com> wrote: > Thanks Pieter, > > In reading the client registration with SPIFFE draft, I believe that this > is not as much "dynamic client registration" (as described in that doc) but > "implicit client registration", where registration of the client has taken > place prior to the client contacting the AS, and has been performed by some > entity (a SPIFFE server) trusted well-enough by the AS that the AS may > proceed to authorize the client based on that prior registration. > > In which case, why does the client need to be involved in the registration > at all? Would it not be possible for the SPIFFE server to inform the AS of > the new client, prior to the client contacting the AS? Have I understood > this correctly? > > Cheers, -johnk > > Sent from my Galaxy > > > -------- Original message -------- > From: Pieter Kasselman <pie...@spirl.com> > Date: 6/25/25 07:20 (GMT-05:00) > To: oauth <oauth@ietf.org>, Ismael Kazzouzi <ism...@spirl.com>, > dag...@signicat.com > Subject: [OAUTH-WG] Simplify Client Registration with SPIFFE > > 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 -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
