[Openid-specs-heart] Vectors of Trust - HEART Edition

Fri Jul 31 17:45:08 UTC 2015

I was trying to make a different point about UMA: UMA can significantly
reduce the liability of the resource server when the resource server allows
the resource owner that's registering an authorization server to choose
whatever AS they want. This puts the onus of dealing with other family
members, for example, on the RO instead of the RS.

One of the places this is happening right now is Consent for biobanks that
include genetic testing including the $215 M Precision Medicine Initiative
announced by Obama. It's practically impossible to get "informed" consent
for this kind of research because it's impossible to know in advance what
the data will actually be used for and by whom. This poses problems when
the consent process itself skews the research population. For example, it
is well known that minorities are under-represented when this kind of
consent is used.

By allowing the patient who is being asked for consent (clinical or
research) to pick their own AS, UMA can reduce the liability of the
resource server that is the other party to that consent. This works two
ways. First, the responsibility for dealing with family members or other
secondary affected parties shifts to the resource owner. Second, the scope
of the registration-time consent itself can be much broader if it includes
provision for more specific authorization at a later time.

A specific example of the latter issue came up last week. A major research
program wanted consent for biobanking my blood and for genetic sequencing.
However, they did not actually have the funding to do the sequencing, only
to store the blood. They wanted me to agree in advance to the genetic
sequencing at some future date. Because this is only one of potentially
dozens of such requests, I do not want to leave a trail of blood and tissue
samples for whatever they want to do forever even if they do say that I can
revoke consent anytime. Does anyone keep track of the consents they have
given in writing or with OAuth? If the researchers would accept my AS as
the point of authorization then the various outstanding consents for my
samples would be all in one place (my AS) and I would be much more likely
to consent for them to store my sample.

OAuth can't do this. UMA can do this in a general way only if the resource
owner can choose their AS. As far as I'm concerned, this is the first issue
for HEART to resolve because both the value of the FHIR API and the various
security measures around it depend on this one simple precedent about the
AS.

Adrian

On Fri, Jul 31, 2015 at 12:01 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> Genetic information is indeed an interesting special case. For one, the
> data itself inherently is "about" multiple people. (However, other personal
> data can mimic this behavior. I'm reminded of the OPM breach, where people
> were made to convey personal information about other people as a condition
> of employment, and then that information was badly secured. Arrrgh.) For
> another, it's extremely nonvolatile, so when it's given away, the
> "half-life" is so long that you can't rely on any decay in its usefulness
> to bring the recipient back to you to get it again.
>
> In these cases, collecting strong purpose-of-use assurance claims from the
> requesting party and cranking up enforcement is what I start thinking of
> (in UMA terms).
>
> FYI, the design choice made in UMA (for V1, anyway) was to tie any one
> resource to only a single resource owner because of the complexity of
> figuring out multiple-RO-ship. You can model wide administrative access
> over a single resource through scopes (think of how Google Docs has only a
> single "owner" of a document, but can have many editors).
>
> Food for thought...
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
> On Sat, Jul 25, 2015 at 2:47 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Let me try to simplify this convoluted thread.
>>
>> Genetic information, and other private info that impacts multiple
>> individuals, including IoT, does not fit easily with an authorization model
>> where the relying party specifies the Authorization Server because there
>> may not be an absolute Resource Owner.
>>
>> By allowing the Resource Owner that registers with a Resource Server to
>> specify their Authorization Server, the issue of coordinating authorization
>> among the primary Resource Owner and their "relatives" is no longer a
>> problem for the institution. It will be up to any family that cares to
>> coordinate their Authorization servers accordingly.
>>
>> Adrian
>>
>> On Sat, Jul 25, 2015 at 1:20 PM, Id Coach <coach at digitalidcoach.com>
>> wrote:
>>
>>> Adrian replied to me (offlist):
>>>
>>> Yes. Profiling is true of almost any OAuh protected personal information
>>> resource. The subject may or may not realize what they're consenting to.
>>>
>>> The differed with genetic information is that the subject is not the
>>> only resource owner. Family members are partial,resource owners as well. In
>>> this case, the OAuth model for authorization is insufficient and something
>>> like UMA needs to be in play.
>>>
>>> I hope you will copy this conversation to the larger list because I
>>> think my initial post may have been misunderstood by others.
>>>
>>> Adrian
>>>
>>> On Thursday, July 23, 2015, Identity Coach < <coach at digitalidcoach.com>
>>> coach at digitalidcoach.com> wrote:
>>> This developer is using 23&Me data to do racial/disease/arbitrary
>>> profiling, giving certain genetic profiles access to certain info/web
>>> sites/databases and denying other profiles access.
>>>
>>> I thought this was interesting because of the good it can do (anyone
>>> with these genetic characteristics may be interested in this research or
>>> those treatments), and the bad (health service redlining, etc.)
>>>
>>>  j.
>>>
>>>
>>> In reply to:
>>>
>>> On 7/23/15 11:01 AM, Adrian Gropper wrote:
>>>
>>> Genomic and other family-related protected resources is another reason
>>> FHIR must allow a patient-specified UMA authorization server. Without UMA,
>>> there's no hope of coordinating access to family-related info. Here's a
>>> good example.
>>>
>>> https://github.com/offapi/rbac-23andme-oauth2
>>>
>>> My 23andMe genetic profile is already out there ready to be used in all
>>> sorts of ways. My release of this information impacts my entire family.
>>> Unless me and my family members can each choose their OAuth authorization
>>> server with UMA, what hope do we have of coordinating the release of this
>>> kind of information to various third parties?
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Tue, Jul 21, 2015 at 5:09 PM, Adrian Gropper <agropper at healthurl.com>
>>> wrote:
>>>
>>>> A post about harmonizing the Argonaut and HEART approaches to FHIR:
>>>>
>>>>
>>>> http://thehealthcareblog.com/blog/2015/07/20/standards-alone-are-not-the-answer-for-interoperability/
>>>>
>>>> Adrian
>>>>
>>>> On Fri, Jul 17, 2015 at 7:52 AM, Adrian Gropper <
>>>> <agropper at healthurl.com>agropper at healthurl.com> wrote:
>>>>
>>>>> I think all of us agree with Jocelyn Samuels that health data privacy
>>>>> and security can coexist (
>>>>> http://www.fiercehealthit.com/story/jocelyn-samuels-privacy-and-data-sharing-can-coexist/2015-06-04
>>>>> ). What does this specifically mean in the context of HEART and our current
>>>>> conversation about OAuth and UMA profiles?
>>>>>
>>>>> I'm adopting the phrase "vectors of trust" for this discussion because
>>>>> I think it applies to authorization in the same way it does to
>>>>> authentication. (For those that wish to dive in, there's a major healthcare
>>>>> patient authentication discussion underway in IDESG that you can ask me
>>>>> about.)
>>>>>
>>>>> Do scopes have anything to do with vectors of trust in the HEART
>>>>> authorization model? I'm having a hard time following the current
>>>>> discussion about scopes and how they relate to SMART on FHIR and Argonaut.
>>>>> To avoid the compromise of privacy vs. security we need to deal with the
>>>>> vectors of trust _before_ we profile scopes. This may be more true of UMA
>>>>> than it is for OAuth but I think it applies to both.
>>>>>
>>>>> To avoid a compromise between security and privacy, the RS must be
>>>>> granted a safe harbor for API access by the authenticated and autonomous
>>>>> resource owner. This protects the security interest of the RS and the
>>>>> privacy interest of the RO.
>>>>>
>>>>> The trust relationship between RS, AS, and Client must be designed to
>>>>> meet our Charter which includes a requirement of an "independent AS" that
>>>>> could be built by the RO. This is absolutely key to the scalability and
>>>>> generativity of HEART.
>>>>>
>>>>> It's less clear about how HEART will deal with a "built" Client or a
>>>>> client that is trusted only by the AS but not the RS. Who decides if the
>>>>> Client can participate in the "safe harbor by the authenticated and
>>>>> autonomous resource owner" contract? The profiling we do around OAuth and
>>>>> UMA should be able to solve this problem and it should probably be done
>>>>> ahead of the scopes discussion.
>>>>>
>>>>> I believe that once we understand the issues of an independent AS and
>>>>> of Client trust the difference between UMA vs. OAuth profiles, including
>>>>> scopes, in any particular use-case, will be easy to resolve.
>>>>>
>>>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>

-- 

Adrian Gropper MD

RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150731/9246f221/attachment-0001.html>