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.
- User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
- The user is redirected to their consumer LOA1 credential provider and logs in
- The user is redirected back to the govt web site with an LOA1 credential
- The user interacts with the web site
- 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
- The user arrives at the new site and does not have a LOA2 credential
- The site informs the user that they need a more secure credential and that they can get one from the following locations
- The user selects one of the providers and is redirected to that site
- 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)
- The user selects their current LOA1 provider (the one they used when logging into the govt site)
- 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
- The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
- 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.
6 comments:
George, it would seem pretty straightforward UX, except for the implied proxying that happens at the LOA1 provider?
Challenges I can think of for the use case include:
1) if the first provider is certified only for LOA1 (perhaps in metadata), how will the second RP know/be willing to ask for a higher assurance authn?
2) And why would it trust what is returned? The assertion would need to chain back to the TFP that assessed the LOA2 provider
3)how to represent this 'chained authn' to the RP in Saml authn context etc?
4) If OpenID is constrained to LOA1 - this use case implies some other protocol being swapped in for the higher assurance request/response. So, not only must RPs think about what LOA to ask for, they need to know which protocols to use for each request.
Lots of fun ahead :-)
Interesting discussion. I agree with Paul Madsen's comments too.
The solution you've suggested sounds promising, but there may be issues with users navigating away from and then back to your first site (I'm thinking the issue being steps 1-3).
Rather than the user navigating away to a LOA1, which seems to cause many abandonments from testing I've conducted, I would reverse it to where the gov site has the LOA1 as part of its process (via portal - portlet concept).
If you can determine a way to ensure the user does not have to leave the site (aka Task Flow) to becmoe LOA1 enabled - I think the rest of it is good.
Of course, if this were all that easy we wouldn't need to be discussing it, now would we? :)
Great discussion and I'm looking forward to hearing how this is resolved.
[My apologies to Craig for not getting his comment published until today:(]
I agree that navigating away from the site to verify at an LOA1 site is not an ideal user experience. However, the use of popup browser windows can help with this and is the direction OpenID is taking for remote authentication. Also, if the user is already authenticated at the LOA1 provider, they shouldn't even notice the protocol flows that verify their authentication from the LOA2 provider.
That said, I do believe that the UX is critical to get broad adoption. Here's hoping the discussion will continue and not fizzle:)
Thanks for posting my comment - and no problem on it being a tad late - I've been there, done that!
The problem I think with pop-ups is unless you're using the same domain - most of the more updated browsers automatically block pop-ups. This is done to stop spammers from popping up annoying messages or otherwise try to abuse the user experience. Firefox especially is set up for this, and is rather difficult to change. Your LOA1 pop-up idea as a pop-up would be ok if on the same domain, but if that's the case why not embed the LOA1 inside the actual content of the page - thus not requiring an annoying popup? But maybe that's not possible for .gov sites (my ignorance of security now showing). :-)
Very interesting discussion around the LOA. This subject has been discussed prevsiously under the contextual security, or risk-based authorization labels. There are even products available to support an ability to raise a user's LOA with challenge-response or other means. I see this as a huge issue in the coming smartphone marketplace, to raise the LOA for wireless users toggling between consumer and sensitive business sessions, the Feds are prescient.
I am writing a research paper on this, please reply if you're interested in being a reviewer (mwilloughby@complianceresearchgrouop.com)
Craig, interesting point about popups. So far our experience has been that if the popup comes from the user clicking a button, the popup blockers allow the popup to be displayed because it came from an explicit user action. However, if browsers get more restrictive then we could run into the problems you describe.
Mark, the paper sounds interesting. Especially use cases involving a smart phone or other small device.
By the way, a small plug for a user experience group forming as part of the Kantara Initiative. Please check out User Login Experience. It's free to join the group.
Post a Comment