Very supportive of this. Like probably many others, we've had a proprietary version of this for years (actually multiple different mechanisms to hack in interoperability with various providers). I think it would be useful for the AS to at least indicate whether it has understood the request for "custom" metadata, and I think echoing the client ID is not a bad way to do it. I think Max is right that this might expose insecure configuration even if it is not currently used. I'm not convinced that it would be substantially easier than just trying it out by sending a request to the AS asking for e.g. an implicit grant and seeing what happens. Doing so is already very cheap, and I don't think most deployments have the capability to detect someone doing this enumeration in real time to block them.
For the CIMD proposal, I agree with Nick that people will almost certainly hack in this functionality if it is not supported, just as they've been doing for AS metadata. If someone has examples of people already doing this, it might help build support for allowing it in the spec? Cheers, *Frederik Krogsdal Jacobsen* Staff Engineer, Identity Standards IDURA <https://idura.eu> On Tue, 19 May 2026 at 06:33, Emelia S. <emelia= [email protected]> wrote: > 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 <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] > > > _______________________________________________ > 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]
