Subject: [OAUTH-WG] Re: AS Metadata client id parameter draft
From: Filip Skokan <[email-masked]>
To: Nick Watson <nwatson=[email-masked]>
Cc: OAuth WG <[email-masked]>
Date: Mon, 18 May 2026 18:57:34 +0200
List-Id: OAUTH WG <oauth.ietf.org>

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-masked]> 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-masked] | (781) 608-3352
> _______________________________________________
> OAuth mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>