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

Adrian Gropper agropper at healthurl.com
Sat Jul 25 21:47:08 UTC 2015


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


More information about the Openid-specs-heart mailing list