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] *On 
> Behalf Of *Manger, James H
> *Sent:* Tuesday, April 05, 2011 5:51 PM
> *To:* 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 1^st 
> 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
> https://www.ietf.org/mailman/listinfo/oauth