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

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Cait Ryan

Celestin Bitjonck

Chance Yohman

Dale Moberg

Edmund Jay

Glen Marshall

Jim Kragh

Julie Maas

Justin Richer

Kenneth Salyards

Nancy Lush

Sarah Squire

Scott Shorter

Thomas Sullivan

Thompson Boyd

Walter Kirk

Debbie:

Where are we on dates?

Justin:

We shouldn’t have dates as scopes. We should have them as query parameters.

Adrian:

I think I understand. HEART scopes don’t have to interact with query
parameters such as dates.

Justin:

We may want to define an extension to the token introspection response so
that it can express a date range. That would go in the semantic profile.

Glen:

I’m not concerned about being able to express those kinds of date range
things in the scopes. I am concerned that it places a burden on resource
servers to process them. What exists on the other side of the API isn’t
necessarily a server with a database. I’m also wondering whether these are
must-haves.

Justin:

If a resource server can’t process a response, it just does its best.

Adrian:

We are looking at having a notification endpoint where a resource server
could notify someone that it did its best.

Debbie:

Moving on - I think we clarified last week that authorization and consent
are two separate functions. Something I didn’t understand is the content of
the token, claims gathering, trust elevation, are all separate functions
and are part of the profile that we are working on. I hope over the next
few weeks we can get to a final semantic profile. As a group, can we come
to a consensus to work on the “Alice selectively shares health-related data
with physicians and others”?

Adrian:

I agree with this use case, but I insist that the use case consider the ROI
form.

Debbie:

I believe the RPT represents a release for information in general, but
you’re saying “form.” I don’t know that HEART’s responsibility is to
represent a “form.” The RPT is an authorization to release information.

Adrian:

We have to be able to explain how NYP eliminates the ROI form by using
HEART.

Glen:

I have an issue with where we’re headed because I’d like to specify that we
need to get information from a user, but codifying an exact form puts UX in
scope, and I don’t want UX in scope for our work.

Kenneth:

An RPT should generate a FHIR consent which facilitates exchange of
information that would take the place of the ROI form. If it can’t, we need
to change FHIR consent.

Adrian:

FHIR consent is optional and unnecessary and has nothing to do with what
we’re doing.

Debbie:

I disagree. If you look at the consent resource, it points out different
forms, and I was surprised that ROI wasn’t one of them.

Adrian:

The FHIR consent directive is trying to put Alice’s policy on the wire.
With respect to UMA, UMA says that policy is hidden. How the AS arrives at
a policy is not in scope for UMA. Either we have to standardize policy in
UMA, or this issue of the FHIR consent directive is entirely out of scope.
There is no standard for getting this in and out of the AS in a
standardized way.

Kenneth:

HEART should inform the standard, for sure. If you leave policy generation
as a black box, you’re not going to accomplish much.

Adrian:

I think we achieve a lot more by having this orthogonality.

Kenneth:

So you’re saying we don’t need FHIR resources?

Adrian:

No. I’m saying that I’m keeping FHIR out of the consent and authorization
business.

Kenneth:

We’re dealing with FHIR resources, and it happens that one of the resources
can contain policy. You’re artificially dividing FHIR resources and
excluding the one that actually has the most bang for the buck.

Debbie:

I think we need to get past this and clarify it. A client somehow - Dr. Bob
wants to get information from Alice’s resource server. Let’s say we don’t
have consent from Alice. When the resource server goes to the AS, can it
ask for consent when it registers? That would be separate from the
authorization token.

Glen:

What that’s really saying is that we need evidence of a ceremony of some
sort. That improves the level of authenticity.

Debbie:

So I guess that’s the permission ticket piece.

Sarah:

You can’t tie consent to resource registration because Alice doesn’t know
to whom she is giving consent yet.

Debbie:

When the resource server goes to the AS for a permission ticket, they
aren’t registering resources, there could be a separate call outside of
HEART that asks for consent.

Glen:

So this is a “MAY support” type thing?

Kenneth:

I think the key is there’s a presumption that Alice owns these resources,
and for the most part, that’s not likely. Alice would be the subject, but
not the owner.

Sarah:

But we are talking about patient-centered healthcare. That’s the whole
point.

Adrian:

The fact that UMA uses “resource owner” as opposed to “grantor” is
incidental. The resource owner is the resource server. Alice is only a
resource owner by semantic confusion.

Sarah:

According to the UMA spec, it’s Alice. It’s the person setting policy about
the resource.

Kenneth:

For most patients, the most frequent resource they would own is the consent.

Debbie:

If the resource server is registering a resource set for Alice only, or for
everything that’s on its server?

Justin:

The resource server needs to honor Alice’s wishes to the best of its
ability. Not all data may be properly marked up with confidentiality codes
and whatnot.

Adrian:

The resource server doesn’t have to know what Alice’s policies are. The
contract is to assume that the authorization server is representing Alice’s
policies.

Debbie:

When the client first visits the resource server, it may need consent for
policy reasons.

Kenneth:

This doesn’t make sense. It can’t be implemented.

Luis:

We just need agreement between the AS and RS about how to semantically talk
about resources and scopes.

Debbie:

So I could see that an RS would go to the AS and ask what Alice’s
preferences are.

Justin:

This was all part of the Privacy on FHIR work that we did last year. I
think the introspected token response is ideal, but there might be consent
directives that are outside the HEART project.

Sarah:

Furthermore, the reasoning behind keeping policy within the AS and keeping
it so that the Resource Server can’t see who Alice is sharing with. It
protects Alice’s privacy.


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160822/8c649fb8/attachment.html>