[OAUTH-WG] Re: AS Metadata client id parameter draft

[Nick Watson <[e-mail]>]

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=
[e-mail]> 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
> [phone] <+64%2027%20378%200461>
> [e-mail]
> [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 <[e-mail]>
> *Date: *Tuesday, 19 May 2026 at 3:02 PM
> *To: *Max Gerber <max=[e-mail]>
> *Cc: *Andy Barlow <[e-mail]>; Nick Watson <nwatson=
> [e-mail]>; OAuth WG <[e-mail]>
> *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=
> [e-mail]> 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 <[e-mail]>
> wrote:
>
> I fully support any and all effort on this topic.
>
> On Mon, 18 May 2026 at 17:58, Filip Skokan <[e-mail]> 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=
> [e-mail]> 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 | [e-mail] | [phone]
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>