Google, Facebook, and Yahoo! already indicated they will not enforce such a MUST. I could not get a clear answer from Twitter.
However, no one representing this companies has bothered to express this view on the list, and to express how they would like the specification to handle this case. This is why I stopped advocating for it (personally, my own product is already end-to-end TLS, and when we open it up for developers, will not enforce it for personal installations). It is important to remember that this is ultimately within the discretion of the authorization server, and the only ramification (other than the security issue) is not being able to claim full conformance. But such a claim just has no real meaning of value in the consumer space, only in enterprise/government/finance - so I doubt anyone will care if Kiva and the above vendors allow some clients to be less secure than ideal. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Skylar Woodward > Sent: Friday, April 01, 2011 9:52 PM > To: Phil Hunt > Cc: Oleg Gryb; OAuth WG > Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > > Am I the only one still supporting SHOULD on this case? If someone else > supports this language, please speak up. Otherwise, it seems the group > SHOULD move forward with MUST. > > As a provider, we (Kiva) must deal with the possibility of an ecosystem of > developer apps which can't feasibly serve HTTPS endpoints. However, we're > perfectly capable of securing credential exchange and our ecosystem with > our own API/Network additions without holding up the working group on > this point. Alternatively, if others are interested in supporting developers > who can't or won't establish HTTPS endpoints, I'm happy to continue the > discussion to work toward a solution (in this working group or side thread). > > > > On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: > > > Unfortunately neither solution suggested so far is acceptable. So a vote > from my perspective is premature. > > > > I'd like to keep working for a new solution. > > > > Phil > > phil.h...@oracle.com > > > > > > > > > > On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: > > > >> It's a very interesting discussion and I think, I understand both parties > >> well > because consider myself belonging to both communities (enterprise and > networking). Still, I would vote in favor of MUST. > >> > >> Considering the big size of this mailing list and the big level of > >> engagement > of its members, why don't we vote? > >> > >> The results of the vote should be taken into consideration by those who > writes the final version. > >> > >> From: Francisco Corella <fcore...@pomcor.com> > >> To: Eran Hammer-Lahav <e...@hueniverse.com>; Mark Mcgloin > >> <mark.mcgl...@ie.ibm.com> > >> Cc: OAuth WG <oauth@ietf.org>; oauth-boun...@ietf.org > >> Sent: Fri, April 1, 2011 9:22:32 AM > >> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) > >> > >> > So we have 2 different communities of Oauth developers that will > >> > never agree. > >> > > >> > SHOULD: Typically the social networking sites that need to cater > >> > for tail end developers by not enforcing TLS on redirect_uri. It is > >> > a risk to think that using strong language in the spec will help > >> > them appreciate the issues > >> > MUST: Typically enterprise organisations (I am in this camp). They > >> > can enforce indirectly by only supporting registered callback urls > >> > and ensure those use TLS > >> > >> Security is at least as necessary to social networking sites as to > >> enterprise sites. Think about what this means for Facebook. If you > >> are using Wifi in a cafe and use the Facebook login button to log in > >> to any application, a hacker can easily impersonate you. > >> > >> By the way, is somebody from Facebook reading this? If so, this is a > >> vulnerability that Facebook has right now, and you should do > >> something about it. At the very least you should change the examples > >> of redirect URIs in the developer documentation so that they use > >> https rather than http. > >> > >> Francisco > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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
