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 <eme...@brandedcode.com> 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 <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
