Return-Path: X-Original-To: oauth@mail2.ietf.org Delivered-To: oauth@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 263A7F080C02 for ; Mon, 18 May 2026 21:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779165151; bh=K7+Ufrca7pUcuD38LdsTPpU6dZ4iGyVImTFpa7sW6LY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZsGwmIXhGR/ruFzQq6A05seEyo7n8cVBWGHeel51jG/QKb9MG0pgsvurEXjUcV3fq xKYxs5iOtsRAS6EvR7cWJrABaHXeTH53RdRUN5O/rwgtLmJH8kl9RqtL89lHe/k12d SwfAMI2LeyetKXvhYzN0H/XbyZOSB4DfdniBCxr8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=brandedcode.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oiupp844bNY0 for ; Mon, 18 May 2026 21:32:24 -0700 (PDT) Received: from smtp-190b.mail.infomaniak.ch (smtp-190b.mail.infomaniak.ch [IPv6:2001:1600:19:b8b8::190b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 72679F080BE5 for ; Mon, 18 May 2026 21:32:24 -0700 (PDT) Received: from smtp-4-0001.mail.infomaniak.ch (unknown [IPv6:2001:1600:7:10::a6c]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4gKMG90rgzzNZs; Tue, 19 May 2026 06:32:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brandedcode.com; s=20250226; t=1779165136; bh=Sy10MkMWy/T1u/fo51OWEvEgQkDWgp6NCLybKP2QuwI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ARRsc8PEi3jxgY5ivlW29n3D5dwfGAnduqg9ObMX9uhWZn8BUowi18sKHiccN1T9p +3JzZQBpAzVdy/FAl/sxTJ39NftVj42pmkr4JqxT1AwbAPrqvesLdzScSeuLR+9Mq3 8j+Ae3ZHCMb4A2KnyzCKW6F0gAcKnA3swehhsCtTaICvB+X07CXM04+PyB3ibZ3rs9 PI18WJZs4wcczxSzs8sxLplN2EdtkyIfPpI1Oo0l/wCm/vY5eCn9lzvyUx+FlOSTJw RFIUivn8e4/49BIWB96NYZzle86gUVOCsNeiih2TKSW28ePM8Nsycbi8MOmTHA4Ygk etjPOTsCq6yBg== Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4gKMG81cRZzSsl; Tue, 19 May 2026 06:32:16 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A65F61BF-DF44-47B1-86D1-581483F7DE29" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) From: "Emelia S." In-Reply-To: Date: Tue, 19 May 2026 06:32:05 +0200 Message-Id: References: To: Nick Watson X-Mailer: Apple Mail (2.3864.500.181) X-Infomaniak-Routing: alpha Message-ID-Hash: TOHX4LXYXNKDE2YTSFA4IC4VYSE4Q264 X-Message-ID-Hash: TOHX4LXYXNKDE2YTSFA4IC4VYSE4Q264 X-MailFrom: emelia@brandedcode.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Tobias Looker , Karl McGuinness , Andy Barlow <0xandybarlow@gmail.com>, OAuth WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_AS_Metadata_client_id_parameter_draft?= List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_A65F61BF-DF44-47B1-86D1-581483F7DE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think I capture it in that issue, but CIMDs operate on ecosystems, not = individual authorization servers typically, due to them targeting a = decentralized way of doing oauth (AS fetches the CIMD), so CIMDs are = generally static documents, and the spec discourages using query = parameters to change the document contents. Servers should ignore metadata that they don't understand, usually you = can't upgrade CIMDs until the ecosystem they're within upgrades their = OAuth infrastructure, e.g., AS's. You may have multiple CIMDs for = different ecosystems too. e.g., AT Protocol is one ecosystem, and = ActivityPub is now another (probably, wordpress just shipped CIMD = support for ActivityPub API yesterday). There's also the MCP ecosystem = too (though afaik that varies a bit more). =E2=80=94 Emelia > On 19 May 2026, at 05:23, Nick Watson = wrote: >=20 > = https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/i= ssues/78 is the proposal I made for CIMD. >=20 > On Mon, May 18, 2026 at 8:13=E2=80=AFPM Tobias Looker = > 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. >>=20 >> Thanks, >> =09 >> Tobias Looker >> CTO >> +64 27 378 0461 >> tobias.looker@mattr.global >> = = = >>=20 >> This communication, including any attachments, is confidential. If = you are not the intended recipient, you should not read it =E2=80=93 = 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. >>=20 >> From: Karl McGuinness > >> Date: Tuesday, 19 May 2026 at 3:02=E2=80=AFPM >> To: Max Gerber > >> Cc: Andy Barlow <0xandybarlow@gmail.com = >; Nick Watson = >; OAuth WG > >> Subject: [OAUTH-WG] Re: AS Metadata client id parameter draft >>=20 >> 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. >>=20 >> 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! >>=20 >> 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. =20 >>=20 >> -Karl >>=20 >>=20 >>=20 >> =20 >>=20 >> On Mon, May 18, 2026 at 5:27=E2=80=AFPM Max Gerber = > = wrote: >> It's a really interesting idea. Thanks Filip for the slides as well! >>=20 >> > (1) do gradual rollouts of AS metadata changes client by client >>=20 >> 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. >>=20 >> > (2) customize metadata if necessary=20 >>=20 >> 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. >>=20 >> 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=E2=80=94a 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. >>=20 >>=20 >> On Mon, May 18, 2026 at 10:08=E2=80=AFAM Andy Barlow = <0xandybarlow@gmail.com > wrote: >> I fully support any and all effort on this topic. >>=20 >> On Mon, 18 May 2026 at 17:58, Filip Skokan > wrote: >> Hello Nick, >>=20 >> Let me know what you all think. >>=20 >> Back at IETF 121 I presented this related/similar idea: >> https://youtu.be/_kNpecjcj64?t=3D6354 >> = 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 >>=20 >> S pozdravem, >> Filip Skokan >>=20 >>=20 >> On Mon, 18 May 2026 at 17:09, Nick Watson = > wrote: >> = https://njwatson32.github.io/as-metadata-client-id/draft-watson-oauth-as-m= etadata-client-id.html >>=20 >> 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). >>=20 >> AS can also choose to ignore the client_id parameter completely and = continue serving a statically cached global AS metadata file. >>=20 >> 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. >>=20 >> Let me know what you all think. >>=20 >> Nick >>=20 >> PS: I've also proposed the "reverse" of this for CIMD in this issue = . >>=20 >> -- >> 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 = >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org = >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org = >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-leave@ietf.org = _____________________________________________= __ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org --Apple-Mail=_A65F61BF-DF44-47B1-86D1-581483F7DE29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think I capture it in that issue, but = CIMDs operate on ecosystems, not individual authorization servers = typically, due to them targeting a decentralized way of doing oauth (AS = fetches the CIMD), so CIMDs are generally static documents, and the spec = discourages using query parameters to change the document = contents.

Servers should ignore metadata that they = don't understand, usually you can't upgrade CIMDs until the ecosystem = they're within upgrades their OAuth infrastructure, e.g., AS's. You may = have multiple CIMDs for different ecosystems too. e.g., AT Protocol is = one ecosystem, and ActivityPub is now another (probably, wordpress just = shipped CIMD support for ActivityPub API yesterday). There's also the = MCP ecosystem too (though afaik that varies a bit = more).

=E2=80=94 = Emelia

On 19 May 2026, = at 05:23, Nick Watson <nwatson=3D40google.com@dmarc.ietf.org> = wrote:


On Mon, May 18, 2026 at 8:13=E2=80=AFPM = Tobias Looker <tobias.looker=3D40mattr.global@dmarc.ietf.or= g> 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,
3D"MATTR =
Tobias Looker
CTO
= +64 27 378 0461
tobias.looker@mattr.global
= = 3D"MATTR = = 3D"MATTR = = 3D"MATTR = = 3D"MATTR

This communication, including any attachments, is confidential. If you are = not the intended recipient, you should not read it =E2=80=93 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 <me@karlmcguinness.com>
Date: Tuesday, 19 May 2026 at 3:02=E2=80=AFPM
To: Max Gerber <max=3D40stytch.com@dmarc.ietf.org>
Cc: Andy Barlow <0xandybarlow@gmail.com>; Nick Watson = <nwatson=3D40google.com@dmarc.ietf.org>; OAuth WG <oauth@ietf.org>
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=E2=80=AFPM Max Gerber <max=3D40stytch.com@dmarc.ietf.org> 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=E2=80=94a 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=E2=80=AFAM Andy Barlow <0xandybarlow@gmail.com> wrote:
I fully support any = and all effort on this topic.

On Mon, 18 May 2026 at = 17:58, Filip Skokan <panva.ip@gmail.com> wrote:
Hello Nick,

Let me know what you = all think.

Back at IETF 121 I = presented this related/similar idea:
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=3D40google.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.

--
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
_______________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- = oauth@ietf.org
To unsubscribe send an email to = oauth-leave@ietf.org

= --Apple-Mail=_A65F61BF-DF44-47B1-86D1-581483F7DE29--