[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 23:14:47 UTC 2016

We're all trying to figure out how to square "risk/reward" challenge -- and
hey, both patients and providers have 'em. :-) (That was actually the
subject of my recent keynote
<https://www.youtube.com/watch?v=BiRr5Uk9PNI&feature=youtu.be> at the
European Identity and Cloud conference, where I used HEART as a
centerpiece...) Thought it might be interesting to share this quote:

*"The value of keeping some personal information protected, and the value
of it being known, are almost entirely context-dependent and contingent on
essentially uncertain combinations of states of the world. Privacy
sensitivities and attitudes are subjective and idiosyncratic, because what
constitutes sensitive information differs across individuals."*

-- The Economics of Privacy, Alessandro Acquisti et al., March 2016
<http://people.duke.edu/~crtaylor/Privacy_Survey.pdf>

Confidentiality codes are just a bureaucratic best guess at what some
patient will consider sensitive. We're entering a realm of directed sharing
that lets the patient override the RS's risk management strategy through
confidentiality codes because the patient has more say than they used to.

We're at a technical cusp because we need to figure out whether the
override mechanism is implicit ("I don't care how you, RS, classified this
data -- I want it shared anyway by virtue of my 'consent power'") or
explicit ("I want you, RS, to *reclassify* this data in some fashion").

I strongly suspect it's the former.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*

On Wed, Jul 27, 2016 at 4:04 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Go Aaron!
>
>
> On Wednesday, July 27, 2016, Aaron Seib <aaron.seib at nate-trust.org> wrote:
>
>> The consumer always has the right to have access to data about them.
>>
>> They have the right to direct you to share it with the third party of
>> their choosing regardless of what bright lines have been burned into the
>> brains of security and privacy professionals who have been relied upon to
>> exchange data in compliance with the law when the scope  of exchange was
>> entirely about sharing with another covered entity.
>>
>> I urge anyone who hasn't gotten the message to look at OCR's guidance
>> from this year.
>>
>> It frightens me to think there are folks who work in this space and feel
>> they have the paternalistic power to tell someone what they are allowed to
>> do with their rights.
>>
>> If HEART isn't about embracing the promise of consumer directives it is a
>> waste of time.
>>
>> Aaron Seib
>>
>> The trick to establishing trust is to avoid all tricks.  Especially
>> tricks on yourself.
>>
>>
>> -------- Original message --------
>> From: Eve Maler <eve.maler at forgerock.com>
>> Date: 7/27/16 4:54 PM (GMT-05:00)
>> To: "Glen Marshall [SRS]" <gfm at securityrs.com>
>> Cc: HEART List <openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] Resources vs Resource sets
>>
>> This is a great discussion from my perspective. We've come to the nub
>> here -- about what "patient centricity" means, risk appetite of the service
>> operator/institution, and other matters.
>>
>> I don't know how it works in health IT regulatory regimes and am eager to
>> find out. But in some other existing and emerging regulatory regimes,
>> gathering individual consent is a key consideration -- and fast becoming
>> *the* key consideration -- in mitigating organizational risk for data
>> transfer. That is, if the customer/consumer/end-user consents, that trumps
>> other constraints.
>>
>> UMA's proposition, of course, goes farther than enabling "reactive"
>> consent, by enabling "proactive" consent as well -- what might be called,
>> ahem, "consent directives" :-), or authorization policy, or sharing
>> instructions, or delegation of access, etc.
>>
>> In other words, it's now possible to ask people what they want shared,
>> and then *do what they say* (within the law). The benefits go beyond
>> compliance, all the way to demonstrating trustworthiness and "building
>> trusted digital relationships".
>>
>> It seems that confidentiality codes are first and foremost a tool of
>> compliance, not of Alice's wishes. We have two humps to get over in
>> leveraging them:
>>
>>    - Use cases: If the FHIR API server/UMA resource server were to
>>    transfer these codes to the UMA authorization server, what use are they to
>>    the AS and/or to the patient/UMA resource owner?
>>    - Logistical: Is this transfer even in scope for HEART?
>>
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> *ForgeRock Summits and UnSummits* are coming to
>> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>>
>> On Wed, Jul 27, 2016 at 1:03 PM, Glen Marshall [SRS] <gfm at securityrs.com>
>> wrote:
>>
>>> The boundary of existing regulatory mandates for privacy and security is
>>> a bright line.  It defines the minimum we in health IT must achieve.
>>> Anything beyond that either anticipates regulatory change or states an
>>> objective or some sort.
>>>
>>>
>>>
>>> In the case of covered entities’ objectives, we can assume they have
>>> performed HIPAA-required risk analysis and set risk management policies
>>> accordingly. I believe that OAuth and UMA operate most effectively in a
>>> such a businesslike risk-mitigation environment, where the semantics of the
>>> security and privacy metadata are unambiguous.
>>>
>>>
>>>
>>> When we honor patient-specific privacy choices, we ignore covered entity
>>> risk assessment and in-common semantics.  Patients are under no obligation
>>> to perform a formal business risk analysis or articulate it in a
>>> commonly-understood way.  Their choices may be realistic or not, articulate
>>> or not.  We have no simple objective basis to assess, let alone enforce,
>>> them.
>>>
>>>
>>>
>>> It is a philosophic ethical question as to how we honor patient privacy
>>> choices.  It is not clear to me that the health IT marketplace is ready to
>>> answer it.
>>>
>>>
>>>
>>>
>>>
>>> Glen F. Marshall
>>>
>>> Consultant
>>>
>>> Security Risk Solutions, Inc.
>>>
>>> 698 Fishermans Bend
>>>
>>> Mount Pleasant, SC 29464
>>>
>>> Tel: (610) 644-2452
>>>
>>> Mobile: (610) 613-3084
>>>
>>> gfm at securityrs.com
>>>
>>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>>
>>>
>>>
>>> *From:* Openid-specs-heart [mailto:
>>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Aaron Seib
>>> *Sent:* Wednesday, July 27, 2016 14:25
>>> *To:* Adrian Gropper <agropper at healthurl.com>; Salyards, Kenneth
>>> (SAMHSA/OPPI) <Kenneth.Salyards at samhsa.hhs.gov>
>>> *Cc:* HEART List <openid-specs-heart at lists.openid.net>
>>> *Subject:* Re: [Openid-specs-heart] Resources vs Resource sets
>>>
>>>
>>>
>>> I don't understand why we would even ask the consumer what their
>>> preference is if they can't change a default used by a Covered Entity?
>>>
>>>
>>>
>>> That is the entire point.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Aaron Seib
>>>
>>>
>>>
>>> The trick to establishing trust is to avoid all tricks.  Especially
>>> tricks on yourself.
>>>
>>> _______________________________________________
>>> 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/20160727/a58c850a/attachment.html>