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>[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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
