<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
For the individual-to-role pattern, HL7 has a role based access
control standard. It includes and extensive vocabulary of
healthcare roles, and it is extensible. This can be used to share
access control role semantics across authorization services. <br>
<br>
The individual-to-NPE and individual-to-role patterns presents some
interesting challenges. One of them is that the mapping of access
permissions depends on the location and work assignments. For
example, health care staff may be assigned to different care
locations and have legitimate access only to the patients' data for
that location. Similarly, the role assigned to a person will vary.
I do not know how amenable these cases are to technical solutions.
Current practice is to assume compliance of the staff to
institutional policies.<br>
<br>
What identifying data needs to be shared among users to access
Alice's [current] authorizations? What is its provenance? <br>
<br>
<div class="moz-signature">
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: (610) 644-2452<br>
Mobile: (610) 613-3084<br>
<a class="moz-txt-link-abbreviated" href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.SecurityRiskSolutions.com">www.SecurityRiskSolutions.com</a></p>
</div>
<div class="moz-cite-prefix">On 10/19/15 16:00, Eve Maler wrote:<br>
</div>
<blockquote
cite="mid:CAMPbGmgUpU_vg_2=E6uABhEE12fseGwcHxrRwE-kcybMzG8GFA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">I promised to write this up, and hopefully I'll
make it before the deadline of today's call.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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>.</div>
<div><br>
</div>
<div>Here are four patterns I can think of:</div>
<div>
<ol>
<li><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><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><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><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>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.</div>
<div><br>
</div>
<div>Each pattern has pros and cons. Briefly:</div>
<div>
<ul>
<li>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? :-)<br>
</li>
<li>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>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>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 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>
</div>
</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>