Subject: [OAUTH-WG] draft-15 editorials

From: "Manger, James H" <[email-masked]>
Date: Wed, 6 Apr 2011 10:51:23 +1000

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Apr 2011 00:57:00 +0000

Also, change "which in turns directs" to "which in turn directs".

                                                                -- Mike

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

7.1 Access Token Types

7.1 Access Token Types

7.1 Access Token Types

--
James Manger

---

From: Paul Madsen <[email-masked]>
Date: Wed, 06 Apr 2011 06:59:52 -0400

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:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Manger, James H
> *Sent:* Tuesday, April 05, 2011 5:51 PM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] draft-15 editorials
>
> *Abstract*: Currently it is:
>
> 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".
>
> *2.1 Authorization Endpoints*
>
> *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.
>
> *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.
>
> *7.1 Access Token Types*
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Apr 2011 07:36:34 -0700

Can you propose text?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Madsen
Sent: Wednesday, April 06, 2011 4:00 AM
To: [email-masked]
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

                                                                -- Mike

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

7.1 Access Token Types

7.1 Access Token Types

7.1 Access Token Types

--
James Manger

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Apr 2011 07:40:44 -0700

Done.

EHL

Ps. I like 1974.

7.1 Access Token Types

7.1 Access Token Types

7.1 Access Token Types

--
James Manger

---

From: Paul Madsen <[email-masked]>
Date: Wed, 06 Apr 2011 11:14:52 -0400

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:
> Behalf Of *Paul Madsen
> *Sent:* Wednesday, April 06, 2011 4:00 AM
> *To:* [email-masked]
> *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
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Manger, James H
> *To:* [email-masked] <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 7 Apr 2011 13:15:23 +1000

Paul,

The draft-15.1 abstract is just the first sentence of the abstract I suggested last month [http://www.ietf.org/mail-archive/web/oauth/current/msg05693.html and below]. The rest covered OAuth's other major aspect: issuing temporary credentials that resource servers can handle, while a separate service can handle permanent or exotic credentials (eg assertions). Does it fit what you were after?

Your "directly negotiate access" phrase hints that there is more to OAuth 2 than delegation, but I'm not sure that it explains it.

--

James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Madsen
Sent: Thursday, 7 April 2011 1:15 AM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-15 editorials

Proposed text

The OAuth 2.0 authorization protocol enables a third-party application to 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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, 17 March 2011 1:40 PM
To: OAuth WG
Subject: [OAUTH-WG] OAuth2 abstract

Comments on draft-ietf-oauth-v2-13:

1. Abstract

The 1-line abstract is not helpful - it merely repeats the title. The abstract is important as it is the text most widely seem around the rest of the IETF community (eg in announcements of drafts and RFCs) and beyond. It needs to mention: users delegating access to applications; applications orchestrating that delegation; swapping permanent credentials for short-lived access tokens; and that it uses HTTP. Here is my suggestion:

  "The OAuth 2.0 authorization protocol allows an application to gain
  limited permission to access an HTTP service on behalf of a user by
  orchestrating an approval interaction between the user and the service.
  OAuth 2.0 uses temporary credentials, issued by an HTTP service either
  directly to an application or to represent user-delegated permissions.
  A collection of HTTP services can accept temporary credentials without
  needing to handle long-term user or application credentials, which
  can be restricted to a secure service that issues the temporary
  credentials."

I think this text can be understood without knowing any of the specialised terms introduced later in the specification.

--

James Manger

---

From: Paul Madsen <[email-masked]>
Date: Thu, 07 Apr 2011 09:14:30 -0400

Hi James, sorry I didnt see your earlier suggestion.

And your text works for me - just looking for text that hints at 
something beyond delegation

thanks

paul

On 4/6/11 11:15 PM, Manger, James H wrote:
>
> Paul,
>
> The draft-15.1 abstract is just the first sentence of the abstract I 
> suggested last month 
> [http://www.ietf.org/mail-archive/web/oauth/current/msg05693.html and 
> below]. The rest covered OAuth's other major aspect: issuing temporary 
> credentials that resource servers can handle, while a separate service 
> can handle permanent or exotic credentials (eg assertions). Does it 
> fit what you were after?
>
> Your "directly negotiate access" phrase hints that there is more to 
> OAuth 2 than delegation, but I'm not sure that it explains it.
>
> --
>
> James Manger
>
> *Sent:* Thursday, 7 April 2011 1:15 AM
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]
> to obtain limited access to an HTTP service, either on behalf of an 
> directly 'negotiate', on its own behalf, such access with the HTTP 
> service.
>
> *Sent:* Thursday, 17 March 2011 1:40 PM
> *To:* OAuth WG
> *Subject:* [OAUTH-WG] OAuth2 abstract
>
> 1. *Abstract*
> The 1-line abstract is not helpful -- it merely repeats the title. The 
> abstract is important as it is the text most widely seem around the 
> rest of the IETF community (eg in announcements of drafts and RFCs) 
> and beyond. It needs to mention: users delegating access to 
> applications; applications orchestrating that delegation; swapping 
> permanent credentials for short-lived access tokens; and that it uses 
> HTTP. Here is my suggestion:
>
> I think this text can be understood without knowing any of the 
> specialised terms introduced later in the specification.
>
> --
>
> James Manger
>