[OpenID] Security related Use Cases?

[Peter Williams]

-----Original Message-----
From: Ben Laurie [mailto:benl at google.com]
Sent: Wednesday, October 22, 2008 2:52 AM
To: Peter Williams
Cc: Dick Hardt; OpenID List
Subject: Re: [OpenID] Security related Use Cases?



On Wed, Oct 22, 2008 at 1:59 AM, Peter Williams <pwilliams at rapattoni.com> wrote:

> Built into PC browser? -10



Why?





Eric mentioned the classical reason already. Build it into every new PC browser release you like..(like the Microsoft wallet and its support for payment-auth protocols? Remember that?) but you have not addressed the browser in the 1 billion phones out there, the soap-based active client on the corporate desktop, the non visual IE controls embedded in excel scripts, and the millions of kiosks. its -10 vs -1 because it perpetuates a myth about the omnipotence of the "next browser release".



Developers building the latest browser components don't represent the reality of corporate or community deployment. Before one can sign the outsourcing contract for 10,000 corporate users to migrate to salesforce.com CRM and GoogleApps gmail, the system has work in all the ways that Exchange/Novell/Lotus does/did ...with all those devices. In general, that means supporting quite a lot of legacy stuff ...so critical business process don't stop. I have 15% of users sitting at shared PCs, using a shared account and shared cookie jar, on a win98-era LAN. (Thus, Yahoo-based machine-based auth is out of the question.) If they are lucky, the machine is "modern": its running XP home edition, unpatched, with no virus checking.



Developers properly think about tomorrow. Deployers thing about today, and the cost of 1000 phone calls while folks struggle to update their drivers, migrate their data, revise the BCP (25% annual cost of IT, remember) and wonder what happens when their new Google browser cannot work with their Apple phone (unlike yesterday, when it all at least worked, albeit painfully achieved, with IE). SUN destroyed the public trust with Java, since the reality is that change an JVM...and things DO BREAK all the time (contrary to the pitch). I was suddenly unable to remotely admin my cisco SSLVPN units from my PC, just last week... It cost us 4h incident response time....



> In "site seal" used at banks, you typically accept/recognize your seal/caption BEFORE you supply password (during signon)!



So?



It's the opposite of the assertion in Paul's claim: login first, then get the seal. In US current account banking, you typically verify the seal (and also get past the anti-fraud expert system) and then login - so as to mitigate password phishing and malicious javascript.





The call was for a consistent UI (and UX, whatever that is). SO?, I pointed out the first inconsistency case. Paul wants (a), deployed banking wants (b). The likelihood of deployed banking migrating to future OpenID consistent UI doing (a) is somewhere close to zero. They will stay consistent with best UI practice, agreed yesterday. If the browser plugin enforces Paul's "consistency" vision on good UI, banks will reject that browser and go back to their own site design.



In the medium term, new trends will of course take effect, as they address legacy installs. But, its much slower than you ever imagine.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081022/28bd347a/attachment-0002.htm>