[OAUTH-WG] Re: Possibly incorrect IANA registry contents for Error Registry

[Warren Parad <[e-mail]>]

Interestingly in your draft this section has a similar mistake
https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-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 PM emelia <[e-mail]> wrote:

> I think I'd be okay with the IANA registry being updated to also reference
> 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 have
> 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 <[e-mail]> wrote:
>
> 
> 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
> <https://www.rfc-editor.org/info/rfc6749/#section-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
> <https://www.rfc-editor.org/info/rfc9126/#section-2.3>), 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
> <https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html> draft,
> 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 AM Thomas Broyer <[e-mail]> wrote:
>
>>
>>
>> On Sun, Sep 20, 2026 at 6:59 PM Warren Parad <wparad=
>> [e-mail]> 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 […] interaction with the 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 RFC
>> 6749) could possibly use other means of returning a response to the client
>> that doesn't involve a redirect (such as the once/twice proposed
>> response_mode=web_message) but then it would likely be those that would
>> 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. <emelia=
>>> [e-mail]> 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?
>>>>
>>>> — Emelia
>>>> _______________________________________________
>>>> OAuth mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> OAuth mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>>
>> --
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/
>> <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
>>
>