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.