[Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP

Maxwell, Jeremy (OS/OCPO) Jeremy.Maxwell at hhs.gov
Tue Jun 16 20:00:27 UTC 2015


Is a smart phone necessary for the use case work flow?  What about folks that don’t have smart phones?  What about folks that don’t have a cell phone?



From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Tuesday, June 16, 2015 3:40 PM
To: Sarah Squire
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP

[adding the HEART list back on the thread]

While this is a real threat, I think this speaks more to a need for IdPs to allow log-in and verification through means that aren’t susceptible to kiosk-based attacks like this. Having an out of band verifier, like an OTP token, U2F crypto challenge, or colluding app on Alice’s phone all make the phishing the password less detrimental. If nothing else, her IdP can notice that Alice is logging on with an unfamiliar computer and require higher levels of authentication, all of which she’d be familiar with.

That said, in HEART, we might be able to (or might need to) come up with standardized means for binding the IdP account while at an untrusted network environment (the doctor’s office). The simple approach is of course to just have Alice log in, but perhaps there are other ceremonies that we can count on. Round-tripping the email address isn’t going to give a very strong binding to an IdP, but maybe there’s something we can do there. Just thinking off the cuff, I can think of a flow that’s reminiscent of something we did at MITRE years ago with an OAuth 1.0 client that worked over email:


1.      Alice shows up at the doc’s office

2.      Alice’s doc logs in and opens up Alice’s medical record on a kiosk

3.      Alice enters her email address into a form on this doc-authenticated page

4.      Doc’s computers use this email address to do a webfinger lookup to find Alice’s IdP

5.      Doc’s computers register with the IdP and start an authentication transaction but don’t open a local browser

6.      Instead, Doc’s computers send Alice an email with the fully-kitted authorization URL

7.      Alice gets the email and opens up the link

8.      Alice is presented with her own IdP’s regular authorization screen (she’s probably already logged in on her device)

9.      Alice authorizes the Doc’s computers to access her identity information

10.  Alice is sent to the redirect URI, which is back on the Doc’s system

11.  This redirect URI could either (a) automatically message the waiting kiosk application through a trusted back-channel that the authentication has taken place, using the ‘state’ value as a secure key between them or (b) display a short code for Alice to enter into the kiosk. Remember, the redirect URI’s contents are rendered on Alice’s device.

In the future, Alice can log in from any device she wants to using her IdP at the Doc’s system, since it’s been strongly bound by the ceremony.

 — Justin

On Jun 15, 2015, at 5:12 PM, Sarah Squire <sarah at engageidentity.com<mailto:sarah at engageidentity.com>> wrote:

I actually like the email address verification not because it's a verification, but because it's a better and more secure user experience. If Alice has to log into her IdP at the registration desk, she has to remember her password (unlikely), then type it into a kiosk that might have a keylogger, or where her keystrokes might be captured by a camera. Alternatively, if the IdP binding is done via email verification, she can log in on her phone, which, if it doesn't already have an open session, probably has her password vault, and even if it doesn't, at least she's typing into her own device rather than a kiosk.

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>

On Mon, Jun 15, 2015 at 1:09 PM, Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>> wrote:
I’ve made this remark on a few of the other use cases, too: I think that we ought to be concentrating on making use of digital federated identities instead of inventing a thousand and one “digital proof” mechanisms like the email address verification listed here. It’s not really central to the use case’s goals so it’s more decoration to the story than anything, but I still wouldn’t want us to put a lot of effort into codifying little workarounds like this.

 — Justin

On Jun 15, 2015, at 3:55 PM, Sarah Squire <sarah at engageidentity.com<mailto:sarah at engageidentity.com>> wrote:

Hello all,

I've attached a write-up of the enrollment use case incorporating feedback from the last three calls. Thanks everyone for your valuable input. I think this is much more solid now. Please chime in if there's anything else we can improve upon.

Sarah

Sarah Squire
Engage Identity
http://engageidentity.com<http://engageidentity.com/>
<HEARTUseCaseAliceEnrollswithPCP.docx>_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net<mailto:Openid-specs-heart at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-heart



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150616/5f229025/attachment-0001.html>


More information about the Openid-specs-heart mailing list