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

[Josh Mandel]

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.

On Mon, Jul 13, 2015 at 6:27 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_Week-2Dof-2DMon-2D20150615_000195.html&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Sc0RjyxGMEW2h3Ch_BDIiMglbyS1FD5zdvsUrydu_yg&s=hLNNBysN3T-c_FzMyO08tEsb10Q4db178dcK01Xad3k&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mitreid-2Dconnect_OpenID-2DConnect-2DJava-2DSpring-2DServer_blob_master_docs_OAuth2.0-5FDiagrams.pdf&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Sc0RjyxGMEW2h3Ch_BDIiMglbyS1FD5zdvsUrydu_yg&s=z5xRnOyFoxlOnhYHKSNLL6urfY5xU0PBtOmsJbY_WGM&e=>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Sc0RjyxGMEW2h3Ch_BDIiMglbyS1FD5zdvsUrydu_yg&s=Hoj3IZHkppZLbSx9yI8lTodVKnwvXk56Jjh1e55e0Q0&e=>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Sc0RjyxGMEW2h3Ch_BDIiMglbyS1FD5zdvsUrydu_yg&s=RPao39LkH6dna0V0detsabQAO7PgGQeBzNX3eBrt_QQ&e=
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150716/64c3ead0/attachment.html>