It's a really interesting idea. Thanks Filip for the slides as well! > (1) do gradual rollouts of AS metadata changes client by client
I 100% see the value in better-supporting gradual rollouts. Today, an AS can try *(emphasis on try!)* to feature flag responses based on IP address or User-Agent but both of those are *very* poor signals. > (2) customize metadata if necessary I am not a fan of long-lived customizations of metadata to support legacy clients, though I understand gradual rollouts and long-lived legacy flags are two sides of the same coin. I know it is not always possible or reasonable, but I would rather break old, insecure, and unmaintained clients than build tools to accommodate them. The security considerations could be worrisome; you call out that an attacker could enumerate which legacy features an AS still supports for a given client. This differs from observing that client's behavior—a client might remove the use of the `implicit` grant from their flow, but still be permitted by the AS to use it for legacy reasons. Using this endpoint, an attacker could determine that fact and attempt to exploit it. On Mon, May 18, 2026 at 10:08 AM Andy Barlow <[email protected]> wrote: > I fully support any and all effort on this topic. > > On Mon, 18 May 2026 at 17:58, Filip Skokan <[email protected]> wrote: > >> Hello Nick, >> >> Let me know what you all think. >> >> >> Back at IETF 121 I presented this related/similar idea: >> >> - https://youtu.be/_kNpecjcj64?t=6354 >> - >> >> https://datatracker.ietf.org/meeting/121/materials/slides-121-oauth-sessa-client-id-hint-for-authorization-server-metadata-requests-00 >> >> I haven't had a chance to follow up on it since >> >> S pozdravem, >> *Filip Skokan* >> >> >> On Mon, 18 May 2026 at 17:09, Nick Watson <nwatson= >> [email protected]> wrote: >> >>> >>> https://njwatson32.github.io/as-metadata-client-id/draft-watson-oauth-as-metadata-client-id.html >>> >>> I've written up a quick draft on supporting a client_id parameter on AS >>> Metadata, which would allow the AS to (1) do gradual rollouts of AS >>> metadata changes client by client and (2) customize metadata if necessary >>> (e.g. for clients participating in beta programs of upcoming drafts). >>> >>> AS can also choose to ignore the client_id parameter completely and >>> continue serving a statically cached global AS metadata file. >>> >>> I had this idea recently when implementing support for 9207 (iss >>> parameter) and running into poorly behaved clients handling these updates >>> badly. The draft I'm proposing would have allowed me to avoid making global >>> changes to AS metadata, and even do a synchronized rollout of returning >>> `iss` from the authorization endpoint and >>> declaring authorization_response_iss_parameter_supported. >>> >>> Let me know what you all think. >>> >>> Nick >>> >>> PS: I've also proposed the "reverse" of this for CIMD in this issue >>> <https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/78> >>> . >>> >>> -- >>> Nick Watson | Software Engineer | [email protected] | (781) 608-3352 >>> _______________________________________________ >>> 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]
