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.

Josh added: As promised: this is the version of the SMART on FHIR specification that includes the most recent changes in response to review from the Argonaut participants: http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/

Beyond a set of editorial changes, the most relevant updates are:

1. Addition of "aud" as a parameter on the authorization request. This is a security fix that mitigates against a malicious resource server (in the absence of a whitelisting protocol by which public client apps decide which resource servers to trust).

2. Moved "launch:" out of the scopes list and into a separate parameter of the authorization request (this cleans up the semantics of our scopes list a bit, and sounds similar to what we were calling an "audience" on today's phone call).

3. Added a scope called "online_access" (by analogy to the OIDC "offline_access" scope). This scope is used to request a refresh token that lasts until a user signs out of the EHR.

Debbie added: Thanks so much for this Josh. Justin will be in Prague next week so I would like to postpone the broader scope/approach discussion until he returns and Eve is available as well. I have no answers - just questions and lots of them!

Instead I would like to use that time as an opportunity to pull the focus back to the PHR as source of truth and do as we originally intended - focus on the use case.

Gajun Sunthara has been building an open source FHIR based PHR from scratch as a way to understand the underlying standards and protocols. It's been amazing to see the concepts develop over time as he's socialized his efforts.

He has implemented OpenID Connect and has connected to a number FHIR resources and created a local store of his own. Additionally he has a running list of endpoints that seem to align with what I think a personal UMA authorization may look like (at least to a consumer). So many ways to extend those concepts.

The authorization service - or source of truth will need to be flexible and meet the consumers need across a number of different RS clients and APIs and standards. Gaj's UI makes me believe its possible to do.

if there is time after the demo, I'd like to use to focus on JUST the scopes that a PHR would need to communicate and enable read/write between PHR and PCP as both client and RS.

Adrian added:

I would suggest that we need to try and reach a consensus on one or more use cases to drive HEART before we dive into scopes and the details of profiles. Here are a few specific comparisons between the Argonaut use-cases as provided by Josh and the HEART WG Charter.

in the SMART on FHIR Authorization Guide:

-

Use Case 1: Patient uses a provider-approved web application to access health data -

Use Case 2: Patient uses provider-approved mobile app to access health data -

Use Case 3: Clinician uses provider-approved web application to access health data -

Use Case 4: Clinician uses provider-approved mobile app to access health data

These use-cases are irrelevant to HEART because they do not support symmetrical interface between two Resource Servers in separate security domains.

The relevant Argonaut use-case:

-

Use Case 5 (future: Provider using EHR A access patient record held in EHR B

is explicitly out of scope for Argonaut and a requirement for HEART.

in the SMART on FHIR Registering a SMART App with an EHR:

“...the app must be registered with that EHR's authorization service.”

The HEART charter http://openid.net/wg/heart/charter/ section 5) requires:

-

Support independent authorization services and identity providers, to be chosen by people who may build, run, or outsource these services.

The HEART charter section 5 also includes the following:

-

Leverage lessons learned from the Blue Button+, RHEx and other initiatives and their profiles to the extent possible, and leverage FHIR as a key exemplar of a health data API, recognizing that additional features may be required.

Experience with CONNECT, Blue Button Plus, and Direct has shown that any institutionally-driven interoperability approach will fragment into islands of trust dictated by the business interests of the implementing resource servers. As with mail, phones, fax, and email, only processes that allow individual people as accountable first-class citizens can create a universal address space for interoperability.

The HEART charter section 5 also includes the following:

-

Generative (able to be combined and extended to support a variety of use cases in other application domains and emerging application functionality).

In order to accommodate and scale to include claims payment, implants, wearable devices, home monitors, cross-sectoral ID providers, and non-HL7 data models, the HEART profiles should not be driven by any single industry’s resource definitions. Argonaut, and the EHR community that controls FHIR is a relatively narrow slice of the human health management ecosystem.

I would suggest that we need to try and reach a consensus on one or more use cases to drive HEART before we dive into scopes and the details of profiles.