Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02

From: Mike Jones <[email-masked]>
Date: Fri, 28 Jan 2011 21:36:16 +0000

I've published draft 02 of the bearer token specification.  This incorporates consensus feedback received to date.  It contains no normative changes relative to draft 01.  Your feedback is solicited.  Specific changes were:

*         Changed terminology from "token reuse" to "token capture and replay".

*         Removed sentence "Encrypting the token contents is another alternative" from the security considerations since it was redundant and potentially confusing.

*         Corrected some references to "resource server" to be "authorization server" in the security considerations.

*         Generalized security considerations language about obtaining consent of the resource owner.

*         Broadened scope of security considerations description for recommendation "Don't pass bearer tokens in page URLs".

*         Removed unused reference to OAuth 1.0.

*         Updated reference to framework specification and updated David Recordon's e-mail address.

*         Removed security considerations text on authenticating clients.

*         Registered the "OAuth2" OAuth access token type and "oauth_token" parameter.

The draft is available at these locations:

*         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt

*         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml

*         http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

This version is explicitly not ready for working group last call, as changes may need to be made due to the open issues in the framework spec about the removal of the Client Assertion Credentials and OAuth2 HTTP Authentication Scheme.

                                                                -- Mike

---

From: William Mills <[email-masked]>
Date: Fri, 28 Jan 2011 14:54:24 -0800

I'd like to add my objection to using "OAuth2" as the scheme name for the access token.  It's confusing in my opinion.  I would much prefer (in my own order of preference): " oauth_bearer", "oauth2_bearer", or "bearer".  I think including OAuth in the name makes sense because it is defined in that context, but we've already talked about other possible token types.

Is there any argument in favor of simply using "OAuth2" that offsets the possible confusion and muddiness?

-bill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, January 28, 2011 1:36 PM
To: [email-masked]
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Fri, 28 Jan 2011 23:08:21 +0000

The argument in favor of "OAuth2" is a consistency argument.  Just as this parameter was called "WRAP" in the WRAP spec and called "OAuth" in the OAuth specs through draft 10 until it was moved to the OAuth2 bearer token spec, it should logically be called "OAuth2" to remain consistent with the precursor specifications.  Also, since the use of bearer tokens is the primary OAuth2 use case (it was the motivating use case for WRAP, which was the reason for a second version of OAuth in the first place), it makes sense for this primary use case bear the primary specification name.

I'm not religious about this (I already asked for working group on this topic a while ago and received very little), but absent a clear working group consensus to change the name, as editor, I believe that it's my job to not introduce breaking changes at this point in the specification development cycle.

                                                                Cheers,
                                                                -- Mike
From: William Mills [mailto:[email-masked]]
Sent: Friday, January 28, 2011 2:54 PM
To: Mike Jones; [email-masked]
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02

-bill

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 28 Jan 2011 16:10:17 -0700

Remove the oauth_token parameter registration. It has nothing to do with the token endpoint.

EHL

On Jan 28, 2011, at 13:36, "Mike Jones" <[email-masked]<mailto:[email-masked]>> wrote:

I’ve published draft 02 of the bearer token specification.  This incorporates consensus feedback received to date.  It contains no normative changes relative to draft 01.  Your feedback is solicited.  Specific changes were:

·         Changed terminology from "token reuse" to "token capture and replay".

·         Removed sentence "Encrypting the token contents is another alternative" from the security considerations since it was redundant and potentially confusing.

·         Corrected some references to "resource server" to be "authorization server" in the security considerations.

·         Generalized security considerations language about obtaining consent of the resource owner.

·         Broadened scope of security considerations description for recommendation "Don't pass bearer tokens in page URLs".

·         Removed unused reference to OAuth 1.0.

·         Updated reference to framework specification and updated David Recordon's e-mail address.

·         Removed security considerations text on authenticating clients.

·         Registered the "OAuth2" OAuth access token type and "oauth_token" parameter.

·         <http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt

·         <http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml

·         <http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html

·         <http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt

·         <http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml

·         <http://svn.openid.net/repos/specifications/oauth/2.0/> http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

                                                                -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Fri, 28 Jan 2011 15:59:45 -0800

At that point though we did not have multiple token types.  Now that we do we should make the naming scheme reflect that.  OAuth2 implies "the one and only".

From: Mike Jones [mailto:[email-masked]]
Sent: Friday, January 28, 2011 3:08 PM
To: William Mills; [email-masked]
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02

                                                                Cheers,
                                                                -- Mike

-bill

                                                                -- Mike

---

From: Skylar Woodward <[email-masked]>
Date: Sun, 30 Jan 2011 20:36:26 +0100

Representing a provider who will be issuing both bearer and mac token types, I'll state a preference on behalf of clarity for our developers to use the "oauth_" prefix for both specifications. Both types will be referred to as "OAuth" tokens in developer documentation regardless of specification history or independence-by-extension, so having "OAuth Bearer Tokens" identified as "OAuth2" and "OAuth Mac Tokens" identified by "MAC" is mildly confusing, thought nowhere near impossible for implementers to manage. On the plus side, it adds extra value as slide-ware during future OAuth talks where 
	
	"OAuth Bearer" -> "OAuth2"
	"OAuth MAC" -> "MAC"

As I don't understand all the implications or the processes of the working groups regarding such a change, take the feedback for what you perceive its worth to be.

Though a breaking change, a simple consideration for a provider who has already supported this is to accept both "OAuth2" and the revised standard as identifiers for backwards compatibility.  Given the current volatility of the token drafts, this is already a consideration we've made.

On Jan 29, 2011, at 12:59 AM, William Mills wrote:

> At that point though we did not have multiple token types.  Now that we do we should make the naming scheme reflect that.  OAuth2 implies “the one and only”.
>  
> The argument in favor of “OAuth2” is a consistency argument.  Just as this parameter was called “WRAP” in the WRAP spec and called “OAuth” in the OAuth specs through draft 10 until it was moved to the OAuth2 bearer token spec, it should logically be called “OAuth2” to remain consistent with the precursor specifications.  Also, since the use of bearer tokens is the primary OAuth2 use case (it was the motivating use case for WRAP, which was the reason for a second version of OAuth in the first place), it makes sense for this primary use case bear the primary specification name.
>  
> I’m not religious about this (I already asked for working group on this topic a while ago and received very little), but absent a clear working group consensus to change the name, as editor, I believe that it’s my job to not introduce breaking changes at this point in the specification development cycle.
>  
>                                                                 Cheers,
>                                                                 -- Mike
>  
> I’d like to add my objection to using “OAuth2” as the scheme name for the access token.  It’s confusing in my opinion.  I would much prefer (in my own order of preference): “ oauth_bearer”, “oauth2_bearer”, or “bearer”.  I think including OAuth in the name makes sense because it is defined in that context, but we’ve already talked about other possible token types. 
>  
> Is there any argument in favor of simply using “OAuth2” that offsets the possible confusion and muddiness?
>  
> -bill
>  
> ·         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt
> ·         http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml
> ·         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html
> ·         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt
> ·         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml
> ·         http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)
>  
> [email-masked]