IIW #9 : Making it all work

If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.

Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.

I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.

I'm expecting discussions like this to be a key part of IIW #9.

Internet Identity Workshop
Registration

User experience and Levels of Assurance

The US government recently (Aug. 10th) held an Open Government Identity Management Solutions Privacy Workshop to discuss Trust Frameworks, Levels of Assurance and Privacy. At this workshop the government introduced a process for the adoption of any identity technology and a process for the adoption of any Trust Framework as managed by a provider (e.g. a Trust Framework Provider [TFP]). Both documents can be downloaded from the above link.

One of the key points brought out at the meeting is that user experience (UX) is critical as users navigate government web sites that potentially require different levels of assurance (LOA) (see OMB M04-04). While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over. I believe UX and transitioning between levels of assurance is one of the critical issues to solve.

While specific technologies may be restricted to certain levels of assurance, the user experience should be agnostic to the technology required to implement any specific use case. In this context I'd like to propose the following multi-LOA use case as one possible way to provide a good user experience.

1. User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
2. The user is redirected to their consumer LOA1 credential provider and logs in
3. The user is redirected back to the govt web site with an LOA1 credential
4. The user interacts with the web site
5. The user clicks on an option on the web site that directs them to a new site (or a service within the existing site) that requires a LOA2 credential
6. The user arrives at the new site and does not have a LOA2 credential
7. The site informs the user that they need a more secure credential and that they can get one from the following locations
8. The user selects one of the providers and is redirected to that site
9. The LOA2 provider asks the user if they want to use existing LOA1 providers as a factor in the LOA2 credential
   • here I'm thinking that an LOA1 credential could be used in bootstrapping to the LOA2 credential)
10. The user selects their current LOA1 provider (the one they used when logging into the govt site)
11. The user goes through some identity proofing process (note that this could happen off line if necessary).
    • The point is that the user ties their LOA1 identity to the LOA2 provider. This helps with seamless transition between levels
12. The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
13. The user enters the one-time-pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting web site

I'm sure I've left out some critical steps or places where the above does not comply with assurance framework requirements. I would appreciate feedback as to whether the general idea is viable. I would hope that one goal of this effort would be to protect the user (as much as possible) from having to increase the number of identities they manage.