Use 'fhirUser' scope/claim instead of 'profile' scope/claim for OIDC

[kpshek]

In discussion with @isaacvetter and @whitehatguy, we were digging into SMART's use of OpenID Connect. As part of this discussion, we came to the realization that SMART is overloading OIDC's profile scope and claim.

Per the OIDC specification, the profile scope is defined as:

OPTIONAL. This scope value requests access to the End-User's default profile Claims, which are: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.

SMART is overloading the profile scope to be just the profile claim (and none of the other claims).

The profile claim of OIDC is thus defined as:

URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User.

The intention of the profile claim is the profile page of the user (eg, the user's LinkedIn or Google profile) so that they can put a link to it. SMART is overloading the profile claim to be the user's FHIR server URL (which in the majority/all cases today is an API data endpoint).

We feel that it would be better to define a new scope and claim: fhirUser. The benefits to this approach:

• Authorization servers and SMART apps that are using OpenID Connect more broadly can utilize the profile scope and claim as intended per OIDC.
• SMART can add very clear documentation on this new claim and scope rather than redefine an existing scope/claim

[jmandel]

Thanks @kpshek! I think this would bring very welcome clarity! (Though the pain of a breaking change here is a consideration, I think OIDC is one of the least-implemented parts of the spec at any rate, and we'd do well to hit the "reset button" and get things right.) If we're going to introduce a new scope and claim, we should also be clear about:

• what is the claim?
• Is it a relative URL like Patient/123, or
• n absolute URL?
• Should it actually be two or three claims (e.g. c claim for the FHIR server base, a claim for the user type, and a claim for the id)?

[isaacvetter]

I think that this proposed fhirUser claim should always be a single, absolute (non-search) url to the identity of the current user as represented in FHIR.

It's a feature of SMART that it's tightly integrated into FHIR. Let's not overcomplicate this. The FHIR server base url and user type are fairly explicitly asserted in an absolute url.

@jmandel - does that sounds alright with you?

[jmandel]

If we lock it down to an absolute URL: is it ok for this URL to have a different base URL from the FHIR server that the app is connecting to in the overall OAuth flow? If it can be different, should the app use its access token for the "main" FHIR server to talk to this different one? Relative URLs avoid these particular issues. But if we said it needs to be an absolute URL and it needs to have the same base as the FHIR server that the app is connecting to in the overall OAuth flow, that works too.

[isaacvetter]

Josh - I hadn't considered some of the distributed edge cases that you're pointing out. I think that it is not only reasonable, but probably a good idea, to require the authorization server that's asserting the user's identity to also "host" the user's identity.

This would mean that yes - the fhirUser absolute url should be the same FHIR server that the app is connecting to.

In practice, for a more distributed app / user identity, a SMART/FHIR server that wants to point to an external FHIR server's Patient (or Practitioner/Person/RelatedPerson) resource should proxy that user identity to the app.

I think that this keeps it simpler for the app.

[michelemottini]

I like fhiruser

Could the specs specifically include also Person as a possible target resource? The current specs at http://docs.smarthealthit.org/authorization/scopes-and-launch-context/ list only Practitioner, RelatedPerson and Patient - and no one of those really match our users, the only resource we could use is Person - and I think other systems are in the same situation.

[daliboz]

Note: the authorization server and the FHIR server may be different @isaacvetter @jmandel, so just one clarification on it being "hosted by the authorization server": I agree the Patient/Practitioner/etc absolute URL should be the same FHIR server as the "aud" parameter that the app would send to the authorization server (the target FHIR server).

In regards to allowing Person: I also agree with @michelemottini - there was a discussion on this exact issue in the SMART group where we decided Person was allowable. I just don't think we rolled that back into the doc. Should this be logged as a different issue?

[isaacvetter]

Hey @daliboz , @michelemottini , @whitehatguy ,

Yes, I think this should be a separate issue. Just wrote up #148 -- did I get it right?

I'll also make this comment on the HL7 ballot.

Isaac

[michelemottini]

Yes, thanks Isaac