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

[Id Coach]

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
> <mailto: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 <mailto: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 <mailto: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/__  _
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150725/49b44c4a/attachment.html>