Blaine, Hannes, This thread has gone as far as it can. We need to shut it down and move this item to the chairs (and potentially the AD) to resolve, given that this is not a technical issue, but a political/procedural one. I'm asking the chairs to make a decision about this, given that the working group is unable to reach a conclusion.
Rant inline below... EHL > -----Original Message----- > From: Francisco Corella [mailto:fcore...@pomcor.com] > Sent: Monday, April 04, 2011 5:46 PM > If the IETF endorsed a protocol such that a compliant implementation allows > user impersonation and unauthorized access to protected resource, then the > IETF would be endorsing lack of security. How is that inaccurate? Because there is no such thing as an IETF endorsement, and a publication of an RFC only means that the community has reviewed a document and it represent as full picture as possible (at that time). There is nothing about an IETF standard that requires it to always pick security over usability, *as long as* the security issues are well documented, explained, and given the proper context and warnings. Documenting a security issue and recommending a solution is well within IETF practice. The point of the security consideration section is to make sure those implementing the standard understand the security issues involved. No IETF RFC claims to be 100% secure and that any implementation of it can be 'trusted'. The IETF should *promote* best security practices, as long as they are practical. > The statement is helpful from the point of view of the users who would be > the victims of the attacks. You seem to be concerned about companies and > developers but not about users. That's crap. The user has no way of gaging anything with regard to the client or server implementation. It cannot tell if the server has implemented anything correctly. The user will never even know OAuth exists. Since when does a standard protect users? There is no enforcement. No IETF police. I am not even sure the IETF organization can say anything publically about any particular implementation without opening itself to litigation. Users vote with their feet. How many people stopped using webmail services once they learned about the danger of FireSheep? Practically none. Our job is to produce technical documents that improve interoperability and abide by the best security practices possible. Our only audience are the people implementing the standard. The only question is, will an average developer reading the document understand the issue and do as much as possible to address it? I'm in the business of building consumer web products. Who do you think are my customers? We are all here to serve the needs of the end user. But we also live in the real world where the web is insecure and we have to work with what we've got. Your position is that it is better to make a stand and force almost every consumer web company to violate the specification (since you can't force them to abide by it). My position is that more people will pay attention to the issue if we explain it and not give them an excuse to ignore other security related MUSTs (once you ignore the first, the 2nd, 3rd, 10th come easy). If we make this a MUST, we know Facebook is going to ignore it because they have no other options at this point in time. They are not going to write 'Almost OAuth 2.0 compliant' on their site. They are not going to even mention OAuth to their users. But on their developer site they will say they support OAuth 2.0. Then you will come and write a long blog post about how they are not really OAuth 2.0 compliant. Great. Now what? 600 million people will stop using Facebook? You've been told clearly that the three largest consumer web companies (by audience): Yahoo!, Facebook, and Google, are all going to ignore a MUST if this is what we are going to specify. Either you just don't care producing a document that the three biggest players on the web ignore, or you kidding yourself that they will all commit business suicide and enforce it - forcing their developers to produce unusable client applications (and that client developers will go along with it, wasting time on unusable products). The world doesn't get any safer with this language, but the spec gets further away from reality and we all know what a slippery slope that is when implementation and standards start drifting apart. Our job is to fully document any security shortcoming we are aware of. A SHOULD does just that and is perfectly reasonable. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
