Stream: CARIN IG for Blue Button®
Topic: Connectathon - Optum Server
Amy Ballard (Sep 10 2020 at 16:40):
@Daniel Venton The Optum CapabilityStatement, https://flexdev-eastus.optum.com/R4/metadata, doesn't include the OAuth endpoint URLs. Alternatively, there is also no .well-known/smart-configuration link.
Michele Mottini (Sep 10 2020 at 20:07):
Apparently Optum server requires PKCE to connect, but if I am not mistaken that's now what the SMART standard (that CARIN BB compliant server should support) require
Benjamin Langley (Sep 10 2020 at 20:39):
PKCE is only for apps which can't maintain a client_secret. The smart flow is pretty vague about what to do for public apps in the token step: http://hl7.org/fhir/smart-app-launch/index.html#step-3-app-exchanges-authorization-code-for-access-token
Michele Mottini (Sep 10 2020 at 20:42):
...our is not a public app, we have a server where we keep the secrets
Josh Mandel (Sep 10 2020 at 20:43):
smart flow is pretty vague about what to do for public apps in the token step
I don't think the spec is vague: we say "For public apps, authentication is not possible (and thus not required)".
Josh Mandel (Sep 10 2020 at 20:43):
Public clients can't and don't authenticate when trading and authorization code for a token.
Michele Mottini (Sep 10 2020 at 20:44):
So is requiring PKCE for all client non-compliant?
Josh Mandel (Sep 10 2020 at 20:46):
Requiring PKCE wouldn't be compliant, because clients following the SMART App Launch IG wouldn't be able to get a token; I'd recommend using https://inferno.healthit.gov/ supports testing the SMART App Launch spec.
Josh Mandel (Sep 10 2020 at 20:48):
You could add PKCE as an option for clients to opt into.
Josh Mandel (Sep 10 2020 at 20:50):
(In general, you can also get relevant protections on mobile platforms with app-claimed URLs.)
Daniel Venton (Sep 10 2020 at 21:41):
@Mark Roberts @Amol Vyas Optum is not an EHR (we represent Payers) and we are implementing the CARIN BB IG for CMS interoperability and patient access API. What exact conformance statement in the IG prevents us from requiring PKCE to authenticate? PKCE can be implemented in the client app, if they choose to do so. Our institutional policy dictates usage of PKCE for access to PHI. We feel that PKCE is a suitable implementation of the secret requirement. From the SMART App Launch Framework IG section 1, "This profile does not dictate the institutional policies that are implemented in the authorization server."
Josh Mandel (Sep 11 2020 at 03:02):
To be clear, if you want to be compatible with the SMART App Launch IG, you'll want to make sure your server works according to the specification and passes the test suite. Requiring additional parameters means breaking clients that conform to the IG.
Josh Mandel (Sep 11 2020 at 03:03):
You can allow clients to opt into PKCE, but that's different from breaking clients that don't use PKCE.
Josh Mandel (Sep 11 2020 at 03:06):
The SMART App Launch IG is a requirement from CMS (they refer to specific standards adopted by ONC, including SMART).
The requirement to support SMART should also be spelled out in the CARIN Blue Button IG, to avoid any confusion.
Michele Mottini (Sep 11 2020 at 12:21):
It is: 'Client applications and systems of record SHALL support the standalone launch sequence of the SMART App Launch framework' (from http://build.fhir.org/ig/HL7/carin-bb/Authorization_Authentication_and_Registration.html#smart-on-fhir-application-launch)
Josh Lamb (Sep 11 2020 at 13:57):
we want to modify this slightly to also call out a SHALL requirement for launch/Patient scope and a MAY requirement for User scope.
Last updated: Apr 12 2022 at 19:14 UTC
