Subject: [OAUTH-WG] draft-ietf-oauth-v2-13 comments

From: Mark Kent <[email-masked]>
Date: Sun, 06 Mar 2011 13:18:43 -0800

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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 15:45:19 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Kent
> Sent: Sunday, March 06, 2011 1:19 PM

> 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.
 
> 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,
> 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.

> 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

There is nothing to preclude this. It's just out of scope.

EHL

---

From: Mark Kent <[email-masked]>
Date: Thu, 24 Mar 2011 16:42:34 -0700

>> be
>> client. I
> 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.

It wasn't clear to me, when combining the last paragraph in section 4.1.3
with section 5.2 that the code not matching the client meant that the code
was invalid. While you intend the term "invalid" in the context of a
code/grant (in, e.g. Section 5.2) to be a general catch-all for errors, I
missed that when reading the document. Perhaps a quick nod to this concept
somewhere in either section 1.4 or 5.2 might have helped me out.

Thanks for the other answers - quite clear.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 25 Mar 2011 00:44:52 -0700

Changed 'invalid_grand' to:

                  The provided authorization grant is invalid, expired, revoked, does not match the
                  redirection URI used in the authorization request, or was issued to another client.

EHL

> From: Mark Kent [mailto:[email-masked]]
> Sent: Thursday, March 24, 2011 4:43 PM
> To: Eran Hammer-Lahav; [email-masked]
> Subject: Re: draft-ietf-oauth-v2-13 comments
> 
> >> 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
> > 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.
> 
> It wasn't clear to me, when combining the last paragraph in section 4.1.3 with
> section 5.2 that the code not matching the client meant that the code was
> invalid. While you intend the term "invalid" in the context of a code/grant (in,
> e.g. Section 5.2) to be a general catch-all for errors, I missed that when
> reading the document. Perhaps a quick nod to this concept somewhere in
> either section 1.4 or 5.2 might have helped me out.
>