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

Fri Jul 31 16:01:05 UTC 2015

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150731/64979e16/attachment-0001.html>