I question how much name space pollution is a problem, how many auth schemes are we really going to have?
> -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Wednesday, January 26, 2011 12:49 AM > To: William Mills > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name > > 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
