(How pleasant it is to agree with everyone!)
+1
Igor
William Mills wrote:
+1 for reserving the legacy behavior as well.
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Phil Hunt
Sent: Thursday, February 03, 2011 10:15 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
2/10)
BTW, if you vote for #1, OAUTH2 could be reserved for legacy behaviour.
Phil
phil.h...@oracle.com
On 2011-02-03, at 10:10 AM, Peter Saint-Andre wrote:
With my individual contributor hat on, I too prefer #1 -- it's just a
lot cleaner to my mind.
On 2/3/11 6:41 PM, David Recordon wrote:
Also #1. While I feel for existing implementations of "OAuth2" by
itself, it's not the best name for this specific piece of
functionality and Facebook too has a final migration server side to
make for other features in the spec which weren't finalized when we
implemented them.
On Thu, Feb 3, 2011 at 8:42 AM, William Mills <wmi...@yahoo-inc.com>
wrote:
I'm coming around to #1, I'll put my vote there. I do agree that
we have
usage out there of the OAuth2 scheme and we need not to break that,
how do
we solve that?
From: 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
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
