<div dir="ltr">Attending:<br><br>Debbie Bucci<br>Thomas Boyd<br>Glen Marshall<br>Sarah Squire<br>Abbie Barbir<br>Adrian Gropper<br>Justin Richer<br>Obi Ogbanufe<br>Tom Sullivan<br>Mark Scrimshire<br>Edmund Jay<br>Ishmal Bartley<br>Barbara Filkins<br>Josh Mandel<br><br>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.<br><br>Smart on FHIR scopes are here:<br><a href="http://docs.smarthealthit.org/authorization/scopes-and-launch-context/">http://docs.smarthealthit.org/authorization/scopes-and-launch-context/</a><br><br>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.<br><br>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.<br><br>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.<br><br>We would like to avoid forking away from SMART on FHIR, so we will look at their scopes first.<br><br>SMART on FHIR defines three dimensions:<br><br><ul><li>What am I allowed to access? (example: appointments)<br></li><li>Whom does it represent? (example: Alice)<br></li><li>How much am I allowed to do there? (example: read write)<br></li></ul><br><br>OAuth today does not have an “audience” parameter, but we might go through changing that if we have to.<br><br>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.<br><br>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.<br><br>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.<br><br>Justin would like an audience parameter as well as a scope parameter that could be used within OAuth and UMA.<br><br>Most deployments of OAuth are overloading the scope field such that it defines both the “what” (“audience”) as well as “how much” (traditional scopes).<br><br>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.<br><br>We discussed Josh’s email last month on scopes. <a href="http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20150615/000195.html">http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20150615/000195.html</a><div><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>This is a flow diagram for OAuth:<br><a href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/docs/OAuth2.0_Diagrams.pdf</a><br><br>So in OAuth, the client sends the scopes that it wants. In UMA, the RS sends the scopes that it thinks the client wants.<br><br>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.<div><font color="#000000" face="Arial"><span style="font-size:14.6666669845581px;white-space:pre-wrap"><br clear="all"></span></font><div><div class="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136)">Sarah Squire</div><div style="color:rgb(136,136,136)">Engage Identity</div><div style="color:rgb(136,136,136)"><a href="http://engageidentity.com/" style="color:rgb(17,85,204)" target="_blank">http://engageidentity.com</a></div></div></div></div>
</div></div></div>