Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 09:15:34 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Wednesday, June 01, 2011 11:43 AM

> Throughout the document, the various parameters (e.g., client_secret and
> client_id) are essentially undefined. There is no text about the length of
> these parameters, the allowable characters (e.g., alpha and digits only, all
> ASCII characters, full Unicode), internationalization considerations,
> preparation and comparison of strings, etc. I don't see how developers will
> build interoperable implementations without clear guidance here.

We have no consensus on string sizes.

I can add a note that all strings are UTF-8 encoded unless specified otherwise. Access tokens, for example, are defined by each profile.
 
> Also, the scope parameter still strike me as extremly vague. Can we at least
> define the word "scope" and provide a few examples of how the parameter
> might be used?

Please suggest text.

> No rules are provided for URI matching (e.g., in Section 4.1 the redirection
> URI received needs to be checked against the URI used to redirect the client,
> but not guidance is provided). Perhaps a reference to RFC 3986 is in order
> here. Here also internationalization concerns might need to be covered (e.g.,
> are IRIs allowed?).

Added reference to 3986. As to IRIs, as long as they are encoded as URIs, but last I checked, that was implicit by default.

> 4.1.2. Authorization Response
> 
> OLD:
>          If an
>          authorization code is used more than once, the authorization
>          server MAY revoke all tokens previously issued based on that
>          authorization code.
> 
> NEW:
>          If an
>          authorization code is used more than once, the authorization
>          server SHOULD revoke all tokens previously issued based on that
>          authorization code.
> 
> RATIONALE: MAY seems weak here.

This was changed to MAY because most large scale implementations will not be able to revoke access tokens at all (typically a self-encoded token good for one hour). A SHOULD would be good but impractical advice. I changed it to 'SHOULD attempt' for now.

> OLD:
>    The authorization server SHOULD issue access tokens with limited
>    scope and duration to clients incapable of authenticating.
> 
> NEW:
>    If the authorization server issues access tokens to clients
>    that are incapable of authenticating, the scope and duration of
>    such tokens SHOULD be limited.
> 
> RATIONALE: We're not actively RECOMMENDING authorization servers are to
> issue such tokens, are we?

I removed the sentence are a result of the wg discussion that followed.

> 10.3. Access Token Credentials
> 
>    The client SHOULD request access token credentials with the minimal
>    scope and duration necessary.
> 
> Is this enfoced by the authorization server?

Not sure how this would be possible. The server can later review what is being used, but not predict.

> 10.9. Authorization Codes
> 
>    Authorization codes SHOULD be short lived and MUST be single use.  If
>    the authorization server observes multiple attempts to exchange an
>    authorization code for an access token, the authorization server
>    SHOULD revoke all access tokens already granted based on the
>    compromised authorization code.
> 
> Is there a good reason why the authorization server would not revoke all the
> access tokens? If not, change to MUST.

See above.

Changed it to 'SHOULD attempt' for now.

> MINOR ISSUES...
> 
> 1.4.1. Authorization Code
> 
> OLD:
>    Before directing the resource owner back to the client with the
>    authorization code, the authorization server authenticates the
>    resource owner and obtains authorization.  Because the resource owner
>    only authenticates with the authorization server, the resource
>    owner's credentials are never shared with the client.
> 
> NEW:
>    Before directing the resource owner back to the client with the
>    authorization code, the authorization server authenticates the
>    resource owner and obtains authorization.  Because the resource owner
>    only authenticates with the authorization server, the resource
>    owner's credentials at the resource server are never shared with the
>    client.
> 
> RATIONALE: could the resource owner have credentials at the authorization
> server?

The credentials are always with the authorization server, and the resource server either has access to the credentials, to the server for validation, or relies on cookies and other non-standard credentials replacements.

> 4.1.2.1. Error Response
> 
> OLD:
>    error_description
>          OPTIONAL.  A human-readable text providing additional
>          information, used to assist in the understanding and resolution
>          of the error occurred. [[ add language and encoding information
>          ]]
> 
> NEW:
>    error_description
>          OPTIONAL.  Descriptive text providing additional information,
>          used to assist in the understanding and resolution of the
>          error that has occurred.  If included, it MUST be used only
>          to provide descriptive or diagnostic information that
>          supplements the meaning of an existing HTTP error code.  It
>          MUST NOT be interpreted programmatically by an application and
>          MUST NOT be used as the error message presented to a human
>          user, but MAY be used by application developers for debugging
>          purposes.
> 
> RATIONALE: If the error_description is not intended for humans and is to be
> used only by developers for debugging purposes, then we don't need
> language tags. (As explained in RFC 2277, "internationalization is for humans";
> yes, developers are people too...)

Is this much normative text necessary? We currently have:

                  OPTIONAL. A human-readable UTF-8 encoded text providing additional information,
                  used to assist the client developer in understanding the error that occurred.

> 4.2. Implicit Grant
> 
> This section uses the term "web server"; I suggest "resource server" for
> consistency.

Actually, this is not the resource server. I changed the term to web-hosted client resource to make it clear who is hosting this resource (the client).

> 8.1. Defining Access Token Types
> 8.2. Defining New Endpoint Parameters
> 
> Mention that the ALPHA and DIGIT rules come from RFC 5234.

I don't think this is necessary for rules coming directly from 5234 (which is referenced).

EHL