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
