Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Monday, April 19, 2010 2:07 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs
> OAuth
> 
> On Mon, Apr 19, 2010 at 11:06 AM, Eran Hammer-Lahav
> <[e-mail]> wrote:
> > Initially I don't think it is a problem because only OAuth 2 servers will use it.
> Later it becomes a question of discovery and what you do once you get such
> a challenge from a server you are unfamiliar with.
> 
> I think that many protected resource that will support OAuth 2 will also
> support other protocols, at least OAuth 1.0.

Ok. Don't see how this is relevant. Each will use its own WWW-Authenticate header.

> > I proposed Token because it is in line with other HTTP authentication
> schemes: Basic and Digest.
> >
> > The name really doesn't matter that much, but I rather not use OAuth (to
> avoid the need to add oauth_version=2.0 to every header), and I rather not
> use a version number in the scheme name. If you don't like Token, feel free
> to suggest something else. I think it is very accurate to what is being done.
> 
> Being so generic at some point it may require a parameter to tell what type
> of token is this. At that point I think that OAuth with a version or OAuth2 is
> better.

Same is true if we call it OAuth and someone will try to use it for something else. The exact thing happened with 1.0 with the so-called 2-legged use case. It had nothing to do with the original use case of the spec, but people found it very useful. At some point you have to use some form of discovery.

> > Also keep in mind that there are going to be other flows issuing tokens, and
> we already have both delegation and autonomous flows using the same
> scheme. So calling it OAuth doesn't really tell much more than Token. If I use
> a new flow to get a token, it doesn't really matter what happens as long as I
> end up with a token (with or without a secret).
> 
> True, but I don't think we are trying to solve token based authentication in
> general.

Actually, we are chartered to do just that [1]:

"The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio)."

We can define an OAuth scheme and then another Token scheme. I just don't see the point.

EHL

[1] http://datatracker.ietf.org/wg/oauth/charter/