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

[Peter Saint-Andre <[e-mail]>]

Last week I completed a review of draft-ietf-oauth-v2-16. Here are some
comments.

MAJOR ISSUES...

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.

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?

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?).

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.

10.2. Client Impersonation

   The authorization server SHOULD require the client to pre-register
   its redirection URI and validate the value of the "redirect_uri"
   against the pre-registered value.

How does this validation occur?

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?

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?

10.6. Endpoints Authenticity

   In order to prevent man-in-the-middle and phishing attacks, the
   authorization server MUST implement and require TLS with server-side
   authentication in all exchanges.  The client MUST verify the
   authorization server's TLS certificate, as well as the respective
   certificate chain.

We need a reference to RFC 2818 here since it defines server
verification procedures for HTTP. (Same for Section 10.8.)

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.

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?

1.4.2. Implicit

OLD:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since it reduces the number of round trips required to obtain an
   access token.

NEW:
   Implicit grants improve the responsiveness and efficiency of some
   clients (such as a client implemented as an in-browser application)
   since they reduce the number of round trips required to obtain an
   access token.  However, service providers need to weigh this
   convenience against the security properties of implicit grants
   (e.g., the fact that client authentication is not possible).

RATIONALE: I think it would be good to mention that there's a balance
here between convenience and security.

1.7 Notational Conventions

I think it would be good to add an informational reference to RFC 4949
here, and to check our usage of certain terms against the definitions in
that spec. Proposed text:

   Certain security-related terms are to be understood in the sense
   defined in [RFC4949]; such terms include, but are not limited to,
   "attack", "authentication", "authorization", "certificate",
   "confidentiality", "credential", "encryption", "identity",
   "sign", "signature", "trust", "validate", and "verify".

2.1. Authorization Endpoint

OLD:
   Request and response parameters MUST NOT repeat more than once,
   unless noted otherwise.

NEW:
   Request and response parameters MUST NOT be included more than once,
   unless noted otherwise.

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

4.2. Implicit Grant

This section uses the term "web server"; I suggest "resource server" for
consistency.

7.1. Access Token Types

OLD:
   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand the token
   type.

NEW:
   The access token type provides the client with the information
   required to successfully utilize the access token to make a protected
   resource request (along with type-specific attributes).  The client
   MUST NOT use an access token if it does not understand or does not
   trust the token type.

RATIONALE: An application could understand a given token type but not
trust it (or not trust it from the sender).

8.1. Defining Access Token Types
8.2. Defining New Endpoint Parameters

Mention that the ALPHA and DIGIT rules come from RFC 5234.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/