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

Adrian Gropper agropper at healthurl.com
Thu Jul 23 18:01:46 UTC 2015


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>
> 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/>
>>
>>
>
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
>


-- 
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/20150723/b3454bd7/attachment.html>


More information about the Openid-specs-heart mailing list