Registration: remove client_id query parameter from Read

[Former user]

The Client should simply do a GET on the registration_access_url in order to perform a client read. The server can, at its discretion, include the client_id as a query parameter or something else if it so chooses. The client shouldn't add any other parameters to this URL. The example should have the ?client_id=foo already built in to the URL to show that it can be done that way and to provide a good pattern.

The current text states that the client adds a client_id parameter:

To read the current configuration of the Client on the Authorization Server, the Client makes an HTTP GET request to the Client Registration Access Endpoint with the Registration Access Token, passing the client_id value as a query parameter.

http://openid.bitbucket.org/openid-connect-registration-1_0.html#ReadRequest

[John Bradley]

Yes it is up to the server to add the query parameter in the returned URI. The client shouldn't need to.
The counter argument is that it provides an extra check, however the check is easily made by examining the client_id in the response.

If we have people add it as a query parameter then the parameter name may collide as well.

Now that Justin mentions it in ticket #774 I moved the invalid client_id to read, Perhaps that is no longer an error in register or read, but only in the eventual update.

What are the possible read errors, No resource and not permitted I suspect.

[Former user]

Possible read errors are "no client there" and "no permission", though the first one should actually be subsumed by the second because the lack of a client SHOULD mean the lack of a valid registration_access_token to throw at the READ endpoint.

[Former user]

(edited issue to add reference to referenced text)

[Michael Jones]

OK, I agree with this removal. I haven't looked at the error recommendations above in detail, but I'll observe that in many cases, we can/should probably just be using the error values defined by OAuth Bearer (RFC 6749). But if those don't cover it, then yes, we can add some more.

[John Bradley]

Fixed #774 - removed invalid client_id and made GET return 403 Forbidden. Fixed missing registration_access_url in GET example response. Fixed #776 removed client adding client_id query paramater but make the examples include it as part of the registration_access_url. Fixed #775 Made redirects_uri, contacts, and default_acr_values arrays to match the examples.

→ <<cset e466c61c6037>>

[Former user]

I've added discussion notes to OAuth DynReg about the error responses so hopefully we can fix those there as well.