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

[Debbie Bucci]

Adrian

Your description sounds like a redux mix of FIPP, Privacy by Design
sprinkled with HIPPA.

 I see reference to the workshop and objectives.
http://csrc.nist.gov/projects/privacy_engineering/index.html

Do you have a link reference that lays out the principles you listed?













On Mon, May 4, 2015 at 9: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/*
> <http://patientprivacyrights.org/donate-2/>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150505/87f7a10d/attachment-0001.html>