This is where we stand so far: Option 1 -- 14 votes
William Mills Eran Hammer-Lahav Franklin Tse David Recordon Peter Saint-Andre Phil Hunt Skylar Woodward Michael Adams Igor Faynberg Justin Hart Brian Campbell Luke Shepard James Manger Minoo Hamilton Option 2 -- 1 vote Marius Scurtescu (or #3) Option 3 -- 1 vote Torsten Lodderstedt (or #1) Option 4 -- 3 votes Mike Jones Brian Eaton (??) Dirk Balfanz Option #1 has clear support. However, given my strong feeling on the subject, it is only fair that those voting for other options get to decide if they are willing to let #1 stand as the working group consensus, or would like to continue this debate in hope of a different result. Mike, Brian, Dirk, and Marius - can you live with #1? EHL 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
