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

[Eve Maler]

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151019/e6c2a573/attachment.html>