| That section's text is actually correct: if the AS doesn't support CIMD it's unlikely to know what the given client_id is, unless it uses OpenID Federation, in which case it'd error too since the document for a CIMD isn't compatible with the document OpenID federation requires.
So the "check the metadata" here means that you don't get an error on the authorize redirect to the AS from the RP, much like you should negotiate based on other AS metadata for client compatibility.
I think many CIMD errors would not be redirected, unless they satisfy the requirement of valid client_id and exact match on redirect_uri/s, at which point all the errors become redirected iirc?
So that's where I'm trying to find appropriate existing error codes before expanding scope of already registered error codes or creating new ones. Emelia
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. 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 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.
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 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 :)
Yes it's valid. No it isn't redirectable.
Isn't this a bit contradictory?
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) 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 -- [email protected]
To unsubscribe send an email to [email protected]
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
|
