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

Sarah Squire sarah at engageidentity.com
Mon Aug 29 21:01:39 UTC 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160829/58375b29/attachment.html>


More information about the Openid-specs-heart mailing list