No clue, but what difference does it make? Either you "pollute" the OAuth header namespace or the HTTP Authentication scheme name namespace. What's the difference? Either way, I would be surprised if we see more than 10 token types over the next 5 years.
EHL > -----Original Message----- > From: William Mills [mailto:wmi...@yahoo-inc.com] > Sent: Wednesday, January 26, 2011 8:44 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name > > 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
