<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 17-Oct-08, at 1:13 PM, Eric Sachs wrote:</div><blockquote type="cite"><div dir="ltr"><div><span class="Apple-style-span" style="border-collapse: collapse; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">>>&nbsp;<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; ">Have you tested the OP user experience with a malicious RP? ie. how easy is it for a malicious RP to fool users to pretend they are your OP?</span></span></div> <div><span class="Apple-style-span" style="border-collapse: collapse;">The research note we published has a section on this which I have copied below:</span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><br> </span></div><div><span class="Apple-style-span" style="border-collapse: collapse;"><span class="Apple-style-span" style="font-family: Arial; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; "><b>Phishing Increase</b><br> Some potential IDPs will be concerned that becoming an IDP will make it easier for their end-users to fall prey to phishing attacks.&nbsp; That is because an "evil" RP could intercept the user when they would normally be sent to the IDP, and instead show the user what looks like a login page for their IDP.&nbsp; The RP could then use that phishing page to collect the user's credentials.&nbsp; We do not have a magic answer for that problem.&nbsp; A similar problem also exists with web delegation protocols like OAuth.&nbsp; In the case of web delegation protocols, the user demand for access to their data was too high for websites to ignore, especially when users would give their credentials to 3rd party sites which would then scrape the main site for the user's data (such as social networks scraping a user's E-mail address book).&nbsp; End-users have a similar demand for federated identity, and because of the lack of it, many users will simply use their exact same password on their E-mail provider's site as they do on many other sites where they login with that same E-mail address.&nbsp; It will be up to individual IDPs to decide how to balance demands from their end-users with concerns about potential increases in phishing attacks.</span></span></div></div></blockquote><br></div><div>Just to clarify, you did NOT do any testing?&nbsp;</div><div><br></div><div>Many people in the community view that having something on the client is the only way to minimize phishing. Wether that be a cookie, client side cert, add-on or smart browser.</div><div><br></div><div>An enhanced browser would be able to control where the user is directed and provided a UX that cannot be duplicated by a phisher. An enhanced browser could also take over the UX for a user when the encounter a site that accepts OpenID -- providing a significantly more streamlined UX.&nbsp;</div><div><br></div><div>The browser vendors have indicated they would include functionality if they knew what to do. In the&nbsp;interim, IdP's like Yahoo! and Google could have a simple add-on off of their site that comes pre-configured for Yahoo! or Google.</div><div><br></div><div>What are your thoughts / concerns on this?</div><div><br></div><div>-- Dick</div><br></body></html>