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

[Sarah Squire]

Attending:

Debbie Bucci

Adrian Gropper

Brandon Williams

Cait Ryan

Dale Moberg

Edmund Jay

Eve Maler

Jin Wen

Jim Kragh

John Moehrke

Andy Keith

Luis Maas

Nancy Lush

Oliver Lawless

Sarah Squire

Scott Shorter

Thomas Sullivan

Thompson Boyd

Walter Kirk

Debbie

Let’s start with consent. Is the FHIR consent now going to be balloted?

John

That’s correct. HEART can be used without FHIR consent. It could be seen as
the way you record the rules that UMA is enforcing or it can be something
completely unrelated.

Debbie

So there could be a service that’s UMA enabled that gathers consent
directly, or may use consent to share. After those rules have been
recorded, that server could sent a FHIR consent to the resource server?

John

Although FHIR has an HTTP restful exchange model, that’s not the only way
in which FHIR resources can be used. You could have a FHIR resource server
that only holds FHIR consents and have n other resource servers with other
data. The interaction models are very similar to what we’ve been talking
about with UMA.

Debbie

I think that was one of the examples in Privacy on FHIR where the patient
recorded their preferences and then the information was sent to resource
servers or the authorization server.

Adrian

I think John and I see this the same way. I choose to characterize it as
the FHIR consent has nothing to do with HEART at this point in time.

John

I agree that a HEART-based system can operate without FHIR consent.
However, there are also cases in which someone wants to persist the rules
of the consent in some kind of an object. In those cases, FHIR consent can
be used for that purpose.

Adrian

Why do we care with regard to the HL7 vote?

John

I think you’re taking the ask that Glen put out too much to heart. He was
simply saying that the ballot was opening, and since this community is
interested in that concept, people might want to comment on it. I would not
advocate for a strong tie between the consent resource and HEART. I do
think the community should point out major disconnects or incompatibilities
between the two models.

Debbie

Does someone have a link to the ballot? When I think about why a resource
server would use a FHIR consent, I think about that referrals need to have
consent carried with them. There could be a resource set around referrals.
That seems to be a use case where that might happen. Alice wants to send
her records to Dr. Bob It might be appropriate for the resource server to
include FHIR consent in the payload.

John

Formal HL7 Ballot site http://www.hl7.org/ctl.cfm?action=ballots.home

direct FHIR content http://hl7.org/fhir/2016Sep/index.html

Adrian

I don’t think consent is essential as long as we can move ahead with the
resources and scopes discussion without solving this particular problem.
It’s a different issue.

Debbie

Are you saying an authorization to release is not consent?

Adrian

That’s exactly what I’m saying. The policies at the authorization server
are never shared.

Eve

Other than HL7, everybody else in the world uses consent in a different
way. They use it to mean opt-in and opt-out. Nobody else uses it that way
except UMA and HL7. I’ve been doing work on a new permissions taxonomy.
There’s a model that’s well known. You opt-in, you opt-out, it’s expressed
or implicit. It’s a very disempowered place for a user to be.

John

I agree that that’s a perception. That’s not our intention in the FHIR
resource. The intent is to enable.

Eve

I agree, but this conception is very common. HEART has the concept of
empowering by allowing people to decide ahead of time. Enterprise would
call that access management. Enterprises set up access policies, and then
they are executed. A consent directive is a phrase I love because directed
permissions are a great concept. So there are two separate worlds that are
combining. And then there’s a third world that has no concept of this. Most
of the rest of the world doesn’t use consent as empowered or directed. They
use it to mean reactive disempowered consent. They don’t overlap almost at
all.

Oliver

I think when you say that everyone is used to “reactive,” it’s because we
used to do it on paper.

Adrian

I made an impassioned plea two months ago to ask that we not use the word
“consent” at all. I’ve had to change that position. You articulated the
problem very clearly. We’re down a rathole.

Eve

There is a formal structure going up for ballot.

Oliver

Adrian was saying that he wants to pull out consent and say that it doesn’t
impact the other endpoint. How does that work without that?

Adrian

The other endpoint doesn’t have access to the policies. Only the AS
actually knows what the policies are. To me, that orthogonality is
essential to UMA and HEART. And it solves the problem of how much attention
we have to pay to HL7.

Debbie

I have difficulty understanding how your thinking aligns. HEART doesn’t
have to deal with policy. We don’t have it in our profiles. But there are
policies and consents that a patient defines that are part of consent,
whether it’s an AS, or a third party service, or an access control, that
will impact the calculus that result in the authorization to release a
token. We can’t ignore it. The resource server may need to have some
reference for consent. It’s not totally out of scope. We’re going to have
to deal with it.

Eve

There ultimately may be UX elements that we profile. There may be trust
elevation on the wire that has to do with the scopes we define. But policy
isn’t on the wire for UMA directly. I also want to talk about how long we
release things for. That would be a token expiration, not a scope.

Adrian

That’s not what I meant.

Eve

Okay. Good.

Debbie

Can we talk about date a little bit? There have to be date ranges
somewhere. Can the client ask for something within a certain date range?
Can that be within a FHIR query?

Eve

So you mean the client asks for information that was gathered within a
particular time frame? Should the main resource have scopes for every
single thing underneath or is it a query that you perform?

Adrian

FHIR has a powerful query mechanism, and that’s how most people use it.
They don’t think about resource sets.

Debbie

It’s possible to authorize minimal sets of data - just meds, just
allergies, just immuninizations. Somehow somewhere date needs to be
included.

Eve

What I meant was sharing for a particular stretch of time - different
meaning.

Debbie

But that could be an expiration on a token.

Eve

Right, I would call that a policy condition.

Debbie

As part of a token generation, could you include additional claims or
conditions as part of the token?

Eve

It’s independent of the requesting party. It’s part of a set of
entitlements that the requesting party gets.

Debbie

I’m more curious about what can actually be put into a token

Eve

What can be put into a token is resources and expiration. You have the
ability to say what API calls the client can make, and for how long it can
make them. Alice can go back and revoke any of that. If Alice sets policy
ahead of time, she can set permissions to expire - “automatic unshare.”

Debbie

So let’s say for school immunization, Alice sets a policy to release it to
her University. There could be a separate process that could validate that
it’s a valid university? That’s trust elevation?

Eve

Trust elevation is deciding who to give the token to. Once the token is
given, it’s implicit who the subject of the entitlement was because the
token resides with them. It’s a bearer token.

Debbie

So that’s an authorization process that happens before the token is
generated.

Eve

Right. There’s the question of who you give the token to, what’s in the
token, and when the token expires. We could say the interface that Alice is
presented with the option to go back and turn off sharing. UMA doesn’t make
you do that, it just makes it possible. Nobody makes the UX have that
option. So maybe say that she has the “active” ability to unshare - killing
the token or at least some of the scopes.

Debbie

Is authorization assessment process where trust elevation happens in the
spec?

Eve

Yes. It’s an internal thing the AS has to do given input. Trust elevation
generally is an interaction between the client and the AS and possibly the
requesting party. It’s all in section 3.5 and 3.6. There are two things the
client can do if the AS says I need more. Either it pushes information it
already has about Bob, or it redirects Bob himself to complete an
interactive flow.

Adrian

Somebody has to take an action item to explain to us whether the query
actions of FHIR are possible.

Debbie

I asked if I as Alice set up a policy to release immunization records to
the school so if the client requests it, how does the client verify that
they’re a school.

Oliver

That would be a separate system to provide that layer of trust.

Eve

Trust elevation is a generic term for claims gathering, but it could
include things like “smart contracts” in the future. When you form
authorization policies, it’s usually made of a subject, verb, and object.
The subject would be the requesting party, the verb would be the scopes,
and the object would be the resource. It’s important to profile all this to
make sure that we’re being interoperable and patient-centric.

Adrian

We have to address the fact that FHIR as an API standard is heavily reliant
on query parameters.

Sarah

A query is just another API call. The access management systems that we’re
profiling are protecting API endpoints. A query is just an API call like
any other.

Eve
I don’t think we’re going to solve this in four minutes, but we should put
it on our docket for the future.

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