Hello Mike, Given the spec is still a draft and most existing implementations are not in production stage, it seems that changing the name of the bearer scheme from OAuth2 to Bearer is not going to have a big impact.
With a small change, we are going to have a clearer and more descriptive scheme name, and most importantly, it preserves the fairness to other current (and future) schemes by not promoting a specific scheme. Regards, Franklin -------------------------------------------------- From: "Mike Jones" <[email protected]> Date: Friday, 04 February, 2011 01:19 To: "Eran Hammer-Lahav" <[email protected]>; "OAuth WG" <[email protected]> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: 2/10) > I realize that spec stability doesn't matter to you, but that doesn't mean > that it's not important to others, including those actually using the specs. > Call that a "process" argument if you want, but that doesn't make it any less > pertinent - the "technical" argument is that breaking changes break > implementations. > > I already did vote below -- for option 4. > > From: Eran Hammer-Lahav [mailto:[email protected]] > Sent: Thursday, February 03, 2011 9:14 AM > To: Mike Jones; OAuth WG > Subject: RE: Bearer token type and scheme name (deadline: 2/10) > > All these suggestions were posted to the list by members (Marius, William, > James, Justin). Nothing here is new. If you disagree with my analysis of any > of the points, please raise your *technical* concerns. Trying to use process > arguments is simply not going to fly. > > Pick an option, provide a new option (with full analysis), or don't vote. > > EHL > > > From: Mike Jones [mailto:[email protected]] > Sent: Thursday, February 03, 2011 8:20 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: Bearer token type and scheme name (deadline: 2/10) > > This seems like an overly complex characterization - especially because > you're including hypothetical choices such as schemes and sub-schemes that > don't provide substantial benefits over the straightforward schemes we have > now and would complicate implementations and people's understanding of the > spec, and that don't have substantial support within the working group. > > Given that we're trying to bring the specs to working group last call, I > would personally vote no to introducing any further any breaking changes. > > -- Mike > > From: [email protected] [mailto:[email protected]] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
