While I'm mostly indifferent between #1 and #3, I cast my vote for #1 for the sake of garnering consensus.
Also, it seems important to some that the current specs be usable outside of OAuth. While I'm not convinced there are sufficient other use cases being examined to deliver the extra-OAuth value, I see no need limit these ambitions by choice of scheme name. I'm also assuming that if the larger HTTP or IETF community would have issue with how Auth scheme names are allocated (short vs. long, general vs. specific) there would be some regulatory measure in place to address that. As to the issue of backwards compatibility that William raises, my earlier proposal is in line with what Eran just proposed. Moreover, the value of a working group would seem to be that the community can work to consensus for the best possible design without (and particularly so) the burden of supporting pre-standard systems. On Feb 3, 2011, at 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
