Reconsider strict scope checking for refresh access tokens

[cooperthompson]

In Inferno 1.9, you checked that the scopes associated with a refresh access token were a strict subset of the scopes in the initial access token. In Inferno 2.0, you upgraded that check to do a full equivalence check.

Initially, I thought this made sense, but after more discussion both internally and on chat.fhir.org (Expected scopes on a "refreshed" access token), I'd like to propose relaxing the scope check. We can either relax it back to how it was in 1.9, or make special exceptions for fhirUser and openid scopes. See the chat.fhir.org discussion for background on why I'm suggesting that change.

[cooperthompson]

For reference, the SMART 1.0.0 spec (refresh token section) has this language:

scope - Scope of access authorized. Note that this will be the same as the scope of the original access token, and it can be different from the scopes requested by the app.

This isn't formal SHALL/SHOULD language, but does kinda imply that all scopes should be the same. However, further discussion on chat.fhir.org indicate that wasn't the intent of that statement. Still, if this requires ONC clarification because of that language, let me know.

[cooperthompson]

I realized I didn't mention the specific test, which is 1.4.02:

[arscan]

Thanks for doing the legwork here @cooperthompson. I followed up on that thread, because I just want to be sure that I understand the intent -- this is particularly confusing because of the way that fhirUser and openid are different than traditional access scopes, and "scope" is an overloaded term.

I understand there is no 'SHALL' language there, but if you search throughout the spec for "will", you'll see that term is used quite frequently in places where one of the actors has to do something specific in order for the flows to function. If we viewed all 'wills' as suggestions then I think we'd be in trouble interoperability-wise. Please correct me if I'm wrong here though.

Could there be a change request on the language there to be "will usually be the same...", or "will be a strict subset..."?

[arscan]

From Josh:

The fhirUser and openid scopes might well be excluded; but any patient/ or user/ scopes (FHIR data access scopes) from the original token scopes should be there

We'll plan on loosening this constraint in the next release of the g10 test kit, unless there is any clear disagreement from the community.

[cooperthompson]

I submitted FHIR-36272 to clarify this, probably by loosening the language.