Hey Marius, > -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Sunday, January 30, 2011 2:45 PM > To: Eran Hammer-Lahav > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] Update required for bearer token spec > > On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav > <e...@hueniverse.com> wrote: > > As for the open issues: the bearer token scheme name - if it wasn't > > clear, I plan to use every mean available to me to block the bearer > > token draft from using the 'OAuth2' scheme name, and will raise this > > issue in the WGLC, Area Director review, IETF LC, and direct appeal to > > the IESG if necessary. You might consider this childish, but I > > consider bearer tokens a disaster waiting to happen and will not > > allow the weakest form of token authentication to carry the strongest > > form of endorsement and perception (via the OAuth brand). > > I do respect your opinion Eran, but is there consensus around this? If > anything, the consensus seems to be around bearer tokens. As far as I can > tell this is the big selling point of OAuth 2 and all implementations I am > aware > of will support it.
There is no consensus around names. My project does not support bearer token so at least one Yahoo! product API is going to ban bearer tokens. We have published an open source client and server MAC token implementation in JS and node.js. I do not speak on behalf of the rest of the company, and given past opinion, expect them to support bearer tokens. > For all intents and purposes OAuth 2 is bearer tokens. And this is the issue! It is exactly why I am being so forceful against this perception and why I refuse to allow the bearer token to be named the OAuth2 token type. This will have the exact effect you have stated. Where I disagree with you is that this is a foregone conclusion. I am committed to the message that bearer tokens are a feature of OAuth 2.0, and when implemented correctly can provide a security level adequate for any current web services. I am opposed to any perception of bearer tokens as the default type, implying that people should always start with bearer token and "upgrade" to something stronger only when needed. > > At the end, you might get the scheme name you want, but it will cost > > you significant delays in getting that document published as an RFC > > and with a Proposed Standard designation. So far you have failed to > > raise any technical justification for your insistence of using that > > name. The only reason so far is that it will be less confusing. Perhaps. But > will be more damaging. > > Such delays would be unfortunate, I truly hope we can sort this out. I will follow up with a proposal later today and will get a discussion going. > > After > > all, why would anyone look at the MAC token specification or other > > stronger authentication schemes, when you offer them the "official" > OAuth 2.0 scheme. > > That's a good point. What about using a common prefix for all OAuth 2 > related scheme names? Something like "OAuth2Bearer", "OAuth2Mac". I don't see value in limiting MAC to OAuth. It is a generally useful scheme, especially for "2-legged" authentication as used with 1.0. I'll cover these suggestions in my new discussion thread. Thanks for the feedback. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
