[Openid-specs-heart] Draft HEART meeting notes 2015-07-13

Sarah Squire sarah at engageidentity.com
Mon Jul 13 22:27:31 UTC 2015


Attending:

Debbie Bucci
Thomas Boyd
Glen Marshall
Sarah Squire
Abbie Barbir
Adrian Gropper
Justin Richer
Obi Ogbanufe
Tom Sullivan
Mark Scrimshire
Edmund Jay
Ishmal Bartley
Barbara Filkins
Josh Mandel

How should we discuss scopes? We could start with the argonaut scopes and
start on some design discussions that we need to get into as a group.

Smart on FHIR scopes are here:
http://docs.smarthealthit.org/authorization/scopes-and-launch-context/

How are we assuming that we are structuring resources and structuring
access to resources? OAuth has an implicit assumption that you know what
protected resource you are trying to talk to. OpenID Connect (OIDC) is
always about one user, the current user. However, FHIR could be serving
documents for multiple users. You might have a user who is authorizing
access to multiple records at the same time. When you have a single
representative and a single endpoint (like OIDC does) you only ever have to
deal with one user’s information. Each user can have one information
endpoint.

HEART has to deal with the current user plus other users, like the current
user’s kids. We have to have clarity in our vocabulary when we talk about a
user as opposed to a resource owner.

On the UMA side, the API is designed so that each URL serves a specific
resource for a specific resource owner. Those URLs can serve multiple
users. The only way the client can get information is by asking for
specific URLs, possibly from multiple authorization servers. There is not a
single “root” URL.

We would like to avoid forking away from SMART on FHIR, so we will look at
their scopes first.

SMART on FHIR defines three dimensions:


   - What am I allowed to access? (example: appointments)
   - Whom does it represent? (example: Alice)
   - How much am I allowed to do there? (example: read write)



OAuth today does not have an “audience” parameter, but we might go through
changing that if we have to.

One question we will need to address is whether Alice has to go through a
separate screen to authorize each resource, or whether she can do many of
them at once.

One of the issues we are addressing is that OAuth has all information about
a user in one envelope whereas UMA has the potential for heterogeneous
resources in different locations with different authorization policies
about different patients.

We could decide that the record identifier is in the URL. That would open
up the scopes so that we wouldn’t have to represent the “who” dimension
inside the scope.

Justin would like an audience parameter as well as a scope parameter that
could be used within OAuth and UMA.

Most deployments of OAuth are overloading the scope field such that it
defines both the “what” (“audience”) as well as “how much” (traditional
scopes).

SMART is using the “launch” scope to provide the context. An authorization
can be with respect to a patient or a population of patients. Confusingly,
they use the parameter “audience” completely differently, in a context of
presenting the right tokens to the right servers to prevent counterfeit
authorization tokens.

We discussed Josh’s email last month on scopes.
http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20150615/000195.html

You can break down any API into resource set and scope pairs and you want
to find something that fits nicely with the API itself.

The SMART scopes have basic operations (read, write, etc) and when you
combine them, you end up with a matrix of different operations on one
resource. Without explicitly identifying the resources, you could still
include that as part of the scope. The problem then is that you have a
three-dimensional space represented by a single string. You could have a
structured semantic to parse them and include them in the scopes. SMART
clients ask for special kinds of scopes, but they don’t have to be parsed
and understood because the strings are in a limited vocabulary that can be
mapped to specific access limits.

Doesn’t UMA allow for a more nuanced negotiation between the client and the
authorization server? No, an UMA authorization server has to follow Alice’s
policy, and an UMA client takes what it gets; it cannot negotiate for
different scopes.

Isn’t there negotiation between the resource server and the authorization
server in UMA? The resource server dictates the available set of scopes.
The authorization server cannot communicate what it wants, but it can
decide to authorize a subset of these scopes depending on which claims the
client presents.

This is a flow diagram for OAuth:
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf

So in OAuth, the client sends the scopes that it wants. In UMA, the RS
sends the scopes that it thinks the client wants.

Josh will send links to the current SMART on FHIR documents that include
things like moving the “launch” parameter to its own scope as well as
formalizing the “audience” parameter, similar to the one Justin discussed
above.

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


More information about the Openid-specs-heart mailing list