[Openid-specs-heart] Draft HEART meeting notes 2015-06-29

[Sarah Squire]

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.


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