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

Mon Oct 19 22:49:19 UTC 2015

Here's the link to the BLT presentation:
https://dl.dropboxusercontent.com/u/8909568/GIS%20-%20Privacy%20Engineering%20Health%20IT.pdf

Please add it to the minutes if anyone can and I'm happy to discuss further.

Adrian

On Mon, Oct 19, 2015 at 6: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 list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151019/56462189/attachment.html>