[Openid-specs-heart] "Individual-to-NPE" sharing episodes in UMA use cases, and "design pattern" solution options
Justin Richer
jricher at mit.edu
Tue Oct 20 06:43:18 UTC 2015
Inline:
On 10/19/2015 10:58 PM, Eve Maler wrote:
> 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 <mailto:cardio-unit at nyp.org>"?)
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 "cardio-unit at nyp.org"
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:
- Alice enters "bob at nyp.org" into her AS's policy page
- Alice's AS does a webfinger lookup on "bob at nyp.org" to find the
OpenID Connect Issuer for that identifier (let's say https://id.nyp.org/
in this example)
- Alice's AS sets a policy that if someone comes in with the "email"
field set to "bob at nyp.org" from the "https://id.nyp.org" server we just
discovered, and "email_verified" is set to "true", then to let them
access things
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 "bob at nyp.org" or "cardio-unit at nyp.org" 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.
>
> *"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
> <mailto: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.
>
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.
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.
-- Justin
> *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 <mailto: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 <tel:919.329.1466>| P
>
> 919.457.4466 <tel:919.457.4466>| F
>
>
> _gunther.meyer at allscripts.com
> <mailto:gunther.meyer at allscripts.com>_| www.allscripts.com
> <http://www.allscripts.com/>
>
> Corporate Headquarters l 222 Merchandise Mart Plaza l 20^th Floor
> l Chicago, IL l 60654
>
> **
>
> __
>
> **
>
> *From:*Openid-specs-heart
> [mailto:openid-specs-heart-bounces at lists.openid.net
> <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
> <mailto: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 <tel:%2B1%20425.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/89fd968f/attachment-0001.html>
More information about the Openid-specs-heart
mailing list