<div dir="ltr"><div><div><div>Let me try to simplify this convoluted thread.<br><br></div>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.<br><br></div>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.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 1:20 PM, Id Coach <span dir="ltr"><<a href="mailto:coach@digitalidcoach.com" target="_blank">coach@digitalidcoach.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Adrian replied to me (offlist):<br>
<blockquote type="cite"><span class="">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></span><span class="">
On Thursday, July 23, 2015, Identity Coach <<a href="mailto:coach@digitalidcoach.com" target="_blank"></a><a href="mailto:coach@digitalidcoach.com" target="_blank">coach@digitalidcoach.com</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>
</span></blockquote>
<br>
In reply to:<span class=""><br>
<br>
<div>On 7/23/15 11:01 AM, Adrian Gropper
wrote:<br>
</div>
</span><blockquote type="cite"><span class="">
<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 href="https://github.com/offapi/rbac-23andme-oauth2" target="_blank">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>
</span><div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Tue, Jul 21, 2015 at 5:09 PM, Adrian
Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span>
wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<div dir="ltr">
<div>A post about harmonizing the Argonaut and HEART
approaches to FHIR:<br>
<br>
<a 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><font color="#888888"><br>
<br>
</font></span></div>
<span><font color="#888888">Adrian<br>
</font></span></div>
</span><span class=""><div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 17, 2015 at 7:52
AM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank"></a><a 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"><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 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 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>
</span></blockquote>
</div>
</div>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><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"><font size="1"></font></span><font size="2"><a 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><div></div></span><br></div></div>
</div>