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 protected]] Sent: Friday, January 28, 2011 3:08 PM To: William Mills; [email protected] Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 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
