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 B3227F07B306 for ; Mon, 18 May 2026 20:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1779161030; bh=GA/aOcBwM1IDSasPnxAnctQhCsoArc4hzLwgbzQUzj4=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=gndfrbtJ2NciKRDEZy8Ho7f2RIBDt4Hbmh+82hhZwUPvjdVTa1kHHAE0OtI+J0ttJ U2mK2pN+SfHUq5B8QPxOunbtKSmYVMNuBaQCABj9W5FXU9jq097UtXVZLBnIq8VpXZ VedCaEF31Ytw5bqkQAZYBc/k4vH0Ibot6snkJqq0= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oxQGerg4Sdmf for ; Mon, 18 May 2026 20:23:49 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D80C2F07B2FB for ; Mon, 18 May 2026 20:23:49 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-67f7caa33easo6436781a12.1 for ; Mon, 18 May 2026 20:23:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779161029; cv=none; d=google.com; s=arc-20240605; b=izWAZ0SczP4xLyK4oVsUBdnREqamWidRnH+5Qy09Ag7OwudiA+KdGaU78Aj4gdqJ2E xF8ROCAUh11OpspS8aWHXNGH/OJlUETqihRj27FVgi6WvTMwaCzCLfTGjiHy+Po10saL uQdImgCQtciphQ6fKPyFSNZWWuGvuDscdgHTY2rLqmalJO3iZOYF1pGCZu/OPKoG/768 1gkDYcb5QOJAv36+KxN4ThZoNYsmvBtscoM+172fYoNVPqLuP75GCm2SIHJ29lJFtNn8 ovrToeiRGGswwGFtKB2V7uPtYmH2v+BNPE7wvPYuQ2F1Gl9KSLY078xjXTa/iH+Q8eYb ippA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=SNiT3ypj5EHeAfYZhmcee6Q/M2wtiOJvWB3/L8LcNws=; fh=RTng7dzltIlHXkTsKXerl8wd7Zkqb+X6KVh/BpQwzJU=; b=RMOw4lHEMk7d0UC+qCbG758oCbAKAFixUHDVbPI60jQS4oUpxBSO30HK4fGAydkYHf OBQV9PZxTR1/s+gp6kiVkKw0I9fN1lxHBYQ9Gsw/6lW4XGm1Eg2Hb9xOf559LcsZsPBd 2n9lSMBc6gUgxnpFxw0xhg2X/nX6uDh+h/BWBZP8DqoB4BDT0DNNSjzA7omFZ0UUCOfA 8tlFpTbGSq7oS088hpvBgXVecMTirIK5hhnbWEKNWDPxNpxzwefgqrTggAbIhZyuBy6M 0VBlvNnTu9EhCDcWxGkk0AIy8wQSK6/pc2FPigdmeQJfmZlv9s0LH8OeIcOE/wonhuNV 0A1w==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779161029; x=1779765829; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SNiT3ypj5EHeAfYZhmcee6Q/M2wtiOJvWB3/L8LcNws=; b=oyk4/j6WZqBYAeUyvZhDsEbABSpb7GfNeeJynqRBVipzqj5EcXtetohhMrTSsEalqR Nl36mEPpJlyz7FurpvJdw8Id9qOGJqIBmXRkPl+UQoP8KbzYvkoppvKxMRtKlQ3Rpm14 fze88KA5KnDKz5b7htWtmqjR32kUh9uWseG7XuzkzNzPQVEVbMO4qSHKfleFAVOYdMWt brUQuv8HScsDMi7msoBENP9KcI61JVlc8CgHzUvaEzU6baP1uHSJEgxKu8Zaw+gli8vt BYEa338mNY87ZOZi441b/D4/dVDMJcAuEECW/V+kEs0LHSli9VZ8TdKSipazrsVFhJsT suJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779161029; x=1779765829; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SNiT3ypj5EHeAfYZhmcee6Q/M2wtiOJvWB3/L8LcNws=; b=PJs/TIUySDAkTTp/2ur2p3xP1lD5qQaUNa4aD3KgVC8i0epuXKIWdN/RO7MCFrIR8Q nycDaPOJtrf8+byCaNG1d2uS48eYUyduaG8voH7qapg4Twp2UNr0dPD7viD3+4hocN5g ETOLEJf2AD1LWKj6yjK6F6t7bPmZVUr8lSLU4B5uLjnpyMCDn+B6UozRpKszQKyznG1n AKRJ/ggMBLezRv2y+Y0PVG/klj7R1qC7IpjLy0xs86waqKTEZKTM/owo6Hm3/diLMkgR cq5WFUFPhmt056EEGF72SfHhs3FAkL2O2MAfV1Oh3JKxQ4HJ9bqsBnQtiXpkbOuaZ887 8tOw== X-Forwarded-Encrypted: i=1; AFNElJ8RoKCbSH84L3ZrXwjIJxtLowF+gMvGJ9thNngLutl4lUs5ECG/zs0MO3AhRARA58Yuh5p9Ww==@ietf.org X-Gm-Message-State: AOJu0Yxs+iZ5FiWRuMxAvq7s2RdE+S62db8ZjGomomZ3ZqcRGvKTnRTJ XY7vkhc+C9QGDHYfaTPxGPUTepbzkD5nqAEz2sPaM00gNJopLdYF2hRBFB8CBgkq2mfyAklJ0v+ c8EeobXheVKZj7ZJrIltR1dgplTRLGAvvUOC/Pb27i+LWHCfaMRQC/J45Yb4= X-Gm-Gg: Acq92OFWQGD9cm8rHB69ms7opywjYG/GvMSF4hyfwVdMFNeKpf3NxFh4CjnWaY+arlO MNCcsxLtxNReB6ly2CFGw5DLwX9lOpa8l8Mw0qmZlcKNxEIGhAqhbWYy9a0lt1ZEywqierWo0jV GE+qLMMayR803jYKstZ805fsXmPziup1X4fGxea8NlBfWf9ZcIFti8oevqdHNVrmXFZe/3zO+E2 tUbS3ac5ogMWQj/YistLJ7TLoC3X01a3VfYYNMivHZsWM9cmuluDBaDew0iChOlZKyBvQ30jmOv FQogDM7yfFrh+4TLJgRkm8C4xSwd+SlYhugSCFB33qBpzZy7wg== X-Received: by 2002:a17:907:8691:b0:bd2:626d:68cf with SMTP id a640c23a62f3a-bd517929a8cmr1031318666b.29.1779161027547; Mon, 18 May 2026 20:23:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Watson Date: Mon, 18 May 2026 20:23:35 -0700 X-Gm-Features: AVHnY4JqEYhAjo0KlwrYaN6ebTXPnKjMxUWI8leUBM4PmyyYZ51-opQv5HpUeGQ Message-ID: To: Tobias Looker Content-Type: multipart/alternative; boundary="0000000000000c7b8f0652233591" Message-ID-Hash: AMAUH4CPORMNZGPSE2EDZ55K7PGAE2ZO X-Message-ID-Hash: AMAUH4CPORMNZGPSE2EDZ55K7PGAE2ZO X-MailFrom: nwatson@google.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: 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: --0000000000000c7b8f0652233591 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/is= sues/78 is the proposal I made for CIMD. 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 clie= nt > specific AS metadata or better still, metadata based on what the client i= s > known to support via CIMD, would significantly improve many OAuth > deployments. > > Thanks, > [image: MATTR website] > > *Tobias Looker* > CTO > +64 27 378 0461 <+64%2027%20378%200461> > tobias.looker@mattr.global > [image: MATTR website] [image: MATTR on LinkedIn] > [image: MATTR on Twitter] > [image: MATTR on Github] > > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it =E2=80=93 please conta= ct 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 > *Date: *Tuesday, 19 May 2026 at 3:02=E2=80=AFPM > *To: *Max Gerber > *Cc: *Andy Barlow <0xandybarlow@gmail.com>; Nick Watson 40google.com@dmarc.ietf.org>; OAuth WG > *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 redu= ce > 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 40stytch.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 b= y > the AS to use it for legacy reasons. Using this endpoint, an attacker cou= ld > 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 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=3D6354 > - > https://datatracker.ietf.org/meeting/121/materials/slides-121-oauth-se= ssa-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 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 glob= al > 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 > > --0000000000000c7b8f0652233591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 18, 2026 at 8:13=E2=80=AFPM Tobia= s Looker <tobias.looker=3D40mattr.global@dmarc.ietf.org> wrote:
Also very supportive of this, including the further feature that Karl sugge= sted r.e CIMD. Being able to gradually roll change by providing client spec= ific AS metadata or better still, metadata based on what the client is know= n 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"MAT= 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 communicat= ion 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@dm= arc.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 c= lick 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 mech= anism to enable discovery of client-specific metadata values and reduce cha= nge management risk as folks have indicated.=C2=A0 Okta=C2=A0shipped suppor= t 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 D= ocument (CIMD) where the=C2=A0authorization server identifier is an optiona= l parameter for the same reasons.=C2=A0 =C2=A0

-Karl



=C2=A0

On Mon, May 18, 2026 at 5= :27=E2=80=AFPM Max Gerber <max=3D40stytch.com@dmarc.ietf.org> wrote:
It's a really intere= sting 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 ca= n try (emphasis on try!)=C2=A0to feature flag responses based on IP address o= r User-Agent but both of those are very=C2=A0poor signals.

>=C2=A0(2) customize metadata=C2=A0if necessary=C2=A0

I am not a fan of long-lived customizations of metadata to support legacy c= lients, though I understand gradual rollouts and long-lived legacy flags ar= e two sides of the same coin. I know it is not always possible or reasonabl= e, 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 attack= er could enumerate=C2=A0which legacy features an AS still supports for a gi= ven client.
This differs from observing that client's behavior=E2=80=94a client mig= ht remove the use of the `implicit` grant from their flow, but still be per= mitted by the AS to use it for legacy reasons. Using this endpoint, an atta= cker could determine that fact and attempt to exploit it.


On Mon, May 18, 2026 at 1= 0: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 prese= nted this related/similar idea:
I haven't had a chan= ce 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 qu= ick draft on supporting a client_id parameter on AS Metadata, which would a= llow the AS to (1) do gradual rollouts of AS metadata changes client by cli= ent and (2) customize metadata=C2=A0if necessary (e.g. for clients participating in beta programs of upcoming drafts).

AS can also choose to ig= nore the client_id parameter completely and continue serving a statically c= ached global AS metadata=C2=A0file.

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 retur= ning `iss` from the authorization endpoint and declaring=C2=A0authorization= _response_iss_parameter_supported.

Let me know what you all= think.

Nick

PS: I've also propos= ed the "reverse" of this for CIMD in this issue.

--
Nick Watson=C2=A0|=C2=A0Software Engineer | nwatson@google.com=C2=A0|=C2=A0(781) 608-3352
_______________________________________________<= br> OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________<= br> OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________<= br> OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________<= br> OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--0000000000000c7b8f0652233591--