+1 for reserving the legacy behavior as well.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Phil Hunt > Sent: Thursday, February 03, 2011 10:15 AM > To: Mike Jones > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour. > > Phil > phil.h...@oracle.com > > > > > On 2011-02-03, at 10:10 AM, Peter Saint-Andre wrote: > > > With my individual contributor hat on, I too prefer #1 -- it's just a > > lot cleaner to my mind. > > > > On 2/3/11 6:41 PM, David Recordon wrote: > >> Also #1. While I feel for existing implementations of "OAuth2" by > >> itself, it's not the best name for this specific piece of > >> functionality and Facebook too has a final migration server side to > >> make for other features in the spec which weren't finalized when we > >> implemented them. > >> > >> > >> On Thu, Feb 3, 2011 at 8:42 AM, William Mills <wmi...@yahoo-inc.com> > wrote: > >>> I'm coming around to #1, I'll put my vote there. I do agree that > we have > >>> usage out there of the OAuth2 scheme and we need not to break that, > how do > >>> we solve that? > >>> > >>> > >>> > >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf Of > >>> Eran Hammer-Lahav > >>> Sent: Thursday, February 03, 2011 12:34 AM > >>> To: OAuth WG > >>> Subject: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > >>> > >>> > >>> > >>> After a long back-and-forth, I think it is time to present a few > options and > >>> have people express their preferences. > >>> > >>> > >>> > >>> These are the options mentioned so far and their +/-: > >>> > >>> > >>> > >>> 1. Descriptive, non-OAuth-specific scheme names (Bearer, MAC) > >>> > >>> > >>> > >>> Each token type gets its own name (which does not include the word > 'oauth' > >>> in it), as well as a matching HTTP authentication scheme if a new > one is > >>> being defined. > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - works cleanly with the HTTP authentication framework by simply > defining > >>> new methods or reusing existing ones. > >>> > >>> - schemes can be used outside the OAuth authorization flow (e.g. 2- > legged > >>> OAuth 1.0 use cases). > >>> > >>> - all schemes are presented equally without giving any a preferred > >>> treatment. > >>> > >>> - built-in discovery using 401 challenge header for which schemes > are > >>> supported (with their respective information). > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - potential creation of many new HTTP authentication schemes which > has been > >>> stable for a long time. > >>> > >>> > >>> > >>> 2. Single OAuth2 scheme with sub-schemes > >>> > >>> > >>> > >>> Define a single authentication scheme for all token types with some > >>> attribute used to detect which scheme is actually being used. > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - single scheme, reuse of the 1.0 pattern. > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - requires a new registry for authentication header parameters. > >>> > >>> - schemes are not easily reusable outside OAuth. > >>> > >>> - existing frameworks usually switch on scheme name, not on sub > scheme, > >>> which will cause difficulty in some deployments. > >>> > >>> - potential to produce a very complicated scheme once many sub > schemes are > >>> added. > >>> > >>> - requires its own discovery method for which schemes are > supported. > >>> > >>> > >>> > >>> 3. Name prefix (e.g. oauth2_bearer) > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - makes the protocol a bit easier to newbies since it will look all > >>> inclusive (authorization and authentication). > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - makes reuse outside OAuth awkward without any technical benefit. > >>> > >>> > >>> > >>> 4. OAuth2 for bearer, MAC for mac > >>> > >>> > >>> > >>> Name the bearer token 'OAuth2' and everything else gets a different > name > >>> (with or without OAuth in it). > >>> > >>> > >>> > >>> Benefits: > >>> > >>> > >>> > >>> - Matches current draft. > >>> > >>> > >>> > >>> Downsides: > >>> > >>> > >>> > >>> - Elevates bearer token to the preferred token type, instead of > promoting > >>> comparison of the various token types available. > >>> > >>> - Creates a very odd usage where the authorization server issues an > access > >>> token of type 'OAuth2' which is non-descriptive and very confusing > (since > >>> there are other token types). > >>> > >>> - Uses the name OAuth2 which stands for authorization in an > authentication > >>> flow, continuing the confusion about what OAuth is (an > authorization > >>> protocol). > >>> > >>> > >>> > >>> --- > >>> > >>> > >>> > >>> Please reply with your preference by 2/10. As always, please > provide > >>> feedback on the options and analysis. > >>> > >>> > >>> > >>> EHL > >>> > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
