[Openid-specs-heart] "Individual-to-NPE" sharing episodes in UMA use cases, and "design pattern" solution options

Tue Oct 20 15:30:34 UTC 2015

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.

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.

What identifying data needs to be shared among users to access Alice's 
[current] authorizations?  What is its provenance?

*Glen F. Marshall*
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com

On 10/19/15 16:00, Eve Maler wrote:
> I promised to write this up, and hopefully I'll make it before the 
> deadline of today's call.
>
> 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 *is, or is the agent of,* a "non-person 
> entity" or NPE, such as a hospital, government agency, or company.
>
> 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 *do some profiling in these areas*.
>
> Here are four patterns I can think of:
>
>  1. *Individual-to-agent-of-NPE*: 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).
>  2. *Individual-to-NPE*: 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.
>  3. *Individual-to-role*: Alice the individual RO shares with "any RqP
>     who can prove they have been assigned the role 'works for NYP'".
>  4. *Individual-to-individual*: Alice the individual RO shares with
>     "the individual RqP who can prove they control the identifier
>     'bob at 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.
>
> 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.
>
> Each pattern has pros and cons. Briefly:
>
>   * 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? :-)
>   * 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.
>   * 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?
>   * 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?
>
> *Eve Maler
> *ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151020/ff88a28e/attachment.html>