<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Inline:<br>
<br>
<div class="moz-cite-prefix">On 10/19/2015 10:58 PM, Eve Maler
wrote:<br>
</div>
<blockquote
cite="mid:CAMPbGmj2ZHnDhB24zv76vDXB5He_7WF9Q79N6cLb4vqyBWsGCg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">Hi Gunther-- Thanks for speaking up!
<div><br>
</div>
<div>Interestingly, sharing with the hospital NPE could possibly
feel just like sharing with a person with some identifier, if
the resource owner is told what the hospital's identifier is
and it's in a familiar format. Over time, we've all no doubt
observed that email addresses, and things that look like them,
are extremely powerful tools for representing identities --
and even groups of them (because an email address can be an
"alias"). As long as the address isn't literally a shared
account, which is just bad news security-wise, maybe that
pattern can be exploited somehow. ("Alice shares heart data
stream with <a moz-do-not-send="true"
href="mailto:cardio-unit@nyp.org">cardio-unit@nyp.org</a>"?)</div>
</div>
</blockquote>
<br>
It's important for us to remember that things that look like email
addresses don't have to actually be email addresses. As long as it's
an identifier that Alice can be told and can use, we're fine. I
rather like the example above, since Dr. Bob can hand Alice
<a class="moz-txt-link-rfc2396E" href="mailto:cardio-unit@nyp.org">"cardio-unit@nyp.org"</a> and she can probably generally understand
that. On the technical side, we need to specify what that alias
means, and this is likely to require profiling discovery. We took a
step in the Privacy on FHIR project by saying it *was* an email
address, using the following mechanism:<br>
<br>
- Alice enters <a class="moz-txt-link-rfc2396E" href="mailto:bob@nyp.org">"bob@nyp.org"</a> into her AS's policy page<br>
- Alice's AS does a webfinger lookup on <a class="moz-txt-link-rfc2396E" href="mailto:bob@nyp.org">"bob@nyp.org"</a> to find the
OpenID Connect Issuer for that identifier (let's say
<a class="moz-txt-link-freetext" href="https://id.nyp.org/">https://id.nyp.org/</a> in this example)<br>
- Alice's AS sets a policy that if someone comes in with the
"email" field set to <a class="moz-txt-link-rfc2396E" href="mailto:bob@nyp.org">"bob@nyp.org"</a> from the <a class="moz-txt-link-rfc2396E" href="https://id.nyp.org">"https://id.nyp.org"</a>
server we just discovered, and "email_verified" is set to "true",
then to let them access things<br>
<br>
This works great for individuals where the identifier happens to
match the email address (a common enough case for individuals of
course), but falls over for any other attribute sets. It's important
that whatever Alice enters be as simple as <a class="moz-txt-link-rfc2396E" href="mailto:bob@nyp.org">"bob@nyp.org"</a> or
<a class="moz-txt-link-rfc2396E" href="mailto:cardio-unit@nyp.org">"cardio-unit@nyp.org"</a> to kick off the whole process, otherwise it's
far too much work for the end users. Webfinger is the right starting
point, but I believe we need something beyond that.<br>
<br>
<blockquote
cite="mid:CAMPbGmj2ZHnDhB24zv76vDXB5He_7WF9Q79N6cLb4vqyBWsGCg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div><b>"T"-for-technical observation coming...</b> Another
perhaps interesting observation (knowing this will probably
annoy Justin until some perfected version of UMA shows up on
the horizon :-): Agents of NPE RqPs, such as all the employees
of one hospital, will probably all share the same mechanism
for identifying themselves to Alice's AS, at least for the
purpose of the initial consent to share claims with it. (This
is the "AAT issuance" flow.) If it were possible to make one
additional (huge?) simplifying assumption, which is that Dr.
Bob <i>will use</i> <i><b>Alice's</b></i> <i>AS</i> whenever
he wants to further share her resource with some
proxy-for-Bob, and proxy Charlie only <i>uses</i> <i>Alice's</i>
<i>AS</i> whenever he wants to share Alice's resource with yet
another hospital employee down the line, then we can easily do
this with "today's UMA", and Alice will easily be able to
inspect the sharing chain from a central location and cut off
access if she sees that the ability is being abused.</div>
<div><br>
</div>
<div>If Alice were to share with <a moz-do-not-send="true"
href="mailto:cardio-unit@nyp.org">cardio-unit@nyp.org</a>,
then -- I think -- whatever/whoever controls that alias would
indeed have to use Alice's AS to set/generate policies for
delegation chaining, in order for it to work for the next hop.</div>
</div>
<div class="gmail_extra"><br clear="all">
</div>
</blockquote>
<br>
I don't believe this is a simplifying assumption that we can
reasonably make, thanks to the caching issue brought up on today's
call. Dr. Bob will be at the junction between Alice's resource and
his own data set. Authorization decisions that he makes will not be
for Alice's resource, but they will be for *his copy* of *her
resource*. This is a key distinction that we can't ignore. Once the
data is copied, Alice effectively has no control over what happens
to it from a technical level. This is the nature of digital
information, and it's up to the business and legal layers to do
something about it. It's possible to reach back into the technical
space with a component like a Consent Receipt to represent rights
and responsibilities at these other layers, but Alice still has to
trust Dr. Bob to actually do what he said he'd do here, and I don't
think there's any way around that. Previous attempts to control
digital data once it's been released have been known as "DRM" and
are technologically untenable. <br>
<br>
Forcing Bob to go back to Alice's AS to set further policies has
other problems as well, as now Bob needs a login on the AS that's
capable of setting policies. In current UMA Bob also needs an
account capable of issuing OAuth tokens (the AAT) but that's a
separately broken thing in UMA that we should not rely on. Not the
least of which reason being that I want to tear that part of the
spec out as soon as reasonably possible, so we shouldn't start
building on it. There are other issues as well. Regardless, we don't
need that assumption to accomplish what we want to do, and it's
actively harmful and limiting if we make it.<br>
<br>
-- Justin<br>
<br>
<blockquote
cite="mid:CAMPbGmj2ZHnDhB24zv76vDXB5He_7WF9Q79N6cLb4vqyBWsGCg@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<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 moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org OpenUMA</a>
community!</p>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Oct 19, 2015 at 3:13 PM, Meyer,
Gunther <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Gunther.Meyer@allscripts.com" target="_blank">Gunther.Meyer@allscripts.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi
All!</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">First
off, thank you for letting me participate in this
discussion. And please excuse the Newbie questions
or suggestions!</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">From
a sharing of information point of view, if I put
myself in the shoes of a patient, I see that sharing
information with an individual makes sense, with the
following provisions</span></p>
<p><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>1.<span
style="font:7.0pt "Times New Roman"">
</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If
the provider is not available, someone else that is
their proxy must be able to access it.</span></p>
<p><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><span>2.<span
style="font:7.0pt "Times New Roman"">
</span></span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I
may not know the provider, for example if this is
the first time at the practice (might be an edge
case?)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">As
to the “group” concept, I did not want to get into
the middle of a debate. I just wanted to point out
that larger practices or hospital often consider
sharing in terms of groups of users rather than
individuals, and would therefore be more comfortable
with a sharing model that involved groups. Therefore
it is just something we need to consider (though we
might reject is as impractical)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Could
someone please share the link to the BLT
presentation, that sounded very interesting.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Also,
I think that the point that the application, C,
might have to be better defined seems to have merit,
unless the patient just authorizes the Hospital?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Finally,
I think that the patient sharing with an individual
doctor is interesting if the user’s intent can be
preserved during the import process. I think very
few users, however, will express much more than the
default “share with anyone as needed for treatment”
consent. Therefore, once the information is shared
with NYP, as discussed, it will be imported and then
the organizational security and policies will kick
in.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regards</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Gunther</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal" style="line-height:12.0pt"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22">Gunther
Meyer</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#707176">
|
</span><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365">Architect<br>
</span></b><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22">Allscripts</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#707176">
| 8529 Six Forks Road | Raleigh, NC |27615</span></p>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"> <br>
<a moz-do-not-send="true" href="tel:919.329.1466"
value="+19193291466" target="_blank">919.329.1466</a></span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">|
</span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">P</span></p>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"><a
moz-do-not-send="true" href="tel:919.457.4466"
value="+19194574466" target="_blank">919.457.4466</a></span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">|
</span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">F</span></p>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#616365"><br>
</span><u><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22"><a
moz-do-not-send="true"
href="mailto:gunther.meyer@allscripts.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:gunther.meyer@allscripts.com">gunther.meyer@allscripts.com</a></a></span></u><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">
|
</span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a
moz-do-not-send="true"
href="http://www.allscripts.com/" target="_blank"><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5b8f22"><a class="moz-txt-link-abbreviated" href="http://www.allscripts.com">www.allscripts.com</a></span></a></span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green">
</span></p>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#4d4f53">Corporate
Headquarters l 222 Merchandise Mart Plaza l 20<sup>th</sup>
Floor l Chicago, IL l 60654</span><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:green"></span></p>
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#76923c"> </span></b></p>
<p class="MsoNormal"
style="margin-bottom:5.25pt;line-height:15.0pt"><u><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#76923c"><span
style="text-decoration:none"> </span></span></u></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></b></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Openid-specs-heart [mailto:<a moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>Eve Maler<br>
<b>Sent:</b> Monday, October 19, 2015 4:00 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> [Openid-specs-heart]
"Individual-to-NPE" sharing episodes in UMA use
cases, and "design pattern" solution options</span></p>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">I promised to write this up,
and hopefully I'll make it before the deadline
of today's call.</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">The subject line introduces
what I hope will be useful consistent wording
for discussing these sorts of topics. Some of
our UMA use cases include episodes of
party-to-party resource sharing that involve a
resource owner who is an individual (say, a
patient or consumer), and a requesting party
that <b>is, or is the agent of,</b> a
"non-person entity" or NPE, such as a
hospital, government agency, or company.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Staying entirely within the
confines of the UMA protocol, a number of
different "design patterns" could be chosen
for deployment. Agreeing on which reasons to
use which patterns, and locking down any areas
of variability, could help make systems
interoperate with each other. The UMA
protocol, in fact, expects such variability
and recommends profiling to improve
interoperability. Thus, it seems a good idea
for us to figure out how much such types of
interop are in scope for us, and likely <b>do
some profiling in these areas</b>.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Here are four patterns I
can think of:</p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
<b>Individual-to-agent-of-NPE</b>: Alice the
individual RO shares with "the individual
RqP who can prove they control the
identifier 'Dr. Bob'" (possible also
constraining the client in use as well --
we'll leave that part out for this
analysis).</li>
<li class="MsoNormal">
<b>Individual-to-NPE</b>: Alice the
individual RO shares with "the NPE RqP that
can prove they control the identifier 'New
York Presbyterian Hospital'". Some process
yet to be determined, possibly involving
"chained delegation", ensures that Dr. Bob
and possibly others who work for NYP get
access thereafter.</li>
<li class="MsoNormal">
<b>Individual-to-role</b>: Alice the
individual RO shares with "any RqP who can
prove they have been assigned the role
'works for NYP'".</li>
<li class="MsoNormal">
<b>Individual-to-individual</b>: Alice the
individual RO shares with "the individual
RqP who can prove they control the
identifier 'bob@gmail'" (whom she knows is
her doctor because he provisioned her with
that gmail handle). Bob might do "chained
delegation" to share the resource with
himself as an employee of NYP.</li>
</ol>
</div>
<div>
<p class="MsoNormal">The reason interop
questions arise is because the process of UMA
trust elevation involves things like
claims-gathering and possibly step-up
authentication, and the policy-setting options
presented to Alice (which are out of band of
UMA, but nonetheless...) need to be driven by
these requirements. The ability of the
requesting sides to respond appropriately will
be triggered off of expectations about what
they'll be asked to cough up for trust
elevation.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Each pattern has pros and
cons. Briefly:</p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal">
The one I'm least enamored of is #3;
enterprise access control has had so much
trouble with RBAC, so can we expect adding
UMA to help? :-)</li>
<li class="MsoNormal">
Chained delegation can be very powerful. In
environments where everybody uses the same
UMA authorization server, a number of nice
value-add features can be supported, but
they tend to break down (at least with UMA
V1.0.x) when you add the ability for every
RO to choose their own AS.</li>
<li class="MsoNormal">
I worry about sharing with individual
doctors. It's very expedient, so people will
tend to do it as a path of least resistance
(think Google Apps!). And sometimes maybe
it's the right answer, particularly if
"chained delegation" can allow Alice to
track where her resource has been shared
further. But what if Dr. Bob leaves the
hospital/practice/whatever? Is this always
the right answer?</li>
<li class="MsoNormal">
Sharing with an NPE sounds elegant -- it's
what a recent POC of my acquaintance did.
But the "process yet to be determined"
mentioned above wasn't actually determined
yet, so there's that. :-) And you have the
problem of a system administrator who has
privileged identity credentials to the NPE
account -- as always -- having the key to a
pretty valuable kingdom. Maybe a cool
mitigation of this risk is to go with
sharing with individuals and tracking
sharing chains?</li>
</ul>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP
Innovation & Emerging Technology<br>
Cell <a moz-do-not-send="true"
href="tel:%2B1%20425.345.6756"
value="+14253456756"
target="_blank">+1 425.345.6756</a>
| Skype: xmlgrrl | Twitter: @xmlgrrl<br>
Join our <a moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org
OpenUMA</a> community!</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</body>
</html>