Re: [OAUTH-WG] draft-15 editorials

Can you propose text?

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Paul Madsen
Sent: Wednesday, April 06, 2011 4:00 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-15 editorials

Can we not acknowledge in the abstract that there are other applications for OAuth beyond the delegated authz scenario?

I tell people that OAuth 2 is more a framework than a specific protocol, but the current abstract belies this claim.

paul

On 4/5/11 8:57 PM, Mike Jones wrote:
Also, change "which in turns directs" to "which in turn directs".

                                                                -- Mike

From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, April 05, 2011 5:51 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
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

_______________________________________________

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth