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
