Also #1
On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart <jh...@photobucket.com> wrote: > #1, which is nice to support the OAuth2 scheme as previously discussed > (Hunt, etc) as a legacy type (can be specified in a migration spec). > ---- > -- Justin Hart > -- jh...@photobucket.com > > > > > > On Feb 3, 2011, at 1:34 AM, Eran Hammer-Lahav wrote: > > 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 > > > <ATT00001..txt> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
