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 <jric...@mit.edu> 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 <eme...@brandedcode.com> 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 <jric...@mit.edu> 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 -- oauth@ietf.org >>> To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
