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.