> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mark Kent
> Sent: Sunday, March 06, 2011 1:19 PM
> 1. The error response mechanism for the authorization endpoint depends on
> the response_type being requested. Assuming that the client and redirect
> URI are valid, the endpoint might place the error information in the query
> string (for repsonse_type "code", section 4.1.2.1) or in the fragment (for
> response type "token", section 4.2.2.1). I believe it is ambiguous what should
> be done if the response_type is missing, or invalid. Clarification would be
> appreciated.
I am not sure we can fully resolve this edge case. If the server only supports
one response type, it should default the error method to that. If it supports
both, it should default to the query, as the fragment will not always
accessible.
Added to the end of section 2.1:
If the request is missing the
REQUIRED "response_type" parameter (described in Section 4.1.1 and
Section 4.2.1), the authorization server SHOULD return an error
response as described in Section 4.1.2.1.
> 2. The error response for the authorization endpoint is directed to include
> the state, if a state were supplied in the request (sections 4.1.2.1,
> 4.2.2.1).
> Assuming that including multiple state parameters in the request makes the
> request malformed, how should the server include state in the error
> response if the request contains multiple state parameters? I could see
> justifications for a number of options (not including the state, including
> all the
> state parameters, including just the first state parameter, etc).
> Clarification
> would be appreciated. Note that, if multiple state parameters may be legally
> included in the request, this same question applies to the grant response,
> rather than the error response.
Parameters must not repeat so this will make the request malformed.
Added the following text to 2.1 and 2.2:
Request and response parameters MUST NOT repeat more than once,
unless noted otherwise.
Also, changed the 'state' parameter in error responses to:
state
REQUIRED if a valid "state" parameter was present in the client
authorization request. Set to the exact value received from
the client.
> 3. I believe that section 5.2 is ambiguous as to the error code that should be
> returned from the token endpoint when the client credentials are valid,
> when the client is authorized to use the authorization code grant type in
> general, but when the authorization code supplied is not valid for the
> client. I
> could see unauthorized_client being right, but the wording of the section
> doesn't include the exact case above. Please clarify.
Why not 'invalid_grant'? If I understand your use case, the client is trying to
use a code issued to another client, which makes the code invalid.
> 4. I believe that section 5.2 is ambiguous as to the error code that should be
> returned from the token endpoint when the grant type is "password", and
> the resource owner's credentials are invalid. Section 4.3.3 implies that such
> a
> request is "invalid", suggesting that invalid_request is the correct response,
> but section 5.2 could be clearer on this. Please clarify.
Same, ' invalid_grant'. The prose 'invalid request' is any error condition,
while the error code 'invalid_request' has specific definition.
> In addition, I wonder if the authors have given any thought to the
> applicability of the protocol in a federated authentication domain
> environment, for example where the authorization endpoint and token
> endpoints are on different servers that retain a trust relationship with each
> other. Clearly, in this case, the format of the authorization code is an
> integration point, much in the same way as the access token is in the
> currently provided use cases. Whereas a number of access token formats are
> provided in companion specifications, I see no references for authorization
> codes. Any thoughts on this would be gratefully received.
There is nothing to preclude this. It's just out of scope.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
