First up, nice work with the latest version it¹s considerably easier to follow than previous version. Based on a simple attempt to implement a compliant authentication server, I have the following requests for clarification:
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. 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. 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. 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. 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. Mark.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
