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]
