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

Tue May 5 19:59:21 UTC 2015

It's 2015 and HEART has benefit of Principles, Objectives and Requirements:

- NIST is providing the Privacy Engineering Objectives;
- NIST is also providing the NSTIC Principles;
- State laws have codified some Fair Information Practice Principles 40
decades ago - which are still ignored for being "too hard" to implement in
practice;
- The largest of private corporations, Apple, has introduced privacy-based
Requirements such as pairwise pseudonimity (HealthKit, ApplePay), and
"Apple will not see your data" and "ResearchKit is open source software"
into some of their product lines;
- EU regulators are codifying privacy practices as fast as they can and
challenging the U.S. sectoral regulation model at a time when people have a
growing choice of where to host their information services.

Regardless what we call the list that I introduced, I submit to you that
something like it could serve as an engineering framework for our profiles.
I'm hoping it can drive our consensus faster and make HEART relevant from a
cross-sectoral, human perspective.

Adrian

On Tuesday, May 5, 2015, Lefkovitz, Naomi B. <naomi.lefkovitz at nist.gov>
wrote:

>  Adrian,
>
>  Thank you for the opportunity to weigh in. I think some of the
> nomenclature may be creating some confusion. As Sarah noted, NIST has put
> out three privacy engineering objectives for consideration. We’ll be
> putting out a refined set later this year for more comment. The privacy
> engineering objectives function as general system properties. That is, they
> are useful in thinking about the types of properties you want your system
> to have in order to enable the kinds of privacy protections you want your
> system to manifest. I think what you have created are specific
> privacy-based requirements for HEART. They look as if they are derived from
> the Fair Information Practice Principles, in part. I’m not sure if you
> might have drawn on other sources as well.
>
>  Hopefully, I’ve been able to clarify some of the distinctions between
> principles, objectives and requirements. Please let me know if there are
> other contributions I can make.
>
>  Naomi
>
>   —
> Naomi Lefkovitz
> Senior Privacy Policy Advisor
> National Institute of Standards and Technology
> U.S. Department of Commerce
> 301-975-2924
> naomi.lefkovitz at nist.gov
> <javascript:_e(%7B%7D,'cvml','naomi.lefkovitz at nist.gov');>
>
>
>   From: Sarah Squire <sarah at engageidentity.com
> <javascript:_e(%7B%7D,'cvml','sarah at engageidentity.com');>>
> Date: Tuesday, May 5, 2015 at 1:37 PM
> To: Adrian Gropper <agropper at healthurl.com
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>>
> Cc: "Moehrke, John (GE Healthcare)" <John.Moehrke at med.ge.com
> <javascript:_e(%7B%7D,'cvml','John.Moehrke at med.ge.com');>>, Microsoft
> Office User <naomi.lefkovitz at nist.gov
> <javascript:_e(%7B%7D,'cvml','naomi.lefkovitz at nist.gov');>>, "
> openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>" <
> openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>>,
> Mike Garcia <michael.garcia at nist.gov
> <javascript:_e(%7B%7D,'cvml','michael.garcia at nist.gov');>>
> Subject: Re: [Openid-specs-heart] Taking Privacy engineering to HEART
>
>   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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150505/210e0c50/attachment.html>