MIME-Version: 1.0
References: 
 <CALZ8nCuvyBB7XuRUJO0EqNxXReiaRGe69d0niTGndyvUO6PZMQ@mail.gmail.com>
In-Reply-To: 
 <CALZ8nCuvyBB7XuRUJO0EqNxXReiaRGe69d0niTGndyvUO6PZMQ@mail.gmail.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Mon, 18 May 2026 18:57:34 +0200
Message-ID: 
 <CALAqi_-CVzF2Q+z_Xvr1ShF_mA4wnXskXHX88GaZOdNZ+HK2Dg@mail.gmail.com>
To: Nick Watson <nwatson=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bec4a206521a7743"
Message-ID-Hash: REWGDAEINFUVOUSH6RUWS5Y6G2AO334Y
CC: OAuth WG <oauth@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_AS_Metadata_client_id_parameter_draft?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/edf4CnACF1s8we6LcKpamwsUqAc>

--000000000000bec4a206521a7743
Content-Type: text/plain; charset="UTF-8"

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=
40google.com@dmarc.ietf.org> 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 | nwatson@google.com | (781) 608-3352
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>

--000000000000bec4a206521a7743
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello Nick,</div><div><br></div><div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Let me know what you all think.</blockquo=
te></div><div><br></div><div>Back at IETF 121 I presented this related/simi=
lar idea:</div><div><ul><li><a href=3D"https://youtu.be/_kNpecjcj64?t=3D635=
4">https://youtu.be/_kNpecjcj64?t=3D6354</a></li><li><a href=3D"https://dat=
atracker.ietf.org/meeting/121/materials/slides-121-oauth-sessa-client-id-hi=
nt-for-authorization-server-metadata-requests-00">https://datatracker.ietf.=
org/meeting/121/materials/slides-121-oauth-sessa-client-id-hint-for-authori=
zation-server-metadata-requests-00</a></li></ul><div>I haven&#39;t had a ch=
ance to follow up on it since</div></div><div><br></div><div><div dir=3D"lt=
r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature">S pozdravem=
,<br><b>Filip Skokan</b></div></div><br></div><br><div class=3D"gmail_quote=
 gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 18 Ma=
y 2026 at 17:09, Nick Watson &lt;nwatson=3D<a href=3D"mailto:40google.com@d=
marc.ietf.org">40google.com@dmarc.ietf.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><a href=3D"=
https://njwatson32.github.io/as-metadata-client-id/draft-watson-oauth-as-me=
tadata-client-id.html" target=3D"_blank">https://njwatson32.github.io/as-me=
tadata-client-id/draft-watson-oauth-as-metadata-client-id.html</a></div><di=
v><br></div><div>I&#39;ve written up a quick draft on supporting a client_i=
d parameter on AS Metadata, which would allow the AS to (1) do gradual roll=
outs of AS metadata changes client by client and (2) customize metadata=C2=
=A0if necessary (e.g. for clients participating in beta programs of upcomin=
g drafts).</div><div><br></div><div>AS can also choose to ignore the client=
_id parameter completely and continue serving a statically cached global AS=
 metadata=C2=A0file.</div><div><br></div><div>I had this idea recently when=
 implementing support for 9207 (iss parameter) and running into poorly beha=
ved clients handling these updates badly. The draft I&#39;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=C2=A0authorization_response_iss_parameter_supported.</div><di=
v><br></div><div>Let me know what you all think.</div><div><br></div><div>N=
ick</div><div><br></div><div>PS: I&#39;ve also proposed the &quot;reverse&q=
uot; of this for CIMD in this <a href=3D"https://github.com/oauth-wg/draft-=
ietf-oauth-client-id-metadata-document/issues/78" target=3D"_blank">issue</=
a>.</div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><b=
r><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div style=3D=
"line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);fon=
t-family:sans-serif;font-size:small"><span style=3D"border-width:2px 0px 0p=
x;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top=
:2px">Nick Watson=C2=A0|</span><span style=3D"border-width:2px 0px 0px;bord=
er-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"=
>=C2=A0Software Engineer |</span><span style=3D"border-width:2px 0px 0px;bo=
rder-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"=
>=C2=A0<a href=3D"mailto:nwatson@google.com" target=3D"_blank">nwatson@goog=
le.com</a>=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-styl=
e:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px">=C2=A0=
(781) 608-3352</span></div></div></div></div>
_______________________________________________<br>
OAuth mailing list -- <a href=3D"mailto:oauth@ietf.org" target=3D"_blank">o=
auth@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:oauth-leave@ietf.org" tar=
get=3D"_blank">oauth-leave@ietf.org</a><br>
</blockquote></div>

--000000000000bec4a206521a7743--