Attendees:

Sarah Squire

Debbie Bucci

Thompson Boyd

William Kinsley

Adrian Gropper

Justin Richer

Jeff Shultz

Ishmal Bartley

Glen Marshall

Edmund Jay

Josh Mandel

Jim Kragh

Registration Flows

Debbie has been trying to understand the difference between the authorization code flow, implicit flow, and client flow.

William wants to clarify that this use case was not intended to show client registration at all. The relationship between the PHR and EHR was intentionally existing and static in order to simplify the use case.

An authorization code represents an authorization grant, but they are not the same thing. In the implicit flow, the grant is being made but the client is inside the user agent, so it doesn’t go anywhere. In the client flow, the client authenticates, and that tells the authorization server that the client is authorized because it has been prearranged. There is no “Alice” in the client flow. The client itself is what is getting authorized. There is no “resource owner” involved. If Alice is sitting in front of a web browser, you wouldn’t be using a client flow. “Client credentials flow” is perhaps a more helpful label.

In this use case, the location of public keys, redirect uri, scopes, auth grants, and the client identifier need to be agreed upon regardless of whether the registration is manual or dynamic.

The authorization server has a list of registered clients. A resource server cannot advertise to a client that it has certain requirements using current specifications. There is no standard for advertising claims about clients or resource servers.

This use case does not require a registry or client claims.

Document Core Content and Peripheral Content

We went through the current version of the document and annotated some parts as core and some parts as peripheral. We made it from section 3a to 3f.

UMA vs OAuth

Should we be starting off with UMA? Or sticking to OAuth to begin with in order to simplify? OAuth is a large component of UMA, but UMA is a completely different protocol. You can’t configure systems to use both UMA and OAuth at the same time. UMA does not degrade gracefully into OAuth. UMA does not specify a good way for an OAuth server to talk to an UMA server.

In OAuth, anytime a client wants to talk to a resource server, it knows which authorization server to use. in the classic OAuth use case, you are talking to a specific API, so there’s a tight binding between the authorization server and the protected resource.

UMA is not required in order to have the EHR and PHR talk to each other without Alice present. That is possible with vanilla OAuth. What we need UMA for is authorization decisions that need to be made without Alice present.

This use case does not require UMA. It can be accomplished using only vanilla OAuth if we so choose.

EHR and patient portal are the same thing for the purposes of this use case.

Things to discuss later on the list

Do we need to specify parameters on persistence for identity credentials?

We might want to come up with some principles about whether we prefer to default to OAuth or UMA or both.