Wiki

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.

(addition by Eve) This is a true statement, I think, but my point in mentioning Flickr was that when we designed UMA's two-layer approach, we referenced Flickr's approach of having a variety of OAuth scopes that applied differentially to a variety of resource sets, such as photos and photo albums. Such resource sets are entirely implicit from an OAuth perspective, but make a difference in terms of what scopes can be used with what endpoints. (They seem to have simplified things since, to be more of a full matrix with read/write/delete scopes.)

Salesforce (https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_scopes.htm&language=en_US) is another example. E.g., the "chatter_api" scope only applies to Chatter REST API resources.

UMA just makes the resource set(s) named and explicit so that they can be registered by an RS at an AS that might be operated by a separate organization.

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.