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

Eve Maler eve.maler at forgerock.com
Sat Aug 1 18:40:17 UTC 2015


Ah, I see now. Among all of the deployment ecosystem choices for UMA,
you're suggesting that that particular choice -- what I've been calling a
"wide ecosystem" (but there's probably a better, more precise name for it)
-- has a particular potential benefit in terms of a liability shift from RS
to AS based on RO actions. (Side note: I now see that this is the same
topic you've been bringing up in the UMA WG for its nascent legal subgroup.)


*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 Fri, Jul 31, 2015 at 10:45 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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/20150801/139ea1ea/attachment-0001.html>


More information about the Openid-specs-heart mailing list