<div dir="ltr">My question is not about weak authentication. It's about layering of specifications, data minimization, and avoiding a compromise between security and privacy. <br><br>To that end, the scope of Alice's sovereign technology can include: <br><ul><li>a secure element (e.g. FIDO U2F) that can sign a challenge and carries an unserialized certificate describing its capabilities. An apple iPhone has the same capability but it is not exposed in a standard or open way yet.</li><li>an UMA Authorization server that Alice has built from open source <br></li></ul><p>In healthcare, the base use-case does not require federation or identity proofing. HIPAA allows a patient "known to the practice" to be treated and connected without external identity verification. Alice can bring her U2F and to practice A where they make a biometric record of her identity (take a photo) and register her U2F token. Alice can bring that same U2F token to practice B and they take her fingerprints to make a record of her identity. Neither the photo or the fingerprints ever leave practice A or practice B for any reason. Alice has the benefit of strong security without any compromise of privacy. The VA can meet the presidential directive requiring 2FA.<br></p><p>Alice now wants to authorize practice B to access her FHIR endpoint at practice A. Alice has her U2F secure element and her home built UMA AS. This is what I would call a zero-federation use case. Can she do that under the profiles proposed by MITRE last week?</p><p>Adrian<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 10:17 AM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">"Alice" would be traditional... I have no problem with that if others don't.<div><br></div><div>As for the nature/strength of the digital identity, I think we're going to want to seek some variability in our use cases, most particularly around not assuming "VA" first and foremost, so that we're not too US- or VA-centric. But scenarios in which Alice is strongly authenticated to some standard seem like a reasonable option. And obviously the VA scenario is an important animating one.</div><div><br></div><div>Are there scenarios in which it's useful to enable Alice to be more weakly authenticated on purpose, such as where leveraging existing social logins is a good idea? FWIW, every EHR system I've logged into so far requires passwords alone (with not a lot of evidence of contextual auth that I can see).</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Mon, Jan 12, 2015 at 2:09 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Justin,<br><br></div>First and most important: I suggest we call the patient (resource owner) Alice consistently in all use cases.<br><div><br>Then:<br><br>I'm checking on the definition of the patient's digital identity at the VA. Can we agree that the digital identity could be based on federation with an IdP or simply Alice presenting to the VA a secure element manufactured (but not serialized) to an acceptable specification (e.g.: FIDO Alliance U2F). <br><br></div><div>In other words, the basis of a VA-trusted digital identity does not have to be an IdP as long as the technology is sourced from a trusted vendor.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>Adrian<br></div><div><br><br><div><div>-- <br><div><br><div dir="ltr"><br></div></div>
</div></div></div></font></span></div>
<br></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto: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><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font>Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font><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></div>
</div>