What Happens When my Federated Identity Fails?

Session Topic: What happens when federated identity fails? (T4G)

Convener: George Fletcher – AOL

Notes-taker(s): Jon Webb - Sony

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

A user within a service may have a username record which is referenced by a pid (provider ID) and a puid (provier user ID). This tuple allows login so long as these remain valid. But what happens if you lose federated ID?

How to lose fed id?

• IDP goes out of business
• Personally delete the account
• Disconnect from the RP (e.g. revoke OAuth token)
  • You just reconnect
• compromised accounts
• IDP blocked the acct (e.g. law enforcement action, etc)

Need to define best practices!

• Not necessarily a big deal if I can post to pinterest because my IDP went out of business
• Potentially a big deal if I can't login to eTrade or some medical/govt entity

One approach is to allow creation of another set of auth credentials and link it to the original record.

• What information does the RP know about the user to allow them to recover?
• What information is strong enough?
  • First name, last name, address, favorite animal??
• Previously seen device?
• Phone/SMS challenge

What about if your original IDP account comes back?

• Either way, need re-connection flow

Bottom line - RP's need enough data to recover accounts!

This somewhat flies in the face of some of the privacy principals of OpenID for being an RP. You might be able to have a recovery flow as a part of business you're already doing. E.g. it's one thing to request the user's phone number just so you can have a recovery flow, it's another thing if you request their number because you're legitimately providing a service based on that attribute (same would go for billing info for example).

What about the case where your IDP is simply down or non-responsive temporarily?

• One idea is that you could temporarily allow someone access through an alternative auth mechanism
• Could use the same basic recovery flow, possibly with reduced access/capabilities
  • why?
• Again, this is recreating the problem of running against the privacy principals we'd like to maintain

Examples:

Federated login through plaxo.com, trippit.com. The former will not ask you for an additional username or password, but will allow you to "locally" add new profile photos etc. The latter asks you for an additional local password as well.

One potential enhancement:

• When a user chooses to login with a button from the nascar, you could at least check to see if the IDP is up
  • Launch a hidden iframe to check to see if IDP will respond before allowing the user to login with that provider

This recovery issue exists because users see vested value in certain accounts. Some accounts have more value than others. In facilitating recovery, there are two sides to the risk:

• Consumer risk: access to private information, impersonation, reputation, purchasing, etc
• RP risk: public perception of service, regulators, lawsuits, security, fraud, etc

General discussion around whether or not a RP could push a user towards an IDP that provides "better service" from the perspective of the RP. That could either be better guaranteed availability or levels of assurance or quality of recovery flow and/or turnaround time on recovery. Is there a possibility for a business to provide this recovery service outside of an IDP?

What about heuristics based approaches? Allow account recovery based on the user's interaction with the RP itself (transactions, activity, login time/location, etc).

• Most RP's don't want to hold and secure this information
• Some discussion about these heuristics being error prone in general

Perhaps the conclusion is that this is a balance between allowing customers back in and losing those customers, and that balance will be defined by the service itself and the choices it makes with regard to the storage of this heuristic information/data attributes, and less strict recovery flows or a lack of recovery flow.