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:e...@hueniverse.com] 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:michael.jo...@microsoft.com] 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: 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
