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

Eve Maler eve.maler at forgerock.com
Tue Oct 20 02:58:54 UTC 2015


Hi Gunther-- Thanks for speaking up!

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 cardio-unit at nyp.org"?)

*"T"-for-technical observation coming...* 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 *will use* *Alice's* *AS* whenever he wants to
further share her resource with some proxy-for-Bob, and proxy Charlie only
*uses* *Alice's* *AS* 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.

If Alice were to share with cardio-unit at nyp.org, 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.


*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!

On Mon, Oct 19, 2015 at 3:13 PM, Meyer, Gunther <
Gunther.Meyer at allscripts.com> wrote:

> Hi All!
>
>
>
> First off, thank you for letting me participate in this discussion.  And
> please excuse the Newbie questions or suggestions!
>
>
>
> 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
>
> 1.       If the provider is not available, someone else that is their
> proxy must be able to access it.
>
> 2.       I may not know the provider, for example if this is the first
> time at the practice (might be an edge case?)
>
>
>
> 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)
>
>
>
> Could someone please share the link to the BLT presentation, that sounded
> very interesting.
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> Regards
>
>
>
> Gunther
>
>
>
> *Gunther Meyer* |
> *Architect **Allscripts* | 8529 Six Forks Road | Raleigh, NC |27615
>
>
> 919.329.1466| P
>
> 919.457.4466| F
>
>
> *gunther.meyer at allscripts.com <gunther.meyer at allscripts.com>* |
> www.allscripts.com
>
> Corporate Headquarters l 222 Merchandise Mart Plaza l 20th Floor l
> Chicago, IL l 60654
>
>
>
>
>
>
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Monday, October 19, 2015 4:00 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] "Individual-to-NPE" sharing episodes in
> UMA use cases, and "design pattern" solution options
>
>
>
> 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/8f37cf22/attachment.html>


More information about the Openid-specs-heart mailing list