Michael, You should read the threat model document. This document has more editorial on these kinds of issues.
The core spec deals in specific items implementors must do or not do from an inter-op perspective. The threat model document goes into some details about the need for authenticating clients, etc and the counter-measures that should be considered. This is likely more in line with your concerns. In my opinion, the issue of malware and of component "trust" is to me something that belongs in whitepapers, product manuals, etc and does not belong in the protocol specification. In a sense the issue is the kind of thing a "consultant" would provide and thus this type of consultative information fits into broader best practices of desktops and servers management and has no direct relevance on OAuth. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-07, at 11:02 AM, Michael Thomas wrote: > On 09/07/2011 10:49 AM, John Kemp wrote: >> Mike, >> >> On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote: >> >> >>> On 09/07/2011 10:17 AM, Igor Faynberg wrote: >>> >>>> +300 (if I can do that) to indicate my strong agreement. But if somehow >>>> it is decided to add a few sentences on saying that OAuth cannot deal with >>>> key-logging, I will insist on adding two sentences each on OAuth being >>>> unable to deal with 1) earthquakes, 2) certain contageous diseases, etc., >>>> [...] >>>> >>> Please, enough of the hyperbole. It is not clear or obvious whether this is >>> a protocol issue or not. It brings into question whether the protocol is >>> worth >>> deploying at all, and that is surely an issue. As far as I can tell, there >>> is very >>> little upside to deploying OAuth in the general case over, say, Basic+TLS. >>> In >>> fact, you guys have convinced me that OAuth gives inferior protection at >>> considerable expense for all concerned. >>> >> I'm sorry that you haven't received an easy introduction to the OAuth WG. >> But that's no reason to spout nonsense. OAuth seeks to replace something >> that was once rather common - the need for a user to type (and/or store) his >> password for site A at site B, to let site B get their content from site A. >> Now, site B gets a token in the common case, rather than the user's password >> for site A. This doesn't remove the need for a user to exercise common sense >> in deciding where to type her password. But it does, in the common case, >> mitigate the password being shared among websites, or across networks >> multiple times. >> >> You are right that OAuth doesn't mitigate key logging or other similar >> attacks on the client OS/platform itself. But that doesn't make it inferior >> to other methods of web authorization. >> >> > > It's not nonsense: > > 1) App prompts me for my credentials to Facebook -- I wonder whether > I trust the app. > 2) App puts me in a Facebook login window -- I figure that it's secure and > don't wonder whether I trust the app. > > #2 sure looks worse than #1. > > Mike > _______________________________________________ > 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
