Thanks Dag,I understand the benefits of doing this, but what is strange to me is that in the current dynamic client registration, the client goes a specific registration URL at the AS *prior* to doing the AuthZ request. In this SPIFFE registration case, the "client" has first been registered via SPIFFE with an entity trusted by the AS. This MUST have happened, because the client has an SVID. I believe that having a separate registration URL and authZ URL allows for better security. But with prior SPIFFE registration, equivalent (or better) security is possible, and a second registration can be skipped if these entities trust each other.I am not a fan of (for example) the client passing in redirect URLs for redirect flows as part of the authZ request itself. They should be pre-registered, even if it's immediately before the authZ protocol needs to use them.I think in this proposal, the SVID should be thought of as equivalent to the client ID, and the client can be considered pre-registered, or implicitly registered because of prior SPIFFE registration.-johnkSent from my Galaxy -------- Original message --------From: Dag Sneeggen <dag.sneeg...@signicat.com> Date: 6/26/25 11:12 (GMT-05:00) To: "stable.pseudonym" <stable.pseudo...@gmail.com>, Pieter Kasselman <pie...@spirl.com>, oauth <oauth@ietf.org>, Ismael Kazzouzi <ism...@spirl.com> Subject: Re: [OAUTH-WG] Simplify Client Registration with SPIFFE
IMO what're describing is a totally valid and probably common use case, but it is slightly different than what we focus on here. The advantage of the first use register is that you only create an oauth client when it's needed. With SPIFFE you can have hundreds of shortlived workloads being created and deleted. It's not a given that all of them need an oauth client. Or longlived workloads might not need an oauth client for their whole life span, or they need multiple. Here we essentially propose 1) on-demand automated client lifecycle management. 2) mitigating secret sprawl by leveraging spiffe credentials. Sent from Outlook for Android From: stable.pseudonym <stable.pseudo...@gmail.com> Sent: Thursday, June 26, 2025 4:55:06 PM To: Pieter Kasselman <pie...@spirl.com>; oauth <oauth@ietf.org>; Ismael Kazzouzi <ism...@spirl.com>; Dag Sneeggen <dag.sneeg...@signicat.com> Subject: RE: [OAUTH-WG] Simplify Client Registration with SPIFFE You don't often get email from stable.pseudo...@gmail.com. Learn why this is important 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
