Re: [OAUTH-WG] draft-15 editorials

[Eran Hammer-Lahav <[e-mail]>]

Done.

EHL

Ps. I like 1974.

From: [e-mail] [mailto:[e-mail]] On Behalf Of Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: [e-mail]
Subject: [OAUTH-WG] draft-15 editorials

A few, mainly editorial, points on the latest OAuth 2.0 core draft [draft-ietf-oauth-v2-15]:

Abstract: Currently it is:
   The OAuth 2.0 authorization protocol enables granting third-party
   applications limited access to HTTP service on behalf of an end-user
   by orchestrating an approval interaction between the end-user and the
   HTTP service.
This sentence is confusing as to whom is doing the orchestrating. It is an important OAuth feature that the 3rd-party app does this. Also add "an" before "HTTP service".
   The OAuth 2.0 authorization protocol enables a third-party application
   to obtain limited access to an HTTP service on behalf of an end-user
   by orchestrating an approval interaction between the end-user and the
   HTTP service.


2.1 Authorization Endpoints

  ...when sending requests to the token endpoints
should be

  ...when sending requests to the authorization endpoint


7.1 Access Token Types
I suggest adding the following sentence to the end of the 1st paragraph, just to be sure a security value is not used in the wrong protocol.
   A client MUST NOT use an access token if it does not understand the token type.


7.1 Access Token Types
Use a different access token for the Bearer and MAC examples to avoid any implication that a given token can be used with either method at the client's discretion. Perhaps make the example Bearer token a bit longer. The current example value has at most 72 bits of entropy that doesn't match the 128-bits required in draft-lodderstedt-oauth-security-01#section-5.1.4.2.2.
   Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw


7.1 Access Token Types
The timestamp value in the MAC example corresponds to a date in 1974!


--
James Manger