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: [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
