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

[Sarah Squire]

The NIST privacy engineering objectives, as outlined on slide 8 of this
deck:
http://csrc.nist.gov/projects/privacy_engineering/nist_privacy_engr_objectives_risk_model_discussion_deck.pdf

are predictability, manageability,  and confidentiality. Those three
objectives are exactly the point of the work that has already been done, so
I think we are firmly in line with the work of the NIST privacy engineering
group already.

Adrian, I don't see any reference to the eight principles you have
contextualized here. However, your outline of them provides value, and they
are certainly within the spirit of the HEART project. I don't have enough
familiarity with the format of these profiles to say whether or how they
should actually be codified. As far as your overarching concern, I don't
think that anyone here would disagree that privacy policy decisions should
not be hard-coded into the profiles at any layer.

Sarah

Sarah Squire
Engage Identity

PS Hi! I'm new here. I've met a few of you at IIW and elsewhere. Justin
gushed enough about the great work that's being done by this group that I
had to join in the fun. I look forward to working with you all.

On Tue, May 5, 2015 at 5:51 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> The beauty of FHIR/OAuth is indeed that HEART can design all layers of
> privacy. It's a unique opportunity. Identity, OpenID Connect, UMA, and
> RESTful / OAuth resources are not domain-specific to healthcare. HEART can
> enable the health industry and Argonaut to adopt privacy engineering in its
> implementation of FHIR by keeping policy out of all layers of the stack.
>
> Adrian
>
>
> On Tuesday, May 5, 2015, Moehrke, John (GE Healthcare) <
> John.Moehrke at med.ge.com> wrote:
>
>> NIST is improving but are not as complete as other standards.  See my
>> article.
>> http://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html?m=1
>>
>> Privacy by design is great when doing design. But it assumes you are
>> doing all layers of design.
>>
>> John
>>
>> Sent from my iPhone
>>
>> On May 4, 2015, at 11:15 PM, Debbie Bucci <debbucci at gmail.com<mailto:
>> debbucci at gmail.com>> wrote:
>>
>> 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
>> <mailto: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/
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net<mailto:
>> Openid-specs-heart at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net<mailto:
>> Openid-specs-heart at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>
>
> --
> 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/4b8677ec/attachment-0001.html>