Yeah the pushed client reg draft doesn't change the underlying trust model of the client registration data from DCR. Whereas the client ID metadata documents at least anchors the client reg data against a URL. So realistically I expect them to be used in totally different applications.
IMO Pushed Client Registration would be a better option for the email community that presented an OAuth profile during the last IETF using DCR. DCR has its own challenges of how to manage stale client IDs, which PCR avoids by treating all the data as ephemeral anyway. On Fri, Jun 27, 2025 at 9:39 AM Justin Richer <[email protected]> wrote: > Yeah, I can see that - any time you have to fetch information you’ve got a > whole separate layer of trust that’s sometimes just implied by the system: > trust in webpki, trust in domain ownership, etc. But you can argue that as > an HTTP centric protocol, OAuth inherits all of that anyway. > > All that said, my pushed-data draft and the pull-based draft Aaron’s got > are complementary to each other, in that they work for different target > spaces and in different trust restrictions. I could easily see a highly > dynamic system doing both (and even offering the more classical DynReg > approach, too). > > — Justin > > On Jun 27, 2025, at 8:56 AM, emelia <[email protected]> wrote: > > Yeah, two things we've been trying to figure out with Client ID Metadata > Documents are: > > - How long should the AS cache the Client ID Metadata Document? > > - How can the Client ID Metadata Document indicate to the AS that it is > not a long-lived client / ephemeral (e.g., a client used for development > purposes that isn't necessarily needed long-term) > > So far I haven't had any great answers to either of these two questions. > Maybe using the `Expires` header on the Client ID Metadata Document > response? I'm not sure. I think I like the idea of adding a maxAge or > expiresAt property to the Client Metadata to allow the client to signal to > the AS when the client is no longer needed. > > [1] > https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/3 > [2] > https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/pull/35 > / > https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/pull/29 > <https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/pull/29/files> > > — Emelia > > On 27 Jun 2025, at 14:37, Justin Richer <[email protected]> wrote: > > I like the idea of that if this goes forward. It all depends on how the > method of storing client info works. If it’s associated with just the > issued access tokens, then it gets collected when the tokens themselves > expire and are expunged. If it’s held separately, like a lot of existing > OAuth deployments do with registered clients, then it’s going to need some > key to kick it out. > > From a protocol perspective, it’s important that the client doesn’t need > to know or store any client identifier for this to work. But you’re right > that it would be helpful to give implementation guidance to the AS side as > well. When I was playing around with an implementation, I effectively had a > secondary client storage service for this path, and that would be purged > once the token was issued. > > — Justin > > On Jun 26, 2025, at 8:13 PM, emelia <[email protected]> wrote: > > Hi Justin, > > This sounds reasonable, though would it be wise to introduce a new "client > type" of "ephemeral", so you've like public clients, confidential clients > and ephemeral clients? > > That way your AS can know it can garbage collect that temporary client? > > Perhaps adding to registration data a property like maxAge or something > too? > > Yours > Emelia > > On 26. Jun 2025, at 23:12, Justin Richer <[email protected]> wrote: > > > I’ve been seeing a lot of recent conversations trying to work around the > limitations of OAuth needing a client_id as part of the syntax of the > protocol. This is especially pertinent with proxy protocols like MCP, in > which the client could be very ephemeral and have no real way to establish > itself with the AS ahead of time. Dynamic Client Registration does work, of > course, as do public clients — but both of these have their limitations. > With DynReg, you end up with a client_id that might never get used again. > With public clients, you still require a pre-registration but don’t really > get the security benefits of registration. And for a highly dynamic system, > the pre-registration doesn’t make sense. There are other approaches like > having the AS fetch the client’s info from a URL, but that assumes the > client can host something accessible to the AS and the AS is protected > against SSRF attacks. > > After talking through some ideas with Aaron, we came up with a pattern > that leverages PAR and the authz code flow to allow a client to push its > registration information as part of the PAR request and continue the OAuth > process using a stand-in client identifier for syntactical compatibility. > > > https://www.ietf.org/archive/id/draft-richer-oauth-pushed-client-registration-00.html > > The short version of the process goes like this: > > 1. Client makes a PAR request with a special client_id value to trigger > this (we’ll use “dynamic” in the example but it’s a fixed string that’s > always the same for all clients). The request includes its redirect URI and > optionally any other DynReg client metadata, and can also include any keys > and challenges for PKCE and client auth > 2. AS returns a request_uri like normal PAR, but this creates an internal > transaction that is bound to the parameters sent in (1) > 3. Client calls the authz endpoint with the request_uri and the special > client_id value, “dynamic” > 4. AS loads the configuration based on the request_uri and processes the > request as usual > 5. AS returns the “code” and anything else relevant, as usual > 6. Client calls the token endpoint with the code, PKCE verifier, proof of > its keys from (1), and the client_id value of “dynamic”; could include a > DPoP/MTLS proof too > 7. AS loads the approved request from the “code” value and processes it as > usual > 8. AS returns a token as usual > 9. Client uses the token as usual > > > While it was MCP that brought this up, the pattern also shows up in other > places like connecting instances of an email client to instances of an > email server. > > I’d like to get some time on the agenda for Madrid to discuss this draft > in greater detail. > > — Justin > _______________________________________________ > 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] > > > > _______________________________________________ > 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]
