Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth
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
Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth
On Mon, Apr 19, 2010 at 11:06 AM, Eran Hammer-Lahav e...@hueniverse.com 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. 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. 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. Marius 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
Re: [OAUTH-WG] Clarification: Authorization scheme :: Token vs OAuth
-Original Message- From: Marius Scurtescu [mailto:mscurte...@google.com] 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...@hueniverse.com 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/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[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
