On 01/16/2012 05:52 AM, Mark Mcgloin wrote:
Countermeasures:
First off the title: it says Countermeasures. Therefore, anything here must be a real and meaningful "countermeasure".
1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials.
This is not a countermeasure. It is a request that bad guys be good. Strike it entirely.
In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed
This is not a credible countermeasure. End users know nothing about this, and I'd venture to say that includes you and me too. Strike it entirely.
2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way
This may be a valid countermeasure, but there needs to be some reason to believe that it is not just a hope and a prayer put here just to feel good. If it cannot be substantiated, strike it entirely.
3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser.
This is not a valid countermeasure. It expects bad guys to be good. Strike it entirely. Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
