[Openid-specs-ab] [openid/connect] Basing Client Registration Error Responses entirely on draft-ietf-oauth-v2-bearer is very awkward (issue #642)

Brian Campbell issues-reply at bitbucket.org
Wed Aug 8 22:36:12 UTC 2012


--- you can reply above this line ---

New issue 642: Basing Client Registration Error Responses entirely on draft-ietf-oauth-v2-bearer is very awkward
https://bitbucket.org/openid/connect/issue/642/basing-client-registration-error-responses

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


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


More information about the Openid-specs-ab mailing list