[Openid-specs-heart] Draft HEART Meeting Notes 2016-07-25

[Sarah Squire]

Attending:

Debbie Bucci

Sarah Squire

Kathleen Connor

Thompson Boyd

Nancy Lush

Eve Maler

Cait Ryan

Walter Kirk

Adrian Gropper

Ken Salyards

Scott Shorter

Oliver Lawless

Dale Moberg

Julie Maas

Glen Marshall

Jin Wen

Hope Morgan

Celestin Bitjonck

Jim Kragh

Debbie:

I would like to focus on understanding the resource sets and how they’re
used.

I will assume that the resource server that has a relationship with the
authorization server, it seems like each rs will have an as. Typically,
wouldn’t the client be registered with the authorization server as well?

Eve:

If this were straight OAuth, it would be true anyway. OAuth works in a way
so we would call it all narrow ecosystem.

Debbie:

What I didn’t understand is that OIDC is an API and you have a protection
API and these layer on top of the OAuth protocol, right?

Eve:

Right. They’re UMA standardized bits of the protocol that didn’t exist in
OAuth. Similar to the way that OIDC invented its own identity API and
OAuth-protected it.

Debbie:

And you have similar endpoints for UMA authorization and protection.

Eve;

Right. Those are OAuth protections of the UMA API.

Debbie:

When the resource server registers the resource set and scopes, does that
happen twice?

Eve:

The second time that wording appears - maybe a better wording would be
registering permission. It’s now a particular client acting on behalf of a
particular Bob. In the first one, there’s no client in the picture yet.

Debbie:

Wouldn’t the client know what resources it wants when it goes to the
resource server?

Eve:

Yes, but it doesn’t know the resource set id, it just hits a URL. It gets
back information in the header telling it where to take the permission
ticket.

Debbie:

So a client goes to a FHIR API, and the resource server has registered with
the AS. So the client then has to go to the AS?

Eve:

It’s no different from how OAuth protected resources work. The client has
to be aware of what it can do with the API and aware of the protection
mechanism.

Debbie:

So instead of Alice needing to add Bob as another authorized user for the
flows to that resource, the advantage of UMA is to give in-time, temporary
access without having to have that full authorization piece in place all
the time.

Eve:

The resource server could have invented a proprietary mechanism for
sharing. The upside of UMA is that you could go get an open-source library
and do it yourself. Also, OAuth isn’t built for sharing with another party.
You can also hook up a resource server to an authorization server set up by
another person or organization.

Debbie:

I realize it’s a burden for a patient or a consumer to have maybe hundreds
of endpoints, but if you’re thinking about a provider who has a resource,
that could be thousands. So the resource set is pre-registers so Alice can
set her authorizations.

Eve:

OAuth is a synchronous authorization grant. UMA enables asynchronous.

Debbie:

I’d like to address Kathleen’s comments

Adrian:

I want to talk about consent and authorization. Consent involves Alice and
the resource server. It’s a contract, effectively. Authorization is
something that happens when the client is available to be specified to
whoever is going to do the authorization - in this case the authorization
server. I think it will help everyone if we use consent and authorization
in this way.

Oliver:

Consent is an agreement between an individual and a server?

Adrian:

To the extent that you’re saying to someone who has your data, “here’s my
policy” that is a prior agreement.

Oliver:

You said there was a contract between the client and the server?

Adrian:

The contract is between the resource owner and the server.

Oliver:

Yeah, but the contract of consent is between the provider and the patient.
The method of transmission could change completely.

Glen:

Consent is really a policy aspect. It doesn’t imply anything technical.
Authorization has specific security meanings. Let’s not try to overload
these terms or create variant definitions.

Debbie:

We had hours and hours of arguments and discussion when we did privacy on
FHIR. Consent to me is a contract between the resource owner and the
requesting party.

Oliver:

All I’m saying is the technology is not the other endpoint.

Adrian:

I’ll drop it. I was trying to be helpful. I don’t want to go down a
rathole. The goal of UMA and HEART is to define protocols to be used for
health information exchange. Just like you might be asked by hospital to
consent to your information being shared, then there would be a series of
policies and other things to control what goes through the HIE. HEART fits
the same slot.

Debbie:

So for the last profile that we’re focused on - it’s the UMA profile for
FHIR. As a start, can we agree that the resource server is a FHIR server
and that the resources would be FHIR resources?

Oliver:

Yes, but it’s not just FHIR.

Debbie:

Agreed. We just need to layer on top of it.

Eve:

We’ve said that we’re profiling for FHIR as an exemplar, so it’s clear that
we’ll have some resource sets that are targeted at FHIR.

Kathleen:

While the clipboard idea is cool, there are some policy issues that might
hold that up. It might be better to pick a subset which could be used at
some point to create a clipboard. Just assume that this data is coming from
an EHR.

Debbie:

I don’t think we can assume that there’s confidentiality codes.

Kathleen:

If the patient adds data and marks it as confidential, when it goes back
into HIPAA-land, it may not have standing.

Adrian:

Let’s focus on the fact that we agreed that we’re talking about a FHIR
client talking to a FHIR server. Do we have a consensus on whether we’re
only dealing with patient-level resources?

Oliver:

That’s fine. It could be the case that this get launched at an introductory
level. You can’t enable this until you have agreements between the parties.

Adrian:

Whatever we do in HEART at the patient level has to be able to be mapped to
NYP patient form I mentioned earlier.

Kathleen:

There’s no problem with that. The term we’ve been using is consent
directive.

Debbie:

I would say that the RPT that is issued by the authorization server is a
release for information. Not specific to NYP, or any particular law.

Eve:

They contain entitlements and permissions. We’ve had trouble mapping roi
forms to UMA because there’s no equivalent.

Debbie:

There are some things we could enforce.

Oliver:

I think we should just keep going and see what syncs up.

Eve:

I would love to do that. We’ve had trouble mapping.

Oliver:

What if we just talk about a testing environment and keep going
incrementally, and then once there’s more detail.

Adrian:

If we agree to only use the limited set of terms - FHIR resources,
patient-level - can Eve draw up a sequence diagram?

Eve:

We are not doing an roi. We’re doing a consent directive. It’s more akin to
terms and conditions.

Debbie:

The RPT is a consent to release.

Ken:

Why don’t you just say it’s a FHIR consent directive?

Adrian:

We don’t share the same definition of consent. What’s the difference
between an ROI form and a consent directive?

Debbie:

I really want to put consent aside and talk about how you actually get an
RPT that a resource server defines resource set that Alice can set her
preferences to, that a client can request, and a resource server can
release.

Oliver:

I think the base case is the provider to the patient.

Debbie:

That’s not the use case we’re trying to do. Alice wants to share with
another provider.

Let’s say that we have the 15 base resources. Could the token that goes
back to the resource server have a subset of what’s there? If the client
asks for more than it’s allowed to have.

Eve:

The client attempts access by making API calls one at a time.

Eve (in chat):

My availability in August: Here Aug 1, absent Aug 8 (business trip to
Australia), here Aug 15, absent Aug 22 vacation), here Aug 29.

Nancy:

So you’d request each thing you want one at a time.

Debbie:

I thought the advantage of a resource set was to be able to find it all
with one.

Eve:

There are web resources, FHIR resources, and there’s a reason UMA calls
resource sets resource sets. The resource server is authoritative for its
own API, resource set boundaries and content are its own business. If we
made a ‘first visit resource set’ allowing for a single API call that
returns that information.

Debbie:

Can she set individual scopes on the resource set?

Eve:

Yes. If you have a fitness watch, your scopes could be kinds of
information, or kinds of access. It’s going to be odd if they’re not
orthogonal to each other.

Debbie:

So my question is if I request meds, allergies, and conditions. When Alice
is presented with her authorization. Can she say that her dentist can’t
have meds? Can she pare that down?

Eve:

If someone is asking for information, and you want to send less
information, that’s a very hard technical question. In access management,
that’s a very hard problem to solve.

Debbie:
So if we need a subset, we will need multiple data sets.


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