FHIR Chat · SMART scopes v2 · smart

Stream: smart

Topic: SMART scopes v2

Isaac Vetter (Jun 11 2019 at 00:30):

During FHIR DevDays in Redmond, we talked through some of the features we need from SMART scopes that our current syntax doesn't satisfy. (Also see related conversation).

Isaac Vetter (Jun 11 2019 at 00:30):

Next steps:

Isaac Vetter (Jun 11 2019 at 00:30):

1) As a research step, collect and share the different production, SMART authorization servers' user-facing description of scopes. How are production AS's describing SMART scopes to users now?

Isaac Vetter (Jun 11 2019 at 00:30):

2) Simply adding in resource categorys to our existing SMART syntax may quickly and simply alleviate a lot of the pain. Why not simply toss the resource category's name into the scope. e.g.

Isaac Vetter (Jun 11 2019 at 00:30):

* patient/Observation:lab.read

Isaac Vetter (Jun 11 2019 at 00:30):

* patient/Observation:activity.read

Isaac Vetter (Jun 11 2019 at 00:30):

* patient/Condition:encounter-diagnosis.read

Isaac Vetter (Jun 11 2019 at 00:30):

3) Somewhat related, @Grahame Grieve mentioned specifying a method for an OperationOutcome to specify the scope that would be required to resolve an access denied error to enable a progressive authorization approach. (a la enabling a HATEOAS approach).

Isaac Vetter (Jun 11 2019 at 00:31):

4) While SMART already describes a method for authorizing non-FHIR scopes by prefixing the scope with __ (two underscores), it doesn't explicitly describe how to describe access to FHIR operations.

Pascal Pfiffner (Jun 11 2019 at 17:30):

5) Is there something we want to do with confidentiality classification (http://build.fhir.org/v3/ConfidentialityClassification/vs.html)? E.g. set a baseline confidentiality across resources ("normal"?), and if an app wants to access higher levels (e.g. "restricted" or "very restricted") there is an additional scope that needs to be requested? It would apply across resources IMO.

Grahame Grieve (Jun 14 2019 at 21:18):

http://www.healthintersections.com.au/?p=2967

Grahame Grieve (Jun 17 2019 at 06:02):

this feels like a low impact addition to an operation outcome to me:

{
  "resourceType": "OperationOutcome",
  "id": "break-the-glass",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">This operation not authorized by the user. Approve 'Updated Medications' during the Login process to OK this operation</div>"
  },
  "issue": [
    {
      "severity": "error",
      "code": "forbidden",
      "extension" : [{
        "url" : "http://hl7.org/fhir/StructureDefinition/operationoutcome-required-scope",
        "valueCode" : "MedicationAdministration/write"
      }]
      "details": {
        "text": "The user did not authorise this operation"
      }
    }
  ]
}

Grahame Grieve (Jun 17 2019 at 06:05):

I have added an extension http://hl7.org/fhir/StructureDefinition/operationoutcome-required-scope (which we would define formally in R5). The presence of this extension would indicate that the operation would be successful if the user approved the stated scope. The client application might want to initiate an OAuth sequence to ask the user to approve that scope (or ask the user if they want to).

The extension should only be used when the server has no other reason to deny this kind of operation, such that the user might reasonably expect it to succeed if they authorised the scope (though it may still fail for business rule reasons etc)

Grahame Grieve (Jun 17 2019 at 06:06):

an alternative approach is to define the extension as http://hl7.org/fhir/smart-app-launch/StructureDefinition/required-scope - e.g. get smart to define it rather than putting it in R5

Jim Steel (Jun 17 2019 at 06:23):

"would be successful" might be too strong. Presumably the operation could potentially fail for other reasons, given sufficient authorisation

Grahame Grieve (Jun 17 2019 at 06:34):

yes I guess. But you wouldn't send this back if the user didn't have the authority to run the operation even if the scope was authorised

John Moehrke (Jun 17 2019 at 12:28):

that last statement is important. So you know that the app has overall the authority, just not with the scope it asked for. Not clear how you know that, but by making sure this is true you will not be exposing (leaking) security policy.

Isaac Vetter (Jun 18 2019 at 19:20):

So you know that the app has overall the authority, just not with the scope it asked for

There's only a few definitions of an app's authority, and they're all lists of OAuth2 scopes:

Isaac Vetter (Jun 18 2019 at 19:20):

1) the scopes the app specified during registration.
2) the scopes the app asked for during authorization.
3) the scopes granted by the user/authorization server.

Isaac Vetter (Jun 18 2019 at 19:20):

In the above OperationOutcome example did the app register for user/MedicationAdministration.write, but either did not ask for it during authorization or it was denied by the user/AS ?

Isaac Vetter (Jun 18 2019 at 19:20):

In other words, should a FHIR server only return this break-the-glass OO when an app attempts to perform an unauthorized operation for which it has a registered scope?

Grahame Grieve (Jun 18 2019 at 19:34):

hmm I think I meant that the user has the authority, just haven't offered that to the app.

Grahame Grieve (Jun 18 2019 at 19:34):

I think it would imply that the app is registered for that, but that either it didn't ask, or the user didn't approve.

Grahame Grieve (Jun 18 2019 at 19:35):

@Jenni Syed specifically suggested this, so that apps don't have to ask for eveything from the user up front

Jenni Syed (Jun 18 2019 at 19:45):

Correct, this was not for break the glass. The workflow for break the glass would have to be more complicated/we would need to work that out specifically

Jenni Syed (Jun 18 2019 at 19:46):

It implies that the server stops enforcing some of the user's privs

Jenni Syed (Jun 18 2019 at 19:47):

And typically, that massively stepped up auditing and security logs happen

Jenni Syed (Jun 18 2019 at 19:47):

break the glass is likely its own scope(s) separate from the existing scopes

Jenni Syed (Jun 18 2019 at 19:49):

This was to get closer to 1) giving apps better errors when they either can't check scopes actually granted or don't check them and then try to access something they "assume" they have access to

Jenni Syed (Jun 18 2019 at 19:50):

and 2) allow apps to do auth flows closer to what iOS and android do: which is ask for scopes as functionality is used within an app/slowly expand auth to only what is needed

Brian Postlethwaite (Jun 19 2019 at 00:40):

Do you think that if the break-glass scope is used the authentication should be re-challenged?
Such as when you access confidential parts of your user profile?

Josh Mandel (Jun 19 2019 at 03:49):

Has anyone seen a good UX on for progressive permissions in OAuth? (My impression has been that progressive permissions work well on mobile platforms because the whole interaction happens in a single pop-up with one tap -- approve or deny a single incremental request, like "access contacts?". I'd be interested in how this translates to OAuth, with a browser redirect, potentially a login, a decision, and a redirect back)

Grahame Grieve (Jun 19 2019 at 04:07):

should not need a login, if it's still valid? Maybe we want a launch parameter to indicate incremental authorizing? Maybe I'll prototype it?

Jenni Syed (Jun 19 2019 at 14:04):

@Brian Postlethwaite we did some really really high level discussions around what break the glass might look like over a year ago, and we did expect that it would go back through auth. We didn't discuss if it would require them to re-auth, but it's possible a system needs to capture additional info when that happens (like a reason).

Jenni Syed (Jun 19 2019 at 14:05):

It was just a random side discussion with @Michael Donnelly and I and a few others though

John Moehrke (Jun 19 2019 at 15:42):

@Jenni Syed I would love to hear about this... We do have a break-glass mechanism in the FHIR Spec today, as inserted by Grahame long time ago. Im not all that happy with this, but haven't been involved in any alternative -- http://build.fhir.org/security-labels.html#break-the-glass
YES, break-glass typically (in older systems) does require at least a "are you sure" prompt to the user, with usually a text box asking for "why?".

John Moehrke (Jun 19 2019 at 15:44):

is this OperationOutcome extension intended only for break-glass type workflows? I understood it was also for workflows such as point-of-care-consent capture.

Jenni Syed (Jun 19 2019 at 16:21):

No, the operation outcome isn't intended at all for break the glass right now

Grahame Grieve (Jun 19 2019 at 22:05):

I don't think we closed the break-the-glass discussion. For me, an important part is automatically switching out of break-the-glass mode (since users won't bother...). So I don't think of it as a new session - just a special function within the app. But an external app... is there any use case for an external app to have break-the-glass?

Joel Schneider (Jun 26 2019 at 17:05):

This may be a niche use case, but a constrained /Patient.write scope, limited to adding or modifying a specific Patient.identifier, could be useful. A specialized Patient operation for this purpose might also make sense. May be worth discussing further if there's wider interest in this type of thing.

Michael Donnelly (Sep 17 2019 at 14:07):

What's the next step for this?

Josh Mandel (Sep 17 2019 at 14:16):

HL7-wise, I think this fits under our existing project scope.

Josh Mandel (Sep 17 2019 at 14:18):

So we could get a proposal on the table for an updated IG.

Josh Mandel (Sep 17 2019 at 14:18):

@Michael Donnelly re: scopes in particular, currently Epic doesn't use SMART scopes over the wire (e.g., ignores scopes requested by a client, and always enforces Epic-specified permissions that the developer requested at app registration time). Is this something that would be likely to change if we created "scopes v2"?

Michael Donnelly (Sep 17 2019 at 18:32):

At this point, we plan to continue supporting scopes per client rather than per token. We would be likely to enhance what we have now to return more granular SMART scopes (in the JSON response to the /token endpoint) when they become available.

Michael Donnelly (Sep 17 2019 at 18:34):

If UDAP trusted dynamic client registration comes to fruition, we'd need more granular scopes to assign the proper rights to dynamically created clients.

Michael Donnelly (Sep 17 2019 at 18:36):

(E.g. we great access discretely to Observation (Lab Results) and Observations (Vitals) rather than broadly to Observations.)

Josh Mandel (Sep 17 2019 at 18:38):

we plan to continue supporting scopes per client rather than per token.

But even per-client today, SMART scopes aren't used directly in Epic's registration process (i.e., SMART scopes don't show up by name in the app registration process, and the options that do appear are at slightly different granularity -- like search-as-distinct-from-read). This doesn't strike me as a huge problem, but it does make me wonder about the value of standardizing scopes, in a world where they're not actually being used.

Josh Mandel (Sep 17 2019 at 18:40):

All that said, I definitely want to work on improved scopes; I'm just trying to get a handle on whether they'll be used directly vs serving as "hints".

Grahame Grieve (Sep 17 2019 at 18:40):

others are using them.

Josh Mandel (Sep 17 2019 at 18:41):

(In UDAP trusted dyn-reg, Epic could still ignore on-the-wire scopes and simply pin the newly-registered app's permissions to the set of permissions provided during the up-front registration step.)

Josh Mandel (Sep 17 2019 at 18:41):

Yes, I agree others are using them; I'm just trying to understand the interest expressed here from the Epic team, since Michael and Isaac brought this up :)

Michael Donnelly (Sep 17 2019 at 18:52):

(In UDAP trusted dyn-reg, Epic could still ignore on-the-wire scopes and simply pin the newly-registered app's permissions to the set of permissions provided during the up-front registration step.)

In the use case we discussed on Sunday, there'd be no pre-existing parent client in the EHR. The client would provide a software statement signed by a cert issued by a trusted certifying body (e.g. healtheway), and we'd trust it (and issue a client for our system) because we'd trust that certifier.

Michael Donnelly (Sep 17 2019 at 18:54):

But even per-client today, SMART scopes aren't used directly in Epic's registration process (i.e., SMART scopes don't show up by name in the app registration process, and the options that do appear are at slightly different granularity -- like search-as-distinct-from-read). This doesn't strike me as a huge problem, but it does make me wonder about the value of standardizing scopes, in a world where they're not actually being used.

True! But if we (the community) can get SMART scopes to the level of granularity we (Epic) believe is necessary, we (Epic) will be able to use them in our client creation process.

Josh Mandel (Sep 17 2019 at 19:42):

The client would provide a software statement signed by a cert issued by a trusted certifying body

to be clear, what I mean is that this software statement could bake in a list of "scopes" or permissions of some kind, just as it bakes in a redirect_uri, etc.

Josh Mandel (Sep 17 2019 at 19:44):

Indeed, it does as a claim in the JWT:

scope: string, space delimited list of requested scopes (optional))

Michael Donnelly (Sep 17 2019 at 19:50):

The client would provide a software statement signed by a cert issued by a trusted certifying body

to be clear, what I mean is that this software statement could bake in a list of "scopes" or permissions of some kind, just as it bakes in a redirect_uri, etc.

That's what I meant too. But I'm saying that, in that scenario, we wouldn't have the software statement until the moment the client requests to create a dynamic client.

Michael Donnelly (Sep 17 2019 at 19:52):

Ah, I found the miscommunication. You said "the set of permissions provided during the up-front registration step," and I was thinking you meant up-front client creation with Epic. If you're talking about registration with a third party certifying body, we're on the same page.

Josh Mandel (Sep 17 2019 at 20:18):

Indeed :) I was talking about these both equivalently

Last updated: Apr 12 2022 at 19:14 UTC