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 >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
