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 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. 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). Does this make sense? EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Monday, April 19, 2010 10:06 AM > To: Eran Hammer-Lahav > Cc: Dick Hardt; OAuth WG > Subject: Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs > OAuth > > Isn't "Token" as a scheme to generic/ambiguous? > > If a protected resource accepts several types of Authorization headers, how > can it be sure this is an OAuth 2.0 token and not some other kind? > > If adding a version parameter is too verbose, how about "OAuth2" as > scheme? > > Marius > > > > On Sun, Apr 18, 2010 at 10:05 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > Scheme is always case-insensitive per 2617. > > > > > > > > My reasons for using Token: > > > > > > > > 1. The scheme isn't specific to OAuth (which defines a model for > > obtaining tokens). It is a generic way to use tokens for > > authentication. Similar to how services use OAuth today for "2-legged" > > authentication (using the signature method without an access token at > > all), I expect services to use the Token scheme. > > > > > > > > 2. Doesn't conflict with OAuth 1.0, and doesn't require adding > > oauth_version=2.0 to every request. The fact that 1.0 used a parameter > > name prefix in the *header* was bad enough. > > > > > > > > That discussion did not reach any consensus so I used the last > > proposed text. If people have a problem with that I'll add it to the > > open issues list. > > > > > > > > EHL > > > > > > > > > > > > > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Dick Hardt > > Sent: Sunday, April 18, 2010 9:33 PM > > To: OAuth WG > > Subject: [OAUTH-WG] Clarification: Authorization scheme :: Token vs > > OAuth > > > > > > > > I recall some earlier discussion on calling the scheme Token vs OAuth > > and see that it is now Token per the example: > > > > > > > > Authorization: Token token="vF9dft4qmT" > > > > > > > > Would explain or point out the logic of using Token rather than OAuth? > > > > > > > > A related question: is the scheme case sensitive? > > > > _______________________________________________ > > 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
