Sub Topic 1 <div><br></div><div>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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Adrian<br><br>On Tuesday, June 16, 2015, Maxwell, Jeremy (OS/OCPO) <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Openid-specs-heart [mailto:<a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart-bounces@lists.openid.net');" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Justin Richer<br>
<b>Sent:</b> Tuesday, June 16, 2015 3:40 PM<br>
<b>To:</b> Sarah Squire<br>
<b>Cc:</b> <a href="javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');" target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-heart] HEART Use Case: Alice Enrolls with PCP<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">[adding the HEART list back on the thread]<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p><u></u><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice shows up at the doc’s office<u></u><u></u></p>
</div>
<div>
<p><u></u><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice’s doc logs in and opens up Alice’s medical record on a kiosk<u></u><u></u></p>
</div>
<div>
<p><u></u><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice enters her email address into a form on this doc-authenticated page<u></u><u></u></p>
</div>
<div>
<p><u></u><span>4.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Doc’s computers use this email address to do a webfinger lookup to find Alice’s IdP<u></u><u></u></p>
</div>
<div>
<p><u></u><span>5.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Doc’s computers register with the IdP and start an authentication transaction but don’t open a local browser<u></u><u></u></p>
</div>
<div>
<p><u></u><span>6.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Instead, Doc’s computers send Alice an email with the fully-kitted authorization URL<u></u><u></u></p>
</div>
<div>
<p><u></u><span>7.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice gets the email and opens up the link<u></u><u></u></p>
</div>
<div>
<p><u></u><span>8.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice is presented with her own IdP’s regular authorization screen (she’s probably already logged in on her device)<u></u><u></u></p>
</div>
<div>
<p><u></u><span>9.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice authorizes the Doc’s computers to access her identity information<u></u><u></u></p>
</div>
<div>
<p><u></u><span>10.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Alice is sent to the redirect URI, which is back on the Doc’s system<u></u><u></u></p>
</div>
<div>
<p><u></u><span>11.<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> — Justin<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 15, 2015, at 5:12 PM, Sarah Squire <<a href="javascript:_e(%7B%7D,'cvml','sarah@engageidentity.com');" target="_blank">sarah@engageidentity.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888">Sarah Squire<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888">Engage Identity<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><a href="http://engageidentity.com/" target="_blank"><span style="color:#1155cc">http://engageidentity.com</span></a><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Jun 15, 2015 at 1:09 PM, Justin Richer <<a href="javascript:_e(%7B%7D,'cvml','jricher@mit.edu');" target="_blank">jricher@mit.edu</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> — Justin<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">On Jun 15, 2015, at 3:55 PM, Sarah Squire <<a href="javascript:_e(%7B%7D,'cvml','sarah@engageidentity.com');" target="_blank">sarah@engageidentity.com</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hello all,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sarah<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Sarah Squire<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Engage Identity<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="http://engageidentity.com/" target="_blank">http://engageidentity.com</a><u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><HEARTUseCaseAliceEnrollswithPCP.docx>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','Openid-specs-heart@lists.openid.net');" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote></div></div><br><br>-- <br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u> </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div><br>