Attendees:

Debbie Bucci

Danny van Leeuwen

Sarah Squire

Corey Spears

Dale Moberg

Glen Marshall

Justin Richer

William Kinsley

Adrian Gropper

Thomas Sullivan

Thompson Boyd

Jim Kragh

Kathleen Connor

OAuth Security Profile

Debbie:

Does anyone have concerns about this profile? Bill?

Bill:

No, I’ve expressed my comments to the list

Dale:

Will there be other profiles of OAuth relevant to FHIR?

Justin:

There will be other profiles related to UMA and FHIR, but not OAuth. That one will be more complex. UMA moves us into the wide ecosystem world.

Debbie:

Originally we said the registration was OAuth only, but there are parts of it that could be OIDC. Do we still think this original use case is OAuth only?

Justin:

Yes, any of the OAuth use cases, with slightly different technology, could be deployed as an OIDC or UMA use case. We may “rebrand” another version of this use case for UMA to see how it shakes out.

Debbie:

I’d like to do that so we can see the differences and how they’re related. Adrian’s use case is complicated.

Adrian:

Every encounter starts with the insurance. Taking the delegation use case first not only is the simplest one, because it leaves out all of the OIDC identity stuff and it includes enough OAuth to be critical to what we’re trying to do.

Bill:

I think there’s value in having the OIDC component in there so we can contrast how users are authenticated and proofed. That’s an area we’ve spoken the least about. I think there’s value having it in the diagram.

Adrian:

The UMA use case is easier to profile that the OAuth use case because OAuth has so much optionality.

Justin:

Have you read the OAuth profile that removes the optionality you’re talking about?

Debbie:

I’d like to see the differences between an UMA flow and and OAuth flow.

Adrian:

We don’t design email, for example, on the assumption that everyone will use google or facebook for their email service even though most people don’t. Email is designed in a particular way because people should be able to control their own email server. The same thing applies to authorization servers. It’s not helpful to say there will only be three trusted authorization servers.

Justin:

No one is saying that there will be three authorization servers. When you get hired at a company, you have to have an email there. You can’t bring your own. More importantly, the actual data is able to flow regardless of where the authorization server lives. You’re drawing a false equivalence between ownership of the authorization server and portability of the data.

Debbie:

Would registration touch OIDC? Or is that some typical flow?

Justin:

It ought to. Alice should be able to use an OpenID account, but we tagged that as peripheral. All we are REQUIRING is that Alice has an account. We would like it to be an OpenID account, but it doesn’t have to be.

Dale:

Do we have a use case where the resource server’s authorization server doesn’t check the credentials.

Justin:

What would be the value in that?

Dale:

It’s a potential for the HIE use case. The clients know about their identity. It would be something like a bulk data transfer, sometimes per individual. It’s a “regional aggregate” of providers, payers, and others.

Justin:

That’s precisely what the bulk data transfer is for inside the OAuth profile. We call it a “direct access client.” There’s nothing to stop them from getting identity information. You have trust the client very explicitly. We would prefer the user be there and authenticate because a direct access client could lie, but we still allow direct access clients. We don’t have a use case that goes over that scenario.

Dale:

I might draw one up for the group.

Justin:

There’s been some discussion on the list of NPE to NPE sharing, and a use case would be helpful for the group to understand and get the pieces in the profile to build that fully.

Bill:

So you’re saying the client would be of a type that would be like a trusted server that could represent multiple users and you would have the clientID being the trusted one with a certain role and the userid would be managed independently?

Justin:

Yes. The client is “acting on its own behalf”. The clientid is the trusted entity.

Debbie:

The details of registration in the registration use case are peripheral.

Justin:

There’s server discovery and client registration on both sides.

Debbie:

Which OAuth flow are we using here?

Justin:

This is the normal authorization code flow. Both of these would be patient/* because we want everything about Alice.

Debbie:

So in this profile, for the scopes, is the permission type patient?

Justin:

In this use case, yes. Access type is star.

Debbie:

Is it worth it to put these pieces into the flow? I think so. Any questions about this? Should we move on to Adrian’s diagram?

Debbie:

I don’t get what number 7 is. What’s the approved linkage to payer?

Adrian:

That’s how the information on the clipboard gets there. You have to have a way of linking in your information.

Debbie:

Is number 8 verifying Alice’s eligibility?

Adrian:

Yes. The encounter starts with the introduction of the insurance account. That’s what avoids patient matching and all sorts of issues. Alice is able to introduce her payer by introducing her authorization server.

Debbie:

This assumes her insurance company trusts her authorization server?

Adrian:

Yes, everyone is going to trust the same authorization server.

Debbie:

Our use case is we think something that can be implemented in the near term. Does this require the insurance company to trust Alice’s authorization server?

Adrian:

It requires them to trust an authorization server specified by Alice. The use case starts out with Alice already having an account at the payer. How that came about is before the use case started. She goes to the PCP and the fun begins.

Debbie:

So you’re saying that Alice has access to an insurance portal?

Adrian:

Yes

Debbie:

So 6,7, and 8 is with the primary care. Why is it going to the custodian?

Adrian:

The point of the use case is that Alice is an elderly mom or minor child, and the delegate is someone who uses technology. Alice shows up in person and gives the email of her custodian. Based on that email, everything else in the use case flows accordingly.

Debbie:

So the smartphone is kind of like the PHR?

Adrian:

No, not at all. The smartphone is the custodian’s web browser. It’s just a dumb client. It’s just the resource owner. How does Alice sign into the patient portal? I’m just doing the meaningful use stage 3 API use case. When you do that, you specify something that’s subject to discovery. In order to match Alice’s identity in the provider and the payer, the custodian has to do the OAuth dance to both sides using the smartphone. If the arrows are wrong, we can talk about them and fix them.

Bill:

When do the profiles go to a vote?

Debbie:

They are out for review now. There will be a vote in January sometime. The actual date was sent to the list by Mike Jones.

Adrian:

Is the group particularly interested in the API component of what’s going on here, or is that incidental?

Glen:

I’d like to see user experience brought into it, but it’s not necessary.

Debbie: I’m going to try to do one through eleven. If I get it done before next week, I’ll send it to the list.