<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks Adrian<div class=""><br class=""></div><div class="">I'm reading your email while Eve is presenting HEART here at the European Identity Conference. <div class="">Your proposal goes to the heart of the charter of the OpenID Foundation HEART Work Group</div><div class=""><br class=""><div class="">All puns aside, focus is a critical success factor for the HEART WG as it deliberates in a particularly crowded and noisy landscape.</div><div class="">Your note points to the tension between the proscriptive clarity of a MUST requirement versus the inherent optionality of open standards. </div><div class=""><br class=""></div><div class="">A privacy engineering approach, running concurrently with related procurements, pilots and standards development holds the promise of advancing the important conversations on consent, control and permissioning. MIT KIT and others are promising venues for those discussions.</div><div class=""><div class=""><br class=""></div><div class="">In a related note:</div><div class="">One value of self certification and registration is that it can help make a component of a spec ( like OpenID Connect in HEART), as reliable/trusted as possible (e.g. its legal assurance of technical conformance). </div><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; border-spacing: 0px;"><div class="">Don Thibeau</div><div class=""><a href="http://openid.net" class="">The OpenID Foundation</a></div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""><div><div class="">On May 5, 2015, at 3:55 AM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I propose we apply NIST Privacy Engineering principles to the HEART profiles. This would mean designing the profiles to allow policy to be introduced at the appropriate layer in the protocols and no sooner.<br class=""><br class=""></div>The most important aspects of Privacy Engineering in the HEART context are (in rough order of importance) open source, anonymity, pairwise pseudonymous identity, transparency, notice, data minimization, persistence minimization, and subject-centrality. <br class=""><br class=""><div class=""><div class="">0 - Open Source - HEART MUST allow for implementation by open source Clients and open source authorization servers as built by the Subject.<br class=""></div><div class=""><br class="">1 - Anonymity - HEART MUST allow for anonymous access when policy allows.<br class=""><br class=""></div><div class="">2 - Pairwise Pseudonymous Identity - HEART MUST support pairwise pseudonymous identity for longitudinal aggregation of data by a single Resource Server. For the purpose of the Privacy
Engineering exercise, we need a definition of "known to the practice" as
the in-person identification of the Subject without recourse to
external verification or ID proofing. The requirement for verified identity or other policy-dependent attributes such as a discoverable pseudonym are to be separate from the core design of HEART profiles.<br class=""><br class="">3 - Transparency - HEART MUST allow for the Subject to get an on-line Accounting for Disclosures while preserving a pairwise pseudonymous identity.<br class=""><br class=""></div><div class="">4 - Notice - HEART MUST allow for notice to Subjects that are willing to share a voluntary and possibly insecure notification address.<br class=""><br class=""></div><div class="">5 - Data Minimization - HEART MUST not impose minimum information disclosure requirements by design.<br class=""><br class=""></div><div class="">6 - Persistence Minimization - HEART SHOULD support automated, limited access to data by reference in order to reduce the incentive for Clients to persist unnecessary copies of the subject's data.<br class=""><br class=""></div><div class="">7 - Subject Centrality - aka the Multiple Portals Problem - HEART SHOULD allow for Subjects to specify their preferred Authorization Server in a domain-neutral (across legal, finance, health, education domains) unless expressly prohibited by law.<br class=""></div><div class=""><div class=""><br class=""></div><div class="">I've copied two NIST folks involved in privacy engineering and the NSTIC principles in order to make sure I'm interpreting these correctly.<br class=""><br class=""></div><div class="">Adrian<br clear="all" class=""></div><div class=""><br class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><font size="1" class=""><br class=""><font size="2" class="">Ensure Health Information Privacy. Support Patient Privacy Rights.<br class=""></font></font><span style="font-size:11pt" class=""><font size="1" class=""></font></span><font size="2" class=""><a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><font color="blue" class=""><u class="">http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue" class=""><u class=""> </u></font></font><span style="font-size:11pt" class=""></span><span style="font-size:11pt" class=""></span><span style="font-size:11pt" class=""><font size="1" class=""> <br class=""></font><div class=""></div></span><br class=""></div></div>
</div></div></div></div>
_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart<br class=""></div></div><br class=""></div></div></div></div></body></html>