A look at multi-LOA cases

The foundation for security and enterprise management

The recent "Open Government Identity Management Solutions Privacy Workshop" hosted by the U.S. General Services Administration has engendered a lot of excellent discussion of emerging issues. I mentioned some of it  a couple of weeks ago, and today I want to explore another area that was covered in the workshop.

I wasn't there, but George Fletcher, the chief architect for identity services at AOL, was and he's written about it ("User experience and Levels of Assurance"). A critical point Fletcher makes is that "While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over."

Slideshow: Technology from the feds

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

The recent "Open Government Identity Management Solutions Privacy Workshop" hosted by the U.S. General Services Administration has engendered a lot of excellent discussion of emerging issues. I mentioned some of it  a couple of weeks ago, and today I want to explore another area that was covered in the workshop.

I wasn't there, but George Fletcher, the chief architect for identity services at AOL, was and he's written about it ("User experience and Levels of Assurance"). A critical point Fletcher makes is that "While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over."

Slideshow: Technology from the feds

If you're unfamiliar with the U.S. government's definitions of the various levels of assurance, they are:

* Level 1: Little or no confidence in the asserted identity's validity.

* Level 2: Some confidence in the asserted identity's validity.

* Level 3: High confidence in the asserted identity's validity.

* Level 4: Very high confidence in the asserted identity's validity.

Fletcher goes on to illustrate a multi-LOA use case as follows:

1. User goes to government Web site where he 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 government 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 him 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 he needs a more secure credential and he 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 he wants 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 his current LOA1 provider (the one used when logging into the government 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 his 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 a one-time pin sent to his cell phone.

13. The user enters the one-time pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting Web site.

That looks, to me at least, like a reasonable and relatively efficient process. If you agree (or if you don't) post a comment to Fletcher's note and e-mail me a copy.

Read more about security in Network World's Security section.

Dave Kearns is a consultant and editor of IdM, the Journal of Identity Management.