tag:blogger.com,1999:blog-34275044.post7319212871401496008..comments2023-04-23T07:00:02.839-04:00Comments on Identity in Practice: User experience and Levels of AssuranceGeorge Fletcherhttp://www.blogger.com/profile/12081110172957645007noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-34275044.post-21896102020732137452009-08-27T12:00:17.104-04:002009-08-27T12:00:17.104-04:00Craig, interesting point about popups. So far our ...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.<br /><br />Mark, the paper sounds interesting. Especially use cases involving a smart phone or other small device.<br /><br />By the way, a small plug for a user experience group forming as part of the Kantara Initiative. Please check out <a href="http://kantarainitiative.org/confluence/display/ulx/Home" rel="nofollow">User Login Experience</a>. It's free to join the group.George Fletcherhttps://www.blogger.com/profile/12081110172957645007noreply@blogger.comtag:blogger.com,1999:blog-34275044.post-68116714172591626152009-08-26T12:18:04.210-04:002009-08-26T12:18:04.210-04:00Very interesting discussion around the LOA. This ...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.<br /><br />I am writing a research paper on this, please reply if you're interested in being a reviewer (mwilloughby@complianceresearchgrouop.com)Mark Willoughbyhttp://www.complianceresearchgroup.comnoreply@blogger.comtag:blogger.com,1999:blog-34275044.post-50612635735630452642009-08-25T11:07:03.972-04:002009-08-25T11:07:03.972-04:00Thanks for posting my comment - and no problem on ...Thanks for posting my comment - and no problem on it being a tad late - I've been there, done that!<br /><br />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). :-)Craig Tomlinhttps://www.blogger.com/profile/07727491787560477236noreply@blogger.comtag:blogger.com,1999:blog-34275044.post-75624535253173526702009-08-25T07:44:47.433-04:002009-08-25T07:44:47.433-04:00[My apologies to Craig for not getting his comment...[My apologies to Craig for not getting his comment published until today:(]<br /><br />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.<br /><br />That said, I do believe that the UX is critical to get broad adoption. Here's hoping the discussion will continue and not fizzle:)George Fletcherhttps://www.blogger.com/profile/12081110172957645007noreply@blogger.comtag:blogger.com,1999:blog-34275044.post-42872661954314782822009-08-15T12:15:11.996-04:002009-08-15T12:15:11.996-04:00Interesting discussion. I agree with Paul Madsen&...Interesting discussion. I agree with Paul Madsen's comments too.<br /><br />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).<br /><br />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).<br /><br />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.<br /><br />Of course, if this were all that easy we wouldn't need to be discussing it, now would we? :)<br /><br />Great discussion and I'm looking forward to hearing how this is resolved.Craig Tomlinhttps://www.blogger.com/profile/07727491787560477236noreply@blogger.comtag:blogger.com,1999:blog-34275044.post-32324768113681651312009-08-15T06:33:53.821-04:002009-08-15T06:33:53.821-04:00George, it would seem pretty straightforward UX, e...George, it would seem pretty straightforward UX, except for the implied proxying that happens at the LOA1 provider?<br /><br />Challenges I can think of for the use case include:<br /><br />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? <br /><br />2) And why would it trust what is returned? The assertion would need to chain back to the TFP that assessed the LOA2 provider <br /><br />3)how to represent this 'chained authn' to the RP in Saml authn context etc?<br /><br />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.<br /><br />Lots of fun ahead :-)Paul Madsenhttps://www.blogger.com/profile/08489111023182783403noreply@blogger.com