Thanks William. It is important to differentiate between style and substance (both of which are very important to people).
Style-wise, we can use either of the three options below, but they are essentially the same. You take the string and put it through a parser and end up with the actual scheme name and some attributes. I don't really buy the arguments about namespaces and pollution. Creating a super scheme that then has to be extended for sub-schemes is actually a lot more complex. AFAIK, all the existing HTTP authentication schemes are not extensible (or at least have not been extended). There is something very helpful in moving extensibility out of the scheme so that a client that can speak it today can also speak it 10 years from now. If you need new options, create a new scheme. I like the scheme-per-type approach because it is modular and does not require much coordination. The lack of consensus we've seen between bearer tokens and mac tokens is an example. I don't want to have to negotiate parameter names and other formats when such collaboration will just slow both efforts and lead to no meaningful interoperability (given that the two token types are completely incompatible). The HTTP authentication headers are named poorly. The WWW-Authenticate means 'you need to authenticate' and the Authorization header means 'here is my authentication credentials'. There is no actual authorization as implemented by OAuth (in terms of third party and grants). When talking about using a token to access a protected resource, we are dealing exclusively with authentication and should use the right HTTP vehicle for that. EHL > -----Original Message----- > From: William Mills [mailto:wmi...@yahoo-inc.com] > Sent: Tuesday, January 25, 2011 11:23 PM > To: Eran Hammer-Lahav; Mike Jones > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name > > Back to Marius' question though, which is about how we determine how to > treat the Authenticate header when you see it. I, for one, was not happy > with the way that Wrap added on to the OAuth scheme. There are at least 3 > possibilities that it seems to be worth discussing: > > 1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2 > authtype=bearer, but we could go more agnostic like "Authz type=bearer" if > OAuth2 really chafes. > > PRO: simple namespace > > 2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc. \ > > PRO: easy to extend, in no way semantically bound to OAuth > CON: namespace pollution and a proliferation of auth types > > 3) as yet un-discussed, we could reserve a namespace like oauth2_ and use > things like oauth2_bearer. > > 2 and 3 are not exclusive. Are there more? > > There's also discussion that this is authorization, not authentication, and > if we > really want to go there then the source of the problem might be that we're > choosing to overload the Authenticate header. Even more muddy, it's > entirely possible that a bearer token might contain a user credential. > > > > > > -----Original Message----- > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > > Behalf > > > > Of Marius Scurtescu > > > > Sent: Tuesday, January 25, 2011 6:26 PM > > > > To: Mike Jones > > > > Cc: OAuth WG > > > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > > > <michael.jo...@microsoft.com> wrote: > > > > > I'd like a sense from the working group whether others want this > > > > > change, and if so, what the name should be changed to. > > > > > > > > Probably this was debated, but I will ask again. > > > > > > > > Why can't we use "OAuth2" as the scheme in all cases and require a > > > > token_type name/value pair? > > > > > > > > Is it wise to dump lots of new schemes in a name space we do not > > control? > > > > > > > > Marius > > > > _______________________________________________ > > > > 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
