https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/78 is the proposal I made for CIMD.
On Mon, May 18, 2026 at 8:13 PM Tobias Looker <tobias.looker= [email protected]> wrote: > Also very supportive of this, including the further feature that Karl > suggested r.e CIMD. Being able to gradually roll change by providing client > specific AS metadata or better still, metadata based on what the client is > known to support via CIMD, would significantly improve many OAuth > deployments. > > Thanks, > [image: MATTR website] <https://mattr.global/> > > *Tobias Looker* > CTO > +64 27 378 0461 <+64%2027%20378%200461> > [email protected] > [image: MATTR website] <https://mattr.global/> [image: MATTR on LinkedIn] > <https://www.linkedin.com/company/mattrglobal> [image: MATTR on Twitter] > <https://twitter.com/mattrglobal> [image: MATTR on Github] > <https://github.com/mattrglobal> > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it – please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > *From: *Karl McGuinness <[email protected]> > *Date: *Tuesday, 19 May 2026 at 3:02 PM > *To: *Max Gerber <[email protected]> > *Cc: *Andy Barlow <[email protected]>; Nick Watson <nwatson= > [email protected]>; OAuth WG <[email protected]> > *Subject: *[OAUTH-WG] Re: AS Metadata client id parameter draft > > EXTERNAL EMAIL: This email originated outside of our organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > I strongly support standardizing an approach for a per-client metadata > mechanism to enable discovery of client-specific metadata values and reduce > change management risk as folks have indicated. Okta shipped support for > client_id as query param for similar reasons almost 10 years ago! > > I also think we need to consider the inverse for OAuth Client ID Metadata > Document (CIMD) where the authorization server identifier is an optional > parameter for the same reasons. > > -Karl > > > > > > On Mon, May 18, 2026 at 5:27 PM Max Gerber <max= > [email protected]> wrote: > > 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] > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
