[Openid-specs-heart] Draft HEART Meeting Notes 2015-12-7

[Sarah Squire]

Attendees:

Debbie Bucci

Glen Marshall

Michael Magrath

Sarah Squire

John Moehrke

Eve Maler

Justin Richer

Dale Moberg

Aaron Seib

Adrian Gropper

Tom Sullivan

Thompson Boyd

Hope Morgan

Edmund Jay

Jin Wen

John Bradley

Brandon Smith

Jim Kragh

Mark Russell


Profile Drafts

Justin:

Today is the end of the two week working group review period. We published
new profiles today. Nothing has been normatively changed. In the OAuth
profile, we are more specific about scopes. We call out that authorization
servers can use arbitrary scopes at run time. Similar changes were made to
the UMA and OIDC profiles. As it stands, they are ready for publication.

Debbie:

What’s the next step now?

John:

Once the work group has approved them, we talk to Mike and get notices sent
out that the review process is underway.

Action item: The chairs will notify Mike and supply the URLs of the
documents.

Action item: Justin will publish the current drafts at a different URL so
that they can be the canonical implementer’s drafts.

John:

It might be good to vote on these at the same time board elections are
happening so they have more visibility. There’s a “notice of the vote” that
you can do concurrent with the public review process. That would save us a
couple of weeks.

Action item: Debbie will get notice of the review period and the vote onto
the website.

Debbie:

Bill, you started a conversation about scopes.

Bill:

Referencing section 2.1 of the FHIR OAuth profile, I think this whole
section should be struck because it goes against the basic philosophy of
OAuth and UMA. We’re defining roles of users here. It’s not clear who we’re
talking about here. I think it’s problematic.

Justin:

We are not defining classes of users. This is two different kinds of
access. In the first one, you’re asking to access a single record. In the
second one, you’re asking for everything in a certain category. Naming them
“patient” and “user” may be confusing. We took that from the SMART on FHIR
system so that we would be compatible.

Bill:

Most systems don’t have a concept of single vs. every records.

Justin:

It’s not every record in the system. It’s every record the requester has
permission to access.

Bill:

Then what’s the difference between the two? It’s misleading and it goes
against the general philosophy.

Adrian:

These profiles are supposed to facilitate security. Mixing multiple
resources with single patient resources is bad practice. Let’s deal with
them separately.

Sarah:

Just to be clear, this is not a philosophical part of the profile. It’s
just a way for a machine to tell another machine whether it wants one
record or multiple records.

Adrian:

Let’s park the bulk transfer for later. Let’s deal with single patient
resources and deal with bulk transfer later. How do we map the patient
right of access to multiple subjects? If you have multiple kids in a
family, do they all have to use the same authorization server?

Justin:

Yes, and it all fits in HEART as written, so what’s the problem?

Adrian:

The security practices for those two resources are very different.

Justin:

One of these says that I just want one record. One of these just says that
I want to be able to push one button and have all my stuff. “Get all my
family’s records” or “get all my patient’s records”

Adrian:

This is where we are overloading the resource owner definition. In what you
just said, the resources do not necessarily pertain to a specific person.
You’re conflating two different kinds of delegation. One has a single
subject and one has multiple subjects.

Justin:

I am talking about OAuth delegation. I’m talking about delegating my
authority to a computer. We aren’t talking about delegation between people.

Adrian:

Okay, then I would say that we don’t have a use case to talk about to
settle this argument.

Justin:

No, we don’t have a use case for it because it has already been solved.

Eve:

Is delegation defined in OAuth?

Justin:

No, but it helps to explain what’s going on.

Eve:

So when you say user delegation, you’re talking about three legged
delegation.

Justin:

Yes

Eve:

I will take this offline and suggest some new language for Section 2 of the
UMA profile having to do with delegation.

Justin:

All we’re saying in section 2.1 of the FHIR OAuth profile is that we need a
way to differentiate between whether we’re getting one thing or multiple
things. We can change what we call it, but we should coordinate with SMART
on FHIR

Aaron:

For some patients, a user may consist of one patient, in which case both
scopes are identical. The way that I’ve seen consumer applications being
used, I haven’t seen patients accessing more than one record at the same
time.

Justin:

HReader is an ipad app that was specifically about collecting multiple
records and having your entire family records in a single dashboard app on
your ipad.

Aaron:

What is the technical benefit of having a “user” scope?

Justin:

You only make one call to the API to get everything, and you can simplify
the user experience. You can ask the user whether they want one thing or
all the things. It’s likely that a patient would use the “patient” scope
more often. A doctor would probably use the “user” scope more often.

Adrian:

There are two dramatically different cases. In the case where the user is
the physician, the resource can no longer be associated with the mom or the
kids.

Justin:

This is the OAuth profile. You’re talking about the UMA profile.

Aaron:

When I think about a user, I think about a social worker who has 15 foster
children. I can think about “user” if I put it in that context.

Justin:

In this profile, the relationship between the resource server and the
authorization server has already been set up. In UMA, there is an
assumption that each URL is only protected by a single authorization
server. Which is one of many reasons why we’re starting with OAuth.

Adrian:

The issue is that UMA might be right. The adoptability of HEART might be
better if you don’t mix the two resources together.

Bill:

So, Justin, you’ve agreed that the terms “patient” and “user” are poor
choices. Before we put this out for vote-

Justin:

Stop! This specification is not going out for vote. The OAuth FHIR
specification is NOT going out for vote.

Bill:

There is no real defined difference because both types can access more than
one record. There are more than one types that would exist in a system.
It’s not clear how a proxy process would get tied to this. Also, a nurse
can be a user and a patient.

Justin:

The names are arbitrary, and they could be different. We could switch to
“single” and “multiple”. There is a difference between them. You can’t get
multiple records from the single scope. Users can have different roles,
which is why need to do this. We need to differentiate between how users
access records.

Adrian:

Discovery is important in what we’re doing. If you mix the discovery use
case with the single patient use case, the user experience component is
going to be a disaster. Resources that are related to discovery will have
to inherit resources.

Justin:

No one is talking about discovery.

Debbie:

So when we talk about the sequence diagram, I’m assuming this use case is
going to touch on many profiles. So, I’m confused. If we change our scopes
do we have to worry about mapping between us and FHIR?

Aaron:

I think “single” and “multi” would be clarifying.

Justin:

Someone please start a new thread to discuss better names for these.

Bill:

It’s the business rules of the resource server to determine permissions.
Scopes for access should be based on the client they are using.

Justin:

It’s ultimately always the resource server that determines what gets
returned. However, it’s the OAuth token that carries “things you can
access” across the wire. So that when the resource server sees it, it can
tell what you’re trying to read.

Debbie:

We need to wrap this now, so I guess we pick this up next week. I had hoped
to expand the sequence diagram.

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