Thanks James. Your feedback is a bit late as the draft I am working on how drops the challenge details completely, leaving only the indication that the server supports the Token scheme and using a realm to help the client figure out which token to use (if they have more than one suitable for this resource).
The reason why it makes little sense to have different schemes for different types of tokens is that it is not the protected resource's job to say which algorithm should be used, but the server when issuing the token for that resource. The draft did a poor job at separating the role of the server issuing the tokens from the role of the server providing access to resources. As a side note, 'class' was my placeholder parameter for replacing 'realm' (or at least suggesting that we take a look at that). Given the strong feeling here that there isn't really a current use case for servers issuing multiple tokens (of different properties) for a single realm and then allowing individual resources to reduce it to a smaller number of token types, there is no reason to go beyond 'realm'. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Manger, James H > Sent: Wednesday, February 03, 2010 5:14 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft > > Hello OAuthers, > > I have a couple of comments on the "Token Access Auth" draft. > > Initial impression (as Eran asked for): Yuck. > Now I will try to be a bit more constructive. > > This authentication draft breaks the existing model of HTTP authentication > too much. It puts a bunch of very different mechanisms (bearer, shared > secret, and public key crypto) into a single "Token" scheme. We should, > instead, have 1 scheme per mechanism, which is how HTTP auth has been > designed. > I agree with Dan Winship [email 2009-12-09] that a meta-scheme ("Token") > with multiple sub-schemes will not work well with existing code > architectures, which offer extensibility based on schemes, not based on any > other parts of a WWW-Authenticate header. > > > It looks like 'realm' has been replaced by 'class'. This is working against > the > existing model for HTTP auth, without a compelling reason. > > > A major rational for separating OAuth into Delegation and Authentication > documents was to recognize that they are logically independent. > Authentication needs an id (eg a token or user-id) and, optionally, a key -- > but has no dependence on delegation. Ideally, authentication specs would > not mention (OAuth-style) delegation at all. > The authentication draft is too strongly bound to delegation by trying to > package all authentication mechanisms that can be used with delegation > under a single scheme. This cannot work. > There will be other schemes: at lower layers, signature in the URI, signing > excluding the host name, using password-based key agreement, using > multiple round-trips, non-http protocols etc. > > > I am not against developing a mechanism to sign HTTP requests with a shared > secret. I think it is far less important for the OAuth working group than > specifying the delegation flows, and signalling. > > > My suggestions: > > 1. Define 1 very simple bearer scheme -- with no mention of delegation. > Don't include request signing in the same document. > Eg Authorization: ID a=<authorization-id> > (use "WRAP" and "wrap_access_token" as labels if you must) > > 2. Optionally, work on a mechanism to sign an HTTP request with a shared > secret without needing to exchange multiple messages with the server. > Ensure the mechanism can include 2 ids (authentication id and authorization > id), and a channel binding parameter. > > Plus the main part of the WG work: on delegation flows; server-to-client > signalling about how to do delegation (eg providing URI to redirect user to); > stating which hosts and/or URIs a token (and optional secret) can be used at; > working out how periodically refreshing credentials fits architecturally. > > > -- > James Manger > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Monday, 7 December 2009 7:28 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: [OAUTH-WG] Token Access Authentication Scheme Draft > > > > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > > > > This draft is my first attempt at defining a general purpose > > authentication scheme to fulfill the WG requirement to produce a scheme > > suitable for 2-legged authentication. It also supports the OAuth 3- > > legged use cases as discussed on the list. This draft is in very early > > stage and has been submitted early to help better facilitate the > > conversation. > > > > It has been hard for us to discuss ideas without a concrete proposal. I > > hope this will help and motivate people to participate and provide > > feedback and new ideas. While there are many holes in the draft, it > > should be pretty easy to follow it. > > > > Major changes from OAuth 1.0: > > > > * New auth scheme with new parameter names > > * Signature base string replaced with normalized request string, and > > now does not require *any* encoding > > * Supports multiple token classes, authentication methods, and coverage > > scope > > > > Main feedback requested: > > > > * Initial impressions - this is particularly important to get. Does the > > draft make sense? > > * Functionality - does it include all the requested/required > > functionality? > > * Abstraction level - do the attributes provide the right level of > > configuration and choice? > > > > Please refrain from editorial feedback at this point (grammar, typos, > > etc.), but do provide structural feedback. > > > > I plan to push an updated version by Wed which will incorporate as much > > feedback as I can. I plan to ask for the WG to promote this draft to a > > WG item within 2 weeks. > > > > Thanks, > > > > 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
