<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Adrian replied to me (offlist):<br>
<blockquote type="cite">Yes. Profiling is true of almost any OAuh
protected personal information resource. The subject may or may
not realize what they're consenting to.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I hope you will copy this conversation to the larger list
because I think my initial post may have been misunderstood by
others.</div>
<div><br>
</div>
Adrian<br>
<br>
On Thursday, July 23, 2015, Identity Coach <<a
href="mailto:coach@digitalidcoach.com"><a class="moz-txt-link-abbreviated" href="mailto:coach@digitalidcoach.com">coach@digitalidcoach.com</a></a>>
wrote:<br>
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.<br>
<br>
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.)<br>
<br>
j.<br>
</blockquote>
<br>
In reply to:<br>
<br>
<div class="moz-cite-prefix">On 7/23/15 11:01 AM, Adrian Gropper
wrote:<br>
</div>
<blockquote
cite="mid:CANYRo8j_bE0oXgUKAf3psJCwZw8Csg+5c5Q6b329woBPm453NQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/offapi/rbac-23andme-oauth2">https://github.com/offapi/rbac-23andme-oauth2</a><br>
<br>
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?<br>
<br>
</div>
<div>Adrian<br>
</div>
<div><br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 21, 2015 at 5:09 PM, Adrian
Gropper <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>A post about harmonizing the Argonaut and HEART
approaches to FHIR:<br>
<br>
<a moz-do-not-send="true"
href="http://thehealthcareblog.com/blog/2015/07/20/standards-alone-are-not-the-answer-for-interoperability/"
target="_blank">http://thehealthcareblog.com/blog/2015/07/20/standards-alone-are-not-the-answer-for-interoperability/</a><span
class="HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
<span class="HOEnZb"><font color="#888888">Adrian<br>
</font></span></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 17, 2015 at 7:52
AM, Adrian Gropper <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:agropper@healthurl.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:agropper@healthurl.com">agropper@healthurl.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I
think all of us agree with Jocelyn Samuels
that health data privacy and security can
coexist ( <a moz-do-not-send="true"
href="http://www.fiercehealthit.com/story/jocelyn-samuels-privacy-and-data-sharing-can-coexist/2015-06-04"
target="_blank">http://www.fiercehealthit.com/story/jocelyn-samuels-privacy-and-data-sharing-can-coexist/2015-06-04</a>
). What does this specifically mean in the
context of HEART and our current conversation
about OAuth and UMA profiles?<br>
<br>
</span>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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.)</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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.</span><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">
This protects the security interest of the
RS and the privacy interest of the RO. </span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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. </span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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.</span></p>
<br>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">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.</span></p>
<span><font color="#888888"><br>
<span
style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Adrian</span><br
clear="all">
<br>
-- <br>
<div>
<div dir="ltr">Adrian Gropper MD<span
style="font-size:11pt"></span><font
size="1"><br>
<font size="2">Ensure Health
Information Privacy. Support Patient
Privacy Rights.<br>
</font></font><span
style="font-size:11pt"></span><font
size="2"><a moz-do-not-send="true"
href="http://patientprivacyrights.org/donate-2/"
target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font
color="blue"><u> </u></font></font><span
style="font-size:11pt"></span><span
style="font-size:11pt"></span><span
style="font-size:11pt"><font size="1">
<br>
</font></span><br>
</div>
</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>