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

Tue Oct 20 11:04:28 UTC 2015

It seems to me that something is missing and I may be told its out of scope
but ...
The power of UMA, in my mind, is to provide asynchronous authorizations.

Example (as I am

Lets say upon the initial visit to Dr. Bob , it is suggested that Alice
should visit a specialist.  Dr Bob will often give multiple referrals to
consider .  (Let's assume electronically in some follow up email or
something) The advertised public identifier could be for Dr. Ted or the
practice with multiple specialist.  Often a specialist would like to gather
as much information as possible before initial visit.  Alice could help
facilitated that -even before she enters the office for the first time.
Should could enter those identifiers in her AS to assist with the referral
process.

I would think the gathering of (or at least availability) of identity
claims during the asynchronous binding ceremony of the specialist with
Alice's AS would be useful here. Which ones - policy out of scope but there
are probably HL7/FHIR attributes beyond typical identity claims to
consider.  The technical ability to do so I think should be in scope.
Alice does not have a direct relationship or precedence in the exchange as
in the provider to provider exchange use case.   There is an associated
burden with Alice at the center of her care that I am not certain we have
considered.

Its a grey area between info that Adrian would like to see  - indicated as
possibly in scope but needs profiles and the need_info process I see in the
UMA flow diagrams.

On Tue, Oct 20, 2015 at 2:43 AM, Justin Richer <jricher at mit.edu> wrote:

> 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"?)
>
>
> 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"
> <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" <bob at nyp.org> into her AS's policy page
>  - Alice's AS does a webfinger lookup on "bob at nyp.org" <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" <bob at nyp.org> from the "https://id.nyp.org"
> <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" <bob at nyp.org> or
> "cardio-unit at nyp.org" <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, 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> 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!
>>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
> _______________________________________________
> 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/5a3c4f6c/attachment.html>