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

[Tobias Looker <[e-mail]>]

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,
[MATTR website]<https://mattr.global/>
Tobias Looker
CTO
[phone]
[e-mail]
[MATTR website]<https://mattr.global/>  [MATTR on LinkedIn] <https://www.linkedin.com/company/mattrglobal>      [MATTR on Twitter] <https://twitter.com/mattrglobal>    [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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> | [phone]
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>