I think I capture it in that issue, but CIMDs operate on ecosystems, not individual authorization servers typically, due to them targeting a decentralized way of doing oauth (AS fetches the CIMD), so CIMDs are generally static documents, and the spec discourages using query parameters to change the document contents.
Servers should ignore metadata that they don't understand, usually you can't upgrade CIMDs until the ecosystem they're within upgrades their OAuth infrastructure, e.g., AS's. You may have multiple CIMDs for different ecosystems too. e.g., AT Protocol is one ecosystem, and ActivityPub is now another (probably, wordpress just shipped CIMD support for ActivityPub API yesterday). There's also the MCP ecosystem too (though afaik that varies a bit more). — Emelia > On 19 May 2026, at 05:23, Nick Watson <[email protected]> > wrote: > > 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 > <[email protected] > <mailto:[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, >> <https://mattr.global/> >> Tobias Looker >> CTO >> +64 27 378 0461 <tel:+64%2027%20378%200461> >> [email protected] >> <https://mattr.global/> <https://www.linkedin.com/company/mattrglobal> >> <https://twitter.com/mattrglobal> <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] >> <mailto:[email protected]>> >> Date: Tuesday, 19 May 2026 at 3:02 PM >> To: Max Gerber <[email protected] >> <mailto:[email protected]>> >> Cc: Andy Barlow <[email protected] <mailto:[email protected]>>; >> Nick Watson <[email protected] >> <mailto:[email protected]>>; OAuth WG <[email protected] >> <mailto:[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 <[email protected] >> <mailto:[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] >> <mailto:[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] >> <mailto:[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 >> <[email protected] <mailto:[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] >> <mailto:[email protected]> | (781) 608-3352 <tel:(781)%20608-3352> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
