<div dir="ltr">Ah, I see now. Among all of the deployment ecosystem choices for UMA, you're suggesting that that particular choice -- what I've been calling a "wide ecosystem" (but there's probably a better, more precise name for it) -- has a particular potential benefit in terms of a liability shift from RS to AS based on RO actions. (Side note: I now see that this is the same topic you've been bringing up in the UMA WG for its nascent legal subgroup.)</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jul 31, 2015 at 10:45 AM, Adrian Gropper <span dir="ltr"><<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"><div><div><div><div><div>I was trying to make a different point about UMA: UMA can significantly reduce the liability of the resource server when the resource server allows the resource owner that's registering an authorization server to choose whatever AS they want. This puts the onus of dealing with other family members, for example, on the RO instead of the RS. <br><br></div>One of the places this is happening right now is Consent for biobanks that include genetic testing including the $215 M Precision Medicine Initiative announced by Obama. It's practically impossible to get "informed" consent for this kind of research because it's impossible to know in advance what the data will actually be used for and by whom. This poses problems when the consent process itself skews the research population. For example, it is well known that minorities are under-represented when this kind of consent is used.<br><br></div>By allowing the patient who is being asked for consent (clinical or research) to pick their own AS, UMA can reduce the liability of the resource server that is the other party to that consent. This works two ways. First, the responsibility for dealing with family members or other secondary affected parties shifts to the resource owner. Second, the scope of the registration-time consent itself can be much broader if it includes provision for more specific authorization at a later time.<br><br></div>A specific example of the latter issue came up last week. A major research program wanted consent for biobanking my blood and for genetic sequencing. However, they did not actually have the funding to do the sequencing, only to store the blood. They wanted me to agree in advance to the genetic sequencing at some future date. Because this is only one of potentially dozens of such requests, I do not want to leave a trail of blood and tissue samples for whatever they want to do forever even if they do say that I can revoke consent anytime. Does anyone keep track of the consents they have given in writing or with OAuth? If the researchers would accept my AS as the point of authorization then the various outstanding consents for my samples would be all in one place (my AS) and I would be much more likely to consent for them to store my sample.<br><br></div>OAuth can't do this. UMA can do this in a general way only if the resource owner can choose their AS. As far as I'm concerned, this is the first issue for HEART to resolve because both the value of the FHIR API and the various security measures around it depend on this one simple precedent about the AS.<br><br></div>Adrian<br><div><br><br><br><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 12:01 PM, Eve Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.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">Genetic information is indeed an interesting special case. For one, the data itself inherently is "about" multiple people. (However, other personal data can mimic this behavior. I'm reminded of the OPM breach, where people were made to convey personal information about other people as a condition of employment, and then that information was badly secured. Arrrgh.) For another, it's extremely nonvolatile, so when it's given away, the "half-life" is so long that you can't rely on any decay in its usefulness to bring the recipient back to you to get it again.<div><br></div><div>In these cases, collecting strong purpose-of-use assurance claims from the requesting party and cranking up enforcement is what I start thinking of (in UMA terms).<div><br></div><div>FYI, the design choice made in UMA (for V1, anyway) was to tie any one resource to only a single resource owner because of the complexity of figuring out multiple-RO-ship. You can model wide administrative access over a single resource through scopes (think of how Google Docs has only a single "owner" of a document, but can have many editors).</div></div><div><br></div><div>Food for thought...</div></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div></font></span><div><div>
<br><div class="gmail_quote">On Sat, Jul 25, 2015 at 2:47 PM, Adrian Gropper <span dir="ltr"><<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"><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"><div><div>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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div bgcolor="#FFFFFF" text="#000000">
Adrian replied to me (offlist):<br>
<blockquote type="cite"><span>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>
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><br>
<br>
<div>On 7/23/15 11:01 AM, Adrian Gropper
wrote:<br>
</div>
</span><blockquote type="cite"><span>
<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>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>
<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><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></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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><span><br><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"><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>
</span></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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></div></div></div>
</blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div>