If this is changed to a MUST, Facebook will be in violation of the specification moving forward. It is untenable to require all of our *client* developers to implement TLS endpoints though we certainly support developers who wish to do so. This is very different than offerring our entire API (and now site as opt-in) over TLS as the server.
I feel like we need to write the appropriate security considerations even with a MUST because many deployers will ignore the requirement. It's far more valuable to document the risk and explain ways to help mitigate it than just changing a SHOULD to an ignored MUST. --David On Sat, Apr 2, 2011 at 9:33 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
