Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

[Eran Hammer-Lahav <eran at hueniverse.com>]

> -----Original Message-----
> From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
> Of Manger, James H
> Sent: Saturday, October 03, 2009 10:13 AM

> I think some of the disconnect between our ideas revolves around what a
> 'token' is.

Only in the sense that while technically correct, your proposal breaks existing expectations and browser behavior. Just the fact that servers will need to worry about the order of their authorization header in order to support both usernames and tokens on the same resource is to me a non-starter.

My point is only that the existing deployment of Basic prevents it from being used in the way you proposed because it is more likely to break things and does not offer any real benefit (other than a theoretical cleaner architecture), and less work for the spec editor.

> If we need BASIC for usernames and TOKEN PLAIN for delegation tokens,
> wont we also need something else for direct access by clients. Mightn't
> we need a different scheme for tokens issued by the OAuth web-
> delegation flow vs token issued via some other mechanism?

I agree that the scheme name (Token) isn't accurate and happy for other suggestions (such as 'Delegate', etc.). To me token implies some other credential in place of a username but I agree that this is not the common use of the word.

Direct access by clients does work well with existing username-based schemes because that's what it is - direct access. We have two distinct cases: direct access and delegated access. The issue is to have both direct access and delegated access coexist on the same resource.

> >> 2. A WWW-Auth scheme indicating that a web delegation flow can be
> used
> >> to get user authorization.
> 
> > I am not sure this is the right way to provide delegation discovery
> (via the auth header). Using Link: headers is much more appropriate.
> 
> A Link header might work. 1 or 2 extra round-trips could be avoid with
> a WWW-Auth scheme compared to a Link relation, as a WWW-Auth scheme
> could be more descriptive (more scheme-specific parameters) that seems
> sensible to cram into a Link relation.

I disagree that an auth scheme is more appropriate than Link. Link can be as easily extended. I do not consider providing discovery information about where credentials can be obtained as a valid 401 challenge. This is exactly what Link is for.
 
> >> ->  Authorization: MAC realm="whatever"; algorithm="HMAC-SHA256";
> 
> > The syntax differences from my proposal aren't significant.
> 
> Indeed, I wasn't suggesting any change here (other than "MAC" as a
> better scheme name).

I think the scheme name should reflect its specific delegation-related role, so MAC would be good generic as well.
 
> >> I think there is value in creating a family of authentication
> methods using a scheme and sub-scheme. It is better to support
> extensibility in the scheme than to force new methods to define new
> schemes. This will allow easier implementation of new sub-schemes.
> 
> So you want the "TOKEN" scheme to mean "delegation credentials", and
> the sub-scheme to be the authentication mechanism.
> I don’t think a special indicator for "delegation credentials" is
> necessary (use case?). If an indicator is necessary we should make it
> independent of the authentication mechanism: an extra parameter to add
> to existing WWW-Auth schemes; a special string to include in the realm
> values of existing WWW-Auth schemes; a separate HTTP response header
> identifying which WWW-Auth headers are meant for "delegation
> credentials"…

This is needed to work with existing deployments, and while I really like the idea of adding a parameter to existing schemes, it will not help with existing code which will simply ignore it and break.

> >> This isn't necessary. Just use BASIC.
> >> A server may need to ensure usernames and tokens can be
> distinguished,
> >> but that is easy enough.
> 
> > Yes it is. The idea of requiring servers to make this distinction is
> impractical. Basic auth is well defined and any attempt to overload it
> with new meaning is wrong.
> 
> Could you explain what is impractical?
> If a server really cannot distinguish tokens it chooses from usernames
> it can use separate URIs for the two groups.
> I don't think treating an OAuth token as a username, or a shared secret
> as a password is a "new meaning".

It means changing existing username platforms (many with strong backend integration with a login system) to first check for a pattern. It puts limitations on token design because of existing usernames. But the main issue is that it is very likely to break existing clients.

I don't think you have demonstrated the value of your proposal other than making the spec shorter. The deployment requirement you are proposing (order of auth headers, structure of tokens, duplication of resource URI based on access type) while possible, take away any value in reuse and are generally unacceptable to me.

EHL