Received: from mail-vs2-x10.google.com (mail-vs2-x10.google.com [IPv6:2a00:1450:4864:3a::10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 264723F for ; Mon, 21 Sep 2026 12:55:22 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=rhosys.ch header.s=google2024 header.b=CUWreFlk; arc=pass ("google.com:s=arc-20260327:i=1"); dmarc=pass (policy=reject) header.from=rhosys.ch; spf=pass (mx.ietf.org: domain of wparad@rhosys.ch designates 2a00:1450:4864:3a::10 as permitted sender) smtp.mailfrom=wparad@rhosys.ch Received: by mail-vs2-x10.google.com with SMTP id ada2fe7eead31-79229116537so867069137.0 for ; Mon, 21 Sep 2026 05:55:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789995315; cv=none; d=google.com; s=arc-20260327; b=fhvR01el6G3bwxB1fmXv8D4n4R++DF7aYL3T24ChierR6P0189yuwl6xTTSfhw5Ztc WRvKCG8Ef5rZnL8I9pIBB2vqEm9UjkpWFE3tzLbmzV3P8SQm5tKTfv8SDTmvhERg2uTU M1zelhmHZGPNqNdI83XNc7WdFYm7Z4A6L7xjheUffD8f6tqoi1ssOpGj6hfprd7w1DxW 9iwTEzaJ9I6M7svsNJq1TSsULqXmc166pxkYDkMoZJqJGFgNemsrRVZ1cW6XjdubH1UZ jpApIijoEQQpAjhsrQvCrMml4R0vpM+F/4x3ye05AzMYxWagQLAjd/IAxudraoHX/o6s kwpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=mClOB8bQqmAozKN5jScZuUJkwCy7ztqBPqjAJxIH1B8=; fh=Hdz9eYpIPC4TVI7Ple1aqwv8kAmqtdStN6agEjdOPsY=; b=KUYvWySNWDqDcJBWO6P5S9vWm2mxO6VFZCQNb79dXPFi/S/mwa0ou4YbKQwZ2+9FmL R03reAvXPJI9OLQ+W+bUuJjAK3awpumm+VkUHQjRgUbADffHYrL4z+DBeQkcS4WbAX2f /GsSXM8Rz6k5YNO+MlB+ZWbumDfWPYK8hsyT5+uxmwHWBX+sS5k4ISC18aweCRRJ2K05 DuXI1vbQvamT1I1ofqjdtKcyKmehFmuT4QgApuRkpyW6rK7iMiI+AobW53dn59GUq36j JeQfxR4r8j/eUCSwe7djykVF/bZ8xIha7h+gbFVgn1i3bB19azpjbEnTKEAdf7D/UkJw 8gjQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google2024; t=1789995315; x=1790600115; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mClOB8bQqmAozKN5jScZuUJkwCy7ztqBPqjAJxIH1B8=; b=CUWreFlkHu2sm5qrXC7eepiP6KKpfHiFg6eaVXZTtnJmdvy8f5E+7/bOAj7L64vaUe u2Pv3Y58kqZHR8xNWtgtjfybY2k3VeD2eDfb+KHIPtK7ffRMNX2PZTYjADR3pe4sTHNg 7nT6fMz0tg5q0yjR8pdJ/T92A/z60dzmCXD5P3AzJoS+EcPXCTQ9QRuS36mXC74yfyjc diGS6JCdaojc9q7KlLsLNalmaHbf0ZUHaP91S54or35luTZGeN9ud+KLukyKSmSlMMqM /jTKCQXbugojKdP46MIRsfPe1PZYk3C1pi5qp+KnEWEoKdYvX9SR9EDPkHqvtrOutVxP Wtgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789995315; x=1790600115; h=content-type: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:content-type; bh=mClOB8bQqmAozKN5jScZuUJkwCy7ztqBPqjAJxIH1B8=; b=DvOWzaTBeUJop5whi7s5Fp38QW5IsLkzHBTJBLX72UeRr0O0AVd/RDBckm7YndrhQ4 NN953Fij1gYw6E1lRq5qeUcpwMte4Yvj8n2AvXT/DSwHy/iACQrFvphMLT6EtxOAHbbp lQmbYeAgBCk2MQozd4lDwohYOzRLi8EkTm4NvTLOPJdiDuRSpASd/bmlXPTEC37WCeSb 3rKjehCicqEz+57EXCvcnyFKjejvKHKni/iOzKL/WprhHUWCfvvoj4I3kFpoYpv1Z2Gt V9Pt8dOxkMv9YnLnkreNg89szsIBI6YLYdj2wxjrliud8aXU2F3i51yy0kp6KYa3sRUs XLxw== X-Forwarded-Encrypted: i=1; AKwUvBwI3WViJmKM2QHly9ws6P7g7/qCxO+TAX8Z2OStgHr2HuY++UH2yczKYWy0f1vjds2bvyWRDQ==@ietf.org X-Gm-Message-State: AFuF++mq8Fcan8PmsbEb9CZn9ZZKdMTm2g1xMvvKPNQbo/xxXvjhGKMC VFgkdjIFz9uycfCdAIUAqmIQqd0nMGo59I3svf+bqD7jDNph4Wd/E5bwtFPVimSIWW0iKrhc8Ql TPPK40K3dUlIRwUtjcxomNWZ01QV42RXLCuNiKr66 X-Gm-Gg: AYBFou1f7nxsBQrzKxS2+j6p0KFVwwQu/V6w2L7Ucwc4XQzJsjTw2Ypl0e2ZeDf4tYY ViqdYCpMJCkvZP2Z7tiyOwA2YMHNlt+Ou0QzRL8EvCazCH/CiGIOsx4fVE/rGumMJm0JRepehcE 4qnOhP+OJ5+7JKJicqKfD3gXj6K/wBo2qHIXiKZ8KHdsoJUPzjt0y3kzi1hWSyLxK712ec5n8mZ jIkODWrRYbFV/33gO5BvvQmxIOylh35menJGBdn23bzMVX0TM/QsXVHv2/0xxYsZxyNZlTIH4Dn WZxk36AroNCUTaX5HgCj42KEQ2ofpm5qNHAaWqH7WNznJ+htG323l3Gzig2FOyaqOVXy53dTdOy X2rfNexQ+fpuqTRBMPnmSX90K9Xc9jNjqbo8BvseiaWxCpTYuyWYEIfKlvzKqiMU+FRs6unHZeB Mfg6nFqoMsJ6Amzph7Qhffgb62zewODB5q2IEYHoPafJkvvWLcbE/C1mI= X-Received: by 2002:a05:6102:149d:b0:7a7:196a:84ec with SMTP id ada2fe7eead31-7a7196a9b63mr2108077137.36.1789995315398; Mon, 21 Sep 2026 05:55:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Mon, 21 Sep 2026 14:55:03 +0200 X-Gm-Features: AcwNN1X60dfHJxge9DQxKSYmIT7n7-0geoqrcmjbuZqTJdhdh090NqM6mvehinU Message-ID: To: emelia Content-Type: multipart/alternative; boundary="000000000000eca62d065bfdc2d7" X-Spamd-Bar: / Message-ID-Hash: TFBEKPYEPJYOGJIYAP7X5FIO3BM6T6EX X-Message-ID-Hash: TFBEKPYEPJYOGJIYAP7X5FIO3BM6T6EX X-MailFrom: wparad@rhosys.ch X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-oauth.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Warren Parad , "Emelia S." , oauth X-Mailman-Version: 3.3.10 Precedence: list Subject: [OAUTH-WG] Re: Possibly incorrect IANA registry contents for Error Registry List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000eca62d065bfdc2d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interestingly in your draft this section has a similar mistake https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-documen= t-02.html#name-authorization-server-metada As it says: > Otherwise, the client would redirect the user and the > user would be met with an error about an invalid client as described > in Section 4.1.2.1 of [RFC6749]. Which by the above thread never actually happens. I think it is safe to say that there is no dedicated error code to handle the conditional case of CIMDs partially invalid during an authorization call (PAR, RAR, or vanilla authorize). and so the only valid codes as defined by the 6749 that would work here would be *invalid_request *or potentially *unauthorized_client*. But I would expect the CIMD RFC to explicitly lay out those scenarios and the error code that should be used if one of the ones in the 6749 RFC isn't sufficient. Part of the question here is are CIMD errors fundamentally redirectable? Some of them might be, that's likely a CIMD specific concern and not likely one that the general current OAuth guidance can weigh in on. On Mon, Sep 21, 2026 at 1:57=E2=80=AFPM emelia wro= te: > I think I'd be okay with the IANA registry being updated to also referenc= e > PAR, alongside 6749, it's just 6749 doesn't reflect the registries's > contents. > > My use for invalid_client is "what happens if a CIMD is invalid or > contains something like token_endpoint_auth_method of private_key_jwt but > does not have a jwks or jwks_uri property (which would make that > authentication method fail)" > > Given CIMDs are fetched after authentication, this is on the authorize or > token endpoint, not PAR which is before authentication (though iirc we ha= ve > that just as a security consideration) > > I'm looking for an appropriate error response for various CIMD scenarios, > and I think invalid_client or invalid_client_metadata may be most > applicable. > > Emelia > > On 21. Sep 2026, at 11:48, Warren Parad wrote: > > =EF=BB=BF > Fundamentally it isn't redirectable, but then you are right, what's the > point of the error code. > > So obviously on the normal authorization endpoint when used as a redirect= , > it cannot be used, and also isn't defined in the exclusive list in 4.1.2.= 1 > . > > Is it a mistake in the registry when driven from this specific RFC, maybe= . > > However, in the PAR (pushed authorization request RFC > ), we explicitly > have this: > >> The authorization server returns an error response with the same format >> as is specified for error responses from the token endpoint in *Section >> 5.2 of [RFC6749]* using the appropriate error code from therein *or from >> Section 4.1.2.1* of [RFC6749]. > > > The token endpoint error response does include *invalid_client*. So it > wouldn't matter if it was registered in the *authorization endpoint > responses* according to the PAR RFC. > > Interestingly, RFC 8414 says basically all Open ID modes are supported, > but doesn't say what they are explicitly, nor lists error types. > So if anything 8414 should have included it to support the *form_post*. > The fragment and query are still redirect modes, so not relevant I think. > The form post is only referenced in 8414, as a link to the Open ID > response mode > draf= t, > which also doesn't define the error responses. > > It seems nothing links to it at all, at the very least it does feel like > 8414 technically would be the linked registry addition or potentially the > PAR RFC. > > If we assume the question is "Is invalid_client a valid error code in the > authorization response" AND I assume authorization response includes the > response to the pushed authentication request. Then my answer is yes. > But if we assume the question is "Is invalid_client a valid error code in > the authorization redirect?" Then my answer is no. > Is the registry link wrong, I would say yes. > > I don't know if this helps Emelia at all though :) > > On Mon, Sep 21, 2026 at 9:26=E2=80=AFAM Thomas Broyer wrote: > >> >> >> On Sun, Sep 20, 2026 at 6:59=E2=80=AFPM Warren Parad > 40rhosys.ch@dmarc.ietf.org> wrote: >> >>> Yes it's valid. No it isn't redirectable. >>> >> >> Isn't this a bit contradictory? >> >> The whole point of the Authorization Endpoint ( >> https://www.rfc-editor.org/info/rfc6749/#section-3.1) is to redirect to >> a Redirection Endpoint "after completing [=E2=80=A6] interaction with th= e resource >> owner". >> If invalid_client is not redirectable, then it cannot be used by the >> authorization endpoint, as defined in RFC 6749. >> Response types other than code or token (or rather, response modes other >> than fragment, query or form_post; but response_mode is not defined in R= FC >> 6749) could possibly use other means of returning a response to the clie= nt >> that doesn't involve a redirect (such as the once/twice proposed >> response_mode=3Dweb_message) but then it would likely be those that woul= d >> register be linked from the registry in addition to RFC 6749? >> >> Or are you saying that the registry listing invalid_client for the >> authorization endpoint was specifically done in prevision for other >> response modes? (i.e. to not forbid them from using that error code) >> >> >>> On Sun, Sep 20, 2026, 18:37 Emelia S. >> 40brandedcode.com@dmarc.ietf.org> wrote: >>> >>>> Hi all, >>>> >>>> In the OAuth Extensions Error Registry managed by IANA, invalid_client >>>> is listed as having a usage location of "token endpoint, authorization >>>> endpoint", citing RFC6749, however, RFC6749's Section 4.1.2.1 >>>> "Authorization Code Grant -> Authorization Response -> Error Response"= does >>>> not list invalid_client. >>>> >>>> https://www.iana.org/assignments/oauth-parameters#extensions-error >>>> >>>> I'm not sure where the IANA registry contents is from, given that >>>> RFC6749 does not include the initial registry contents. The only place >>>> invalid_client is listed in RFC6749 is on the token endpoint. >>>> >>>> Can someone clarify if `invalid_client` is valid for the authorization >>>> endpoint and if that error is redirectable? >>>> >>>> =E2=80=94 Emelia >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> Thomas Broyer >> /t=C9=94.ma.b=CA=81wa.je/ >> >> > --000000000000eca62d065bfdc2d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Interestingly in your draft this section ha= s a similar mistake=C2=A0https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-do= cument-02.html#name-authorization-server-metada

= As it says:
Otherwise, the client would redirect the user and the
=C2= =A0 =C2=A0user would be met with an error about an invalid client as descri= bed
=C2=A0 =C2=A0in Section 4.1.2.1 of [RFC6749].

Which by the above thread never actually happens.

I think it is safe to say that there is no dedicated error= code to handle the conditional case of CIMDs partially invalid during an a= uthorization call (PAR, RAR, or vanilla authorize). and so the only valid c= odes as defined by the 6749 that would work here would be invalid_reques= t or potentially=C2=A0unauthorized_client. But I would expect th= e CIMD RFC to explicitly lay out those scenarios and the error code that sh= ould be used if one of the ones in the 6749 RFC isn't sufficient.
=

Part of the question here is are CIMD errors fund= amentally redirectable? Some of them might be, that's likely a CIMD spe= cific concern and not likely one that the general current OAuth guidance ca= n weigh in on.

On Mon, Sep 21, 2026 at 1:57=E2= =80=AFPM emelia <emelia@brande= dcode.com> wrote:
I think I'd be okay with the IANA registry= being updated to also reference PAR, alongside 6749, it's just 6749 do= esn't reflect the registries's contents.

My use = for invalid_client is "what happens if a CIMD is invalid or contains s= omething like token_endpoint_auth_method of private_key_jwt but does not ha= ve a jwks or jwks_uri property (which would make that authentication method= fail)"

Given CIMDs are fetched after authent= ication, this is on the authorize or token endpoint, not PAR which is befor= e authentication (though iirc we have that just as a security consideration= )

I'm looking for an appropriate error respons= e for various CIMD scenarios, and I think invalid_client or invalid_client_= metadata may be most applicable.

= Emelia

On 21. Sep 2026,= at 11:48, Warren Parad <wparad@rhosys.ch> wrote:

=EF=BB=BF
Fundamentally it= isn't redirectable, but then you are right, what's the point of th= e error code.

So obviously on the normal authorization e= ndpoint when used as a redirect, it cannot be used, and also isn't defi= ned in the exclusive list in 4.1.2.1.

<= div>Is it a mistake in the registry=C2=A0when driven from this specific RFC= , maybe.

However, in the PAR (pushed autho= rization request RFC), we explicitly have this:
The authorization = server returns an error response with the same format as is specified for e= rror responses from the token endpoint in Section 5.2 of [RFC6749] u= sing the appropriate error code from therein or from Section 4.1.2.1= of [RFC6749].

The token endpoint er= ror response does include invalid_client. So it wouldn't matter = if it was registered in the authorization=C2=A0endpoint responses=C2= =A0according to the PAR RFC.

Interestingly, RFC 84= 14 says basically all Open ID modes are supported, but doesn't say what= they are explicitly, nor lists error types.
So if anything 8414 = should have included it to support the form_post. The fragment and q= uery are still redirect modes, so not relevant I think.=C2=A0 The form post= is only referenced in 8414, as a link to the Open ID= response mode=C2=A0draft, which also doesn't define the error resp= onses.

It seems nothing links to it at all, at the= very least it does feel like 8414 technically would be the linked registry= addition or potentially the PAR RFC.

If we assume= the question is "Is invalid_client a valid error code in the authoriz= ation response" AND I assume authorization response includes the respo= nse to the pushed authentication request. Then my answer is yes.
= But if we assume the question is "Is invalid_client a valid error code= in the authorization redirect?" Then my answer is no.
Is the registry link wrong, I would= say yes.
I don't= know if this helps Emelia at all though :)

On Mon, Sep 21, 202= 6 at 9:26=E2=80=AFAM Thomas Broyer <t.broyer@gmail.com> wrote:

On Sun, Sep 20, 2026 at 6:59=E2=80=AFPM Warren Parad <wparad=3D40rhosys.ch@dmarc.= ietf.org> wrote:
Yes it's valid. No it isn't redirect= able.

Isn't this a bit cont= radictory?

The whole point of the Authorization En= dpoint (https://www.rfc-editor.org/info/rfc6749/#section-3.1) i= s to redirect to a Redirection Endpoint "after completing [=E2=80=A6] = interaction with the resource owner".
If invalid_client is n= ot redirectable, then it cannot be used by the authorization endpoint, as d= efined in RFC 6749.
Response types other than code or token (or r= ather, response modes other than fragment, query or form_post; but response= _mode is not defined in RFC 6749) could possibly use other means of returni= ng a response to the client that doesn't involve a redirect (such as th= e once/twice proposed response_mode=3Dweb_message) but then it would likely= be those that would register be linked from the registry in addition to RF= C 6749?

Or are you saying that the registry listin= g invalid_client for the authorization endpoint was specifically done in pr= evision for other response modes? (i.e. to not forbid them from using that = error code)
=C2=A0
On Sun, Sep 20, 2026, 18:= 37 Emelia S. <emelia=3D40brandedcode.com@dmarc.ietf.org> wrote:
Hi all,

In the OAuth Extensions Error Registry managed by IANA, invalid_client is l= isted as having a usage location of "token endpoint, authorization end= point", citing RFC6749, however, RFC6749's Section 4.1.2.1 "A= uthorization Code Grant -> Authorization Response -> Error Response&q= uot; does not list invalid_client.

https://www.iana.org/as= signments/oauth-parameters#extensions-error

I'm not sure where the IANA registry contents is from, given that RFC67= 49 does not include the initial registry contents. The only place invalid_c= lient is listed in RFC6749 is on the token endpoint.

Can someone clarify if `invalid_client` is valid for the authorization endp= oint and if that error is redirectable?

=E2=80=94 Emelia
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


--
--000000000000eca62d065bfdc2d7--