Stream: smart
Topic: SMART App Launch v2
Travis Rotz (Apr 26 2021 at 21:39):
Connectathon 27 Track -> SMART App Launch v2
This is a place to discuss "SMART v2" in general.
Chuck Feltner (May 03 2021 at 13:23):
For the upcoming 2021-05 SMART App Launch v2 Connectathon Track, are there any participating servers or SMART Apps planning to test with EHR Launch? That is from within an existing EHR session and encounter context.
Josh Mandel (May 14 2021 at 17:00):
Welcome to our Connectathon #27 Kickoff! I'll share links here for key resources.
Josh Mandel (May 14 2021 at 17:01):
- Track Overview Page with Scenarios
- SMART App Launch v2 Spec (CI)
- Sign-up Spreadsheet with Server + Client Links
- SMARTv2 Launcher
Josh Mandel (May 14 2021 at 17:29):
SMART Launcher: https://github.com/smart-on-fhir/smart-launcher
Josh Mandel (May 14 2021 at 17:29):
Fork of launcher with v2 features: https://github.com/microsoft-healthcare-madison/smart-launcher
Brian Postlethwaite (May 18 2021 at 11:00):
Can the smart granular test client be use the smart launch rather than standalone?
Brian Postlethwaite (May 18 2021 at 11:04):
Also, wondering if the URL of the fhir server changes for each session, would others find that strange?
A smart client we're building uses the base URL, and now that's likely to cause me some grief :(
Josh Mandel (May 18 2021 at 14:54):
Hey everyone on SMARTv2 Connectathon -- we'll have our check-in/welcome call in 5min!
Josh Mandel (May 18 2021 at 14:56):
Brian Postlethwaite: Can the smart granular test client be use the smart launch rather than standalone?
You mean the EHR Launch? I think it's not currently set up for that; it'd be a good feature, though it leaves open the question of how/where you'd want to set the additional params (e.g., use pkce? use POST-based authz, etc?) Can be hard-coded in the app, or the app could "capture" the launch and wait while the user chose settings to proceed...
Josh Mandel (May 18 2021 at 14:57):
smart client we're building uses the base URL, and now that's likely to cause me some grief :(
Uses base URL of what? I'm not yet following (and not sure if this is a spec issue, or just something about the behavior of our sample app and/or demo server).
Josh Mandel (May 19 2021 at 15:19):
We'll have our wrap-up call in just under 2 hours -- it has been a quiet chat here. Would appreciate if folks could add feedback and wrap-up notes to Column G of https://docs.google.com/spreadsheets/d/10j4a0juCrlZPDtrvOQaNNgSNPUU5MK9Hm7reCg1RF6A/edit#gid=0 based on your experience. Just a quick summary of how the event went, plus highlights, comments or questions. I'll use this for the wrap-up report.
Keith Carlson (May 19 2021 at 15:40):
@Josh Mandel I see you mentioned a "register" endpoint at https://launch.smarthealthit.org/. Where is that endpoint listed? I'm not seeing it in the .well-known/smart-configuration
Josh Mandel (May 19 2021 at 16:17):
I don't think it's a dynreg-compliant endpoint, so it wouldn't make sense to list there in current state; it's hosted at /register. If you want, you can use the UI at https://bulk-data.smarthealthit.org/ to see this in action, and the client_ids generated by that tool should be usable at https://smart.argo.run/
Josh Mandel (May 19 2021 at 16:18):
An example invocation is:
$ curl 'https://bulk-data.smarthealthit.org/auth/register' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' --data-raw 'jwks=%7B%22keys%22%3A%5B%7B%22kty%22%3A%22EC%22%2C%22crv%22%3A%22P-384%22%2C%22x%22%3A%22lSG-9XHZcN6XdUXE6sCnvnGYHClZ1odZLUrLou3kgyMQuwd612Yr--wb8btsVAXf%22%2C%22y%22%3A%22oCsstCTa8NGZ6ou1GOB8mJhdn_gAzeTlHtINFrF1_VG9k0JxFnE9aHyi2qgoW9vx%22%2C%22key_ops%22%3A%5B%22verify%22%5D%2C%22ext%22%3Atrue%2C%22kid%22%3A%2235fbeb4493b0569fb6983a35f06aa5b9%22%2C%22alg%22%3A%22ES384%22%7D%2C%7B%22kty%22%3A%22EC%22%2C%22crv%22%3A%22P-384%22%2C%22d%22%3A%22KozncWMn_lo6nBa2nou5HM2hPgnAcp73B5sQl3_vt61O9wxTG_s4xgjDAO8ipNkg%22%2C%22x%22%3A%22lSG-9XHZcN6XdUXE6sCnvnGYHClZ1odZLUrLou3kgyMQuwd612Yr--wb8btsVAXf%22%2C%22y%22%3A%22oCsstCTa8NGZ6ou1GOB8mJhdn_gAzeTlHtINFrF1_VG9k0JxFnE9aHyi2qgoW9vx%22%2C%22key_ops%22%3A%5B%22sign%22%5D%2C%22ext%22%3Atrue%2C%22kid%22%3A%2235fbeb4493b0569fb6983a35f06aa5b9%22%2C%22alg%22%3A%22ES384%22%7D%5D%7D&dur=15'
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InJlZ2lzdHJhdGlvbi10b2tlbiJ9.eyJqd2tzIjp7ImtleXMiOlt7Imt0eSI6IkVDIiwiY3J2IjoiUC0zODQiLCJ4IjoibFNHLTlYSFpjTjZYZFVYRTZzQ252bkdZSENsWjFvZFpMVXJMb3Uza2d5TVF1d2Q2MTJZci0td2I4YnRzVkFYZiIsInkiOiJvQ3NzdENUYThOR1o2b3UxR09COG1KaGRuX2dBemVUbEh0SU5GckYxX1ZHOWswSnhGbkU5YUh5aTJxZ29XOXZ4Iiwia2V5X29wcyI6WyJ2ZXJpZnkiXSwiZXh0Ijp0cnVlLCJraWQiOiIzNWZiZWI0NDkzYjA1NjlmYjY5ODNhMzVmMDZhYTViOSIsImFsZyI6IkVTMzg0In0seyJrdHkiOiJFQyIsImNydiI6IlAtMzg0IiwiZCI6Iktvem5jV01uX2xvNm5CYTJub3U1SE0yaFBnbkFjcDczQjVzUWwzX3Z0NjFPOXd4VEdfczR4Z2pEQU84aXBOa2ciLCJ4IjoibFNHLTlYSFpjTjZYZFVYRTZzQ252bkdZSENsWjFvZFpMVXJMb3Uza2d5TVF1d2Q2MTJZci0td2I4YnRzVkFYZiIsInkiOiJvQ3NzdENUYThOR1o2b3UxR09COG1KaGRuX2dBemVUbEh0SU5GckYxX1ZHOWswSnhGbkU5YUh5aTJxZ29XOXZ4Iiwia2V5X29wcyI6WyJzaWduIl0sImV4dCI6dHJ1ZSwia2lkIjoiMzVmYmViNDQ5M2IwNTY5ZmI2OTgzYTM1ZjA2YWE1YjkiLCJhbGciOiJFUzM4NCJ9XX0sImFjY2Vzc1Rva2Vuc0V4cGlyZUluIjoxNSwiaWF0IjoxNjIxNDQxMDk1fQ.b3Jx59dv_-hnRWapq99So7Plv58pS90CzmY4auWTLCA
... but it's probably easiest to interact with this via the UI.
Josh Mandel (May 19 2021 at 16:23):
(Digging in here, there's clearly more work for this to be testable; there are internal design choices bleeding through when they shouldn't.)
Chuck Feltner (May 19 2021 at 16:45):
In the track, scenario 2 specifies using the rather lengthy scope
patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs
Is this equivalent to
patient/Observation.rs?category=vital-signs
Currently the smart.argo.run test tool requires the scope to match with the category syntax of the resource request (i.e., system specified or not). I guess FHIR servers are expected to interpret the finer grained scopes so that either category syntax in the actual resource request is allowed?
Josh Mandel (May 19 2021 at 17:01):
Wrap-up call in 30min -- quick reminder to fill out notes and questions in Column G beforehand.
Josh Mandel (May 19 2021 at 17:02):
Technically speaking,
patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs
is narrower than
patient/Observation.rs?category=vital-signs
... because the former only matches Observations with the FHIR-recommended system, and the latter matches Observations with any system (which isn't what we really want).
Josh Mandel (May 19 2021 at 17:03):
Based on discussions in the argonaut calls, we want to encourage use of specific systems when restricting by Coding, when that's the intention (and in this case of category-based observations, it's definitely the intention).
Nikolai Schwertner (May 30 2021 at 17:38):
@Josh Mandel @Vladimir Ignatov Is the source code for the test harness SMART app at https://smart.argo.run/granular/ available by any chance? I was looking for it at https://github.com/smart-on-fhir but no luck...
Josh Mandel (May 30 2021 at 18:01):
https://github.com/smart-on-fhir/smart-launcher/pull/47 is the PR with draft be functionality, as deployed at smart.argo.run
Nikolai Schwertner (May 30 2021 at 22:12):
Thank you very much @Josh Mandel
Nice work, @Gino Canessa!
Brian Postlethwaite (Jun 23 2021 at 23:58):
In reviewing the example response from the spec here
http://build.fhir.org/ig/HL7/smart-app-launch/conformance.html#sample-response
{
...
"scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.rs", "user/*.rs", "offline_access"],
"response_types_supported": ["code", "code id_token", "id_token", "refresh_token"],
"management_endpoint": "https://ehr.example.com/user/manage",
...
}
I note that the response_types_supported has an example value of "code token" and the 2 values as seperate code and token. Is that meant to imply that the combinations supported should be included?
@Josh Mandel ?
Josh Mandel (Jun 24 2021 at 00:53):
Do you mean "code id_token" ? This isn't something we particularly profile in SMART, but if you read the OIDC Core spec, https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest defines this behavior. But it's perhaps a confusing example for us to include here
Brian Postlethwaite (Jun 24 2021 at 01:13):
Isn't it really just saying that they are space delimited, rather than the combination is required to be pre-declared?
Josh Mandel (Jun 24 2021 at 01:15):
No this is a specific hybrid flow that gives you back an ID token and an authorization code as two separate artifacts
Josh Mandel (Jun 24 2021 at 01:15):
It's the code id_token flow.
Josh Mandel (Jun 24 2021 at 01:17):
Hybrid flow in OIDC is pretty in the weeds though; I wouldn't bother with it in the context of SMART app launch use cases.
Brian Postlethwaite (Jun 24 2021 at 01:19):
Ah, so code for code exchange (via the token endpoint)
or code id-token to get code (to exchange for bearer at token endpoint) and also id_token at the same time
Brian Postlethwaite (Jun 24 2021 at 01:19):
I get what you mean, I've only done the code flow.
Josh Mandel (Jun 24 2021 at 01:20):
Yeah, code is all that SMART requires (as long as you support scopes that allow you to request an ID token as part of the access token response). https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata goes into more definitional detail though if you are interested.
Brian Postlethwaite (Jun 24 2021 at 01:24):
Thanks, I'll leave that part as just having code in the Australian profile to keep it simple...
Brian Postlethwaite (Jun 24 2021 at 01:28):
id-token can come back from the code exchange anyway through the scope openid fhirUser right?
Josh Mandel (Jun 24 2021 at 03:15):
With code flow, you can get an id token back in the access token response, when you trade in your authorization code at the token endpoint. (With the hybrid flow, you can get an id_token back at the same time you receive the code, as a URL param.)
Brian Postlethwaite (Jun 30 2021 at 01:51):
In the metadata scopes defined, there is a note that additional scopes MAY be supported, but there isn't a note, that not all clients will have access to all scopes listed too - is this a reasonable thing to have added?
http://build.fhir.org/ig/HL7/smart-app-launch/conformance.html#metadata
Brian Postlethwaite (Jun 30 2021 at 01:53):
Also the link in that section points to a docs.smarthealthit page, and not to the scopes page in the spec - log this?
Brian Postlethwaite (Jun 30 2021 at 02:00):
When a client requests a scope via the permission-v1 format, is there any guidance or expectation that the auth server should return v1 permissions, or could it return v2 permissions instead?
Sorry, just found the line that specifically points this out. (I missread the semantics mapping)
Josh Mandel (Jun 30 2021 at 02:28):
Re: "not all clients will have access to all scopes" -- we really don't say anything about client registration. if there's specific language you'd like to see, definitely do submit an issue.
And yeah, issue for the incorrect link would be great. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
