Proposed text
The OAuth 2.0 authorization protocol enables a third-party applicationto
obtain limited access to an HTTP service, either on behalf of an
end-user by orchestrating an approval interaction between the end-user
and the HTTP service, or by allowing the third-party application to
directly 'negotiate', on its own behalf,such access with the HTTP service.
And I acknowledge the concerns that 'negotiate' might create, thus the
air quotes ....
paul
On 4/6/11 10:36 AM, Eran Hammer-Lahav wrote:
Can you propose text?
EHL
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@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 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
