[Openid-specs-heart] Draft HEART Meeting Notes 2016-08-29

[Eve Maler]

As referenced on the call, the UMA slide deck* (from 2012, it turns out!)
that discusses how the authorization server is a sort-of policy decision
point and the resource server is a sort-of policy enforcement point:

http://kantarainitiative.org/confluence/download/attachments/17760302/UMA%20and%20XACML%202012-10-18.pdf?api=v2

I'm thinking it would be a good idea to update this deck to modern times;
wouldn't be that hard to do, and it would be useful for various purposes. I
can present it briefly on a future call or on an ad hoc call for those with
special interest.

*Brief glossary/notes for reading this version of the deck:

   - AS used to be called an authorization manager or AM)
   - RS used to be called a host
   - RO used to be called authorizing user
   - Client used to be called requester
   - MTI means mandatory to implement
   - The Binding Obligations spec has been overcome by events; new work can
   be found at http://tinyurl.com/umalegal



*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *London and Paris!*

On Mon, Aug 29, 2016 at 2:01 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> Attending:
>
> Debbie Bucci
>
> Adrian Gropper
>
> Celestin Bitjonck
>
> Dale Moberg
>
> Edmund Jay
>
> Eve Maler
>
> Glen Marshall
>
> Jim Kragh
>
> Kenneth Salyards
>
> Luis Maas
>
> Nancy Lush
>
> Sarah Squire
>
> Scott Shorter
>
> Thomas Reineck
>
> Thomas Sullivan
>
> Thompson Boyd
>
> Deborah Wolf
>
> Walter Kirk
>
> Debbie:
>
> Let’s talk about whether the AS should expose Alice’s policy.
>
> Sarah:
>
> One of the reasons the AS doesn’t expose Alice’s policy to the resource
> server is to preserve her privacy.
>
> Eve:
>
> What is exposed to the RS is the result of the policy - i.e. an
> entitlement. That’s what’s put in the token. That’s what the resource
> server sees.
>
> Debbie:
>
> Is there any way to replicate existing policies?
>
> Eve:
>
> Any service that is UMA-enabled needs to perform some basic functions. One
> of the things we’re trying to presume is UMA-enablement of services. The
> part of work that is value-add for this group is a user interface for
> Alice, and backend functionality that would be things like testing for
> policy conditions.
>
> Debbie:
>
> A resource server might ask Alice’s authorization server what her policies
> are so that it can make decisions without having to go back to the AS every
> time.
>
> Sarah:
>
> The UMA spec as it’s written now says that the AS has to go back to the AS
> every time to get a token.
>
> Eve:
>
> Policy portability might be something services would add, so if Alice
> wants to switch to an authorization server that is in the same domain as
> her resource server, she could.
>
> Debbie:
>
> I had assumed that would be an early value-add as a way to adopt UMA. So,
> now I realize it’s not part of the protocol even though it could be added
> later.
>
> Adrian:
>
> In terms of HEART, if our goal is to have something that is
> patient-centric, then the framing of the question is incidental. The joy of
> UMA as it is now is that it is a delegation protocol that is
> patient-centric. I’m not sure that AS-portability is such a burden for
> Alice. She could just re-enter her policies. I would like to see privacy
> policies standardized so they are easier to compare.
>
> Eve:
>
> One is one-time changing of ASs, and one is various use-cases of
> federating various sources of policy.
>
> Debbie:
>
> If a resource server wants to know Alice’s preference, that would require
> consent.
>
> Sarah:
>
> I think you’re thinking about it in a different way. I think you’re saying
> that the resource server and the authorization server should be tightly
> coupled. But you really don’t want the resource server to have information
> about Alice’s sharing policies - those are private.
>
> Eve:
>
> This is the difference between narrow and wide ecosystems. In wide
> ecosystems, the AS becomes Alice’s agent. It executes her authorization
> decisions. The RS should only be stuck with looking out for its own
> liability.
>
> Adrian:
>
> We need to decide whether information sharing looks like a State HIE as it
> exists today, whether it looks like an ROI form, or whether it looks like a
> federation of vendors.
>
> Ken:
>
> Would we consider a FHIR server a resource server? If so, you delegate
> responsibility to that resource server to read and store information,
> right? So then you need an authorization server mechanism and the RS, which
> is seeing permissions to be able to determine what information gets
> retrieved from the RS. So what needs to happen is that these permissions
> which get generated from Alice’s policy. They translate into permissions
> for what the resource server will do. That makes it more manageable. In
> this world, are things like PDPs and PEPs still relevant?
>
> Eve:
>
> Policy decision point is an approximate name for an AS and Policy
> execution point is an approximate name for an RS, but there are definitely
> differences.
>
> Debbie:
>
> So for now, the AS holds the policy and the RS can’t see it. I think that
> might not be enough.
>
> Luis:
>
> The point of the UMA relationship is that the resource server is
> outsourcing the authorization decisions to the authorization server. From
> the business point of view, there has to be some contractual relationship
> between the two, but it’s not part of the protocol for that information to
> be put through.
>
> Debbie:
>
> I don’t think all services are going to speak UMA.
>
> Eve:
>
> I’m working on a narrow- to medium- ecosystem now. It’s like identity
> federations mostly are today. It’s a “circle of trust” not a “star of
> trust”. The metadata that supports those services are service-to-service
> metadata.
>
> Adrian:
>
> If you have a circle of FHIR servers around a central UMA authorization
> server, the AS would be supplied by a vendor who would build an interface
> allowing users to set policy. Then HEART would come along and say here’s a
> way for this circle of servers to do an ROI form release.
>
> Luis:
>
> I think we have to keep separate the policies that would be required in a
> trust community to make UMA work and the technical specifications of UMA.
>
> Eve:
>
> We have an UMA legal group that works on those policies.
>
> Debbie:
>
> I’m moving on to the ROI. What I’m confused about is that Adrian keeps
> talking about a form, whereas an RPT is a release in itself.
>
> Ken:
>
> You have to have something that represents a document like a FHIR consent.
>
> Adrian:
>
> I agree.
>
> Debbie:
>
> This is great!
>
> Adrian:
>
> I want a reference to the ROI form in the charter for the use case.
>
> Debbie:
>
> Eve, where do you want to take this use case next?
>
> Eve:
>
> The use case was supposed to drive our decision making on the technical
> profile. We had a really interesting discussion around scopes, and there’s
> a larger discussion we should still have about the specific flows we should
> drive toward. So, we had a flow around first-visit, and there could be a
> flow around transferring between one doctor and another. When you see it in
> that light, basic data for a first visit vs. existing records would involve
> more data. You start seeing how use-case-based resource exchange could be a
> benefit to Alice, but it starts to look different from a
> provider-to-provider view that many people have had to date. From Alice’s
> perspective, she just wants to get crap done. Do we want to see these use
> cases so that our specification becomes a product? UMA resource sets have
> the opportunity for even more abstraction than FHIR resources. We need to
> be sure of what our direction is.
>
> Debbie:
>
> It sounds like we’re moving to actually creating the profile?
>
> Eve:
> I think this queues up nicely, but we have to know why we’re doing it and
> what our design center is. I mentioned pro-active vs. re-active. Do we want
> Alice to be knowledgeable enough to press a share button and know who she’s
> supposed to share with? Or do we want her to get a notification from the
> doctor and respond to that? We need to talk about use case specificity.
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com
>
> _______________________________________________
> 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/20160829/1051c637/attachment.html>