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

[Sarah Squire]

Lots of people on the call today, and lots of discussion. More discussion
than would fit in an hour, so we agreed to take the rest of the discussion
to the list. Here are the notes on what did get discussed. Feel free to
make additions if I missed anything.

Sarah

Attendees:

Debbie Bucci

Glen Marshall

Sarah Squire

Jim Kragh

Josh Mandel

Justin Richer

Mark Russell

Thompson Boyd

William Kinsley

Adrian Gropper

Edmund Jay

Aaron Seib

John Bradley

Judy Keator

Eve Maler

Thomas Hardjono

John Moehrke

Salvatore D’Agostino

Jin Wen


There has been a conversation going on about what to do with the semantic
layers for this group. We have published initial security profiles. We need
to talk about mapping FHIR resources to OAuth scopes. There are OAuth
scopes that you can use to define actions - read, write, delete, update,
etc. Scopes could be tied to FHIR resources. For example, you could give
someone read access to your medications, and write access to your
children’s allergies.

We could talk about protecting resources on the web, or we could talk about
OAuth scopes as “what the client wants.” Are scopes a bucket of things that
the client wants from the AS?

FHIR gives a richer matrix of possibilities than OAuth scopes. We could
have the UMA and OAuth semantic layers be copacetic, or we could have them
be entirely separate. Interoperability of scopes is an opportunity.

There is interest within HL7 to bring the SMART OAuth work in and endorse
it as an example of how to do OAuth with restful APIs. However, each group
is looking at different parts of the elephant. We will have to ramp up more
complex scopes as we get more complex use cases.

Adrian would like to know whether we can separate health-care specific
things like scopes from identity-related things like authentication and
authorization. We can. That’s why we have separated the semantic layer from
the security layer.

Each API publisher gets to define their own scope, until they have to make
it interoperable. We can now talk about scope maturity as a design effort.
For example, HAPI (http://jamesagnew.github.io/hapi-fhir/) is an
alternative scope design for FHIR with a mature, resource-oriented design.
HAPI includes JAVA libraries for making a HAPI server and perhaps a set of
scope definitions. Restful HAPI APIs could be protected with OAuth, but
they haven’t done scope design. They are not concentrating on authorization
or authentication. HAPI APIs contain hooks for anyone to add their own
security layer. HAPI is a JAVA implementation of the FHIR Rest API.

We might be able to map UMA resource sets to FHIR. In UMA, a resource set
should be treated as private, but scopes are designed to be exposed. A
resource set might be lab results, a scope might be “download,” and a claim
might be “we won’t use this for marketing after we download it.”

We could choose a design that had multiple endpoints for different
resources, one big endpoint for all resources, or a more complex design
that had sub- and super- resources.

Flickr, for example, has photo as a sub-resource of a photo album
super-resource.

HEART might need to have scopes that only apply to certain kinds of
resources like running an analysis on a dataset.

There have been a couple of attempts to map OAuth scopes to UMA. One has
defined resource scopes and access scopes and combine them. One has defined
scopes that are semantically weighted where the scopes (like in
greenbutton) are a fully-formed query language.

Since UMA allows people to set their own parameters for multiple people,
the user experience of scopes is very important. Even if we have a very
expressive means of carrying things across the wire, they won’t be used if
they don’t make sense to users. Alice probably won’t want to go in a tweak
fine-grained access on a regular basis.

There is a problem that a client won’t know what to ask for if the AS
doesn’t make all the available resource sets and scopes discoverable.
Resource servers can make their resources discoverable through the AS
before any request for access is made.

Could non-UMA clients interoperate with UMA endpoints? There is some
disagreement over whether OAuth clients need to be explicitly supported.


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