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

[Eve Maler]

Thank you for the amazing notes! Just one small tweak below...


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Mon, Jun 15, 2015 at 2:07 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> 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.
>

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.
>
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150615/0ecb348d/attachment-0001.html>