Difference between revisions of "Strong Auth and OpenID getting Comfie"

From IIW
Jump to: navigation, search
(Undo revision 3207 by Igiwydijok (Talk))
 
Line 1: Line 1:
=[http://uwujojedeh.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
 
 
Tuesday Session 1 Space C
 
Tuesday Session 1 Space C
  

Latest revision as of 13:03, 7 February 2011

Tuesday Session 1 Space C

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

The issue: banks, governments and other parties operate sites where high-value transactions take place. These organizations have been resisting OpenID, due to concerns that OpenID is not sufficient for high-value transactions. This session sought to clarify the reasons why.

Philosophically OpenID is viewed by some as a framework that empowers users to choose whatever OpenID Provider (OP) they want. Since OP’s vary widely in terms of enrollment and authentication policies, clearly sites that require strong authentication for high-value transactions will seek out specific OP’s that they trust.

While the “dynamic trust model” (use whatever OP you want) works well at low assurance levels it’s not well-suited to high assurance. But OP’s can be vetted (directly by the RP or via a trusted third party) then RP’s can decide to trust them to deliver on particular authentication strengths.

Core question: should banks allow OpenID for high-value transactions, or are their (frequently raised) concerns valid? People in the session quickly said “the concerns are valid.”

There are four key questions:

  1. How strong is the OpenID set of protocols? The experts feel that the current protocol is not quite strong enough, but is getting improved in the next rev. At the last IIW, Paypal did a presentation on some of the issues here. The US Govt has said that given these challenges the current OpenID is not well suited for transactions that need auth strength beyond assurance level
  1. How well did the OP vet the identity? This needs to either be audited externally by a trusted party, or relying parties can establish a contractual relationship or other trust relationship with the IdP that makes them comfortable.
  1. How does the OP perform individual authentication? As per point 2 above.
  1. And how secure is the OP over time? As per point 2 above.

The OpenID provider site is vulnerable to spoofing; some strong auth techniques such as Out of Band confirmations can be used to combat this.

Why would a bank want to rely on OpenID anyway? Well, the bank has an ongoing relationship with the customer, who uses that credential frequently, so they likely won’t see customers wanting to use another credential at the bank. On the flipside, a bank credential would be useful for logging in at a government website

Banks might not want to be an OP (How do they get paid? Or otherwise get value for having offered that service?)

Why do people want to adopt OpenID anyway, if it doesn’t quite meet their needs? Shouldn’t they just use something else? Well, some governments for example want to get out of the identity management business, and specifically the expensive processes related to registration of users. So OpenID holds out some promise, even if it doesn’t meet the higher-level security requirements yet. Also, governments suffer from infrequent interaction with citizens, so would benefit from relying on a more frequently-used credential.

Many of today’s authentication and communication mechanisms have weaknesses but people accept those out of familiarity. For example, we trust many things done over email (e.g. an emailed PDF contract). But when something new such as OpenID is introduced, everyone naturally stops to consider the implications.

In some ways the OpenID model can provide better security than if RP’s try to do their own authentication. For example, the OP can spot patterns of activity across multiple sites that help identify an attack more quickly. And of course, the OP can be a security specialist while many RP’s are not.