Registration- 2.3 Basing Client Registration Error Responses entirely on draft-ietf-oauth-v2-bearer is very awkward

[Brian Campbell]

§2.3 of Client Registration [1] defines all error responses from the Client Registration Endpoint such that they use the the mechanisms defined in §3 of The OAuth 2.0 Authorization Framework: Bearer Token Usage [2]. But the latter document "describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources" (from the abstract) while most of the error conditions in Client Registration have nothing to do with bearer access tokens and are application level errors. This is (to me anyway) a mixing of concerns and really awkward.

For one example, should an attempted client registration request that requires no authentication of any kind (such a request is a SHOULD per §2 [3]) that has a typo in the type parameter really get back a response with an HTTP header (WWW-Authenticate: Bearer) indicating an authentication challenge? That's what the specification would currently require. It just seems wrong from the spec design perspective and it might even result in unexpected and unintended behavior from HTTP clients that attempt to automatically deal with WWW-Authenticate challenges.

It makes sense to defer to error responses in draft-ietf-oauth-v2-bearer for problems with the optional access token. But errors specifically related to the client registration exchange should be handled differently.

The existing error codes and error_description defined in §2.3 perhaps could just be returned as parameters in the JSON object returned and an HTTP 400 status code. (That would also avoid needing to register those 4 new error codes in the OAuth Extensions Error Registry, the lack of which seems like an oversight in the current document).

[1] http://openid.net/specs/openid-connect-registration-1_0.html#anchor7 [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-23#section-3 [3] http://openid.net/specs/openid-connect-registration-1_0.html#anchor2

[Brian Campbell]

Here's a non normative example of what that might look like in:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store


{
 "error":"invalid_type",
 "error_description":"The value of the type parameter must be one of client_associate, rotate_secret or client_update."
}

in response to curl -k -v 'https://localhost:9031/idp/client-registration.openid' -d 'type=client_associated&redirect_uris=https://some.url.ca&application_name=Automatic Super Machine'

[John Bradley]

Fixes #642 - Registration separates application errors from bearer.

→ e7bacc33c978

[John Bradley]

RE #642 error_description

→ ffa348c0cc91

[John Bradley]

Re #642 change error to error_code in 2.3 example

→ <<cset 66de3843dda8>>