[Openid-specs-heart] Taking Privacy engineering to HEART

[Josh Mandel]

Hi Adrian,

Can you share a link to these principles? Googling " NIST Privacy
Engineering principles" (and, separately, Googling the principles
themselves) didn't help me on this one.

Thanks,

  Josh


On Mon, May 4, 2015 at 6:55 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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.
>
> 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.
>
> 0 - Open Source - HEART MUST allow for implementation by open source
> Clients and open source authorization servers as built by the Subject.
>
> 1 - Anonymity - HEART MUST allow for anonymous access when policy allows.
>
> 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.
>
> 3 - Transparency - HEART MUST allow for the Subject to get an on-line
> Accounting for Disclosures while preserving a pairwise pseudonymous
> identity.
>
> 4 - Notice - HEART MUST allow for notice to Subjects that are willing to
> share a voluntary and possibly insecure notification address.
>
> 5 - Data Minimization - HEART MUST not impose minimum information
> disclosure requirements by design.
>
> 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.
>
> 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.
>
> I've copied two NIST folks involved in privacy engineering and the NSTIC
> principles in order to make sure I'm interpreting these correctly.
>
> Adrian
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> *http://patientprivacyrights.org/donate-2/*
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=w5ZkaTRMmFvuPB0f6lMCI5Uw43ETdHFJcSM9gehATo4&s=Kob6B1EWUJnZYZQ6YcqP3N2nFHr0LMCmFW4TFqTWNZ0&e=>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=w5ZkaTRMmFvuPB0f6lMCI5Uw43ETdHFJcSM9gehATo4&s=d8aE9u7xVx3uQYv5zBJzXkn9tms_hlko63bs4Mj11D4&e=
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150504/dea43310/attachment.html>