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
