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

Tue Jun 16 20:26:52 UTC 2015

Sub Topic 1

Justin's sequence - where Alice simply enters a voluntary unique identifier
into the Resource Server's registration form seems like a good default user
experience and one that does not force Alice into any particular federation
or authentication technology.

I would expect the RS to ask for some sort of credentials or attributes on
the part of whatever IDP Alice's voluntary unique identifier resolves to.
Depending on the IDPs credentials or attributes, the RS would have the
option to issue various warnings to Alice even as they proceed with the
registration if Alice insists.

If this maps nicely into OpenID Connect, this could satisfy the "known to
the practice" or "pairwise pseudonimity" requirement as a
privacy-preserving baseline for HEART.

Adrian

On Tuesday, June 16, 2015, Maxwell, Jeremy (OS/OCPO) <Jeremy.Maxwell at hhs.gov>
wrote:

>  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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>
>
>
> On Mon, Jun 15, 2015 at 1:09 PM, Justin Richer <jricher at mit.edu
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>
>
> <HEARTUseCaseAliceEnrollswithPCP.docx>_______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
>
>

-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150616/57c62ca5/attachment.html>