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 protected]]
Sent: Friday, January 28, 2011 2:54 PM
To: Mike Jones; [email protected]
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02
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 protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Friday, January 28, 2011 1:36 PM
To: [email protected]
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02
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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
