+1 #1 On Feb 3, 2011, at 3:21 PM, Brian Campbell wrote:
> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
