Stream: smart
Topic: SMART Apps: well_known or Capabilities?
Jenni Syed (Sep 30 2020 at 16:43):
Have we ever considered/discussed having a well known endpoint for SMART apps? In the past, for FHIR, there has been discussion about capabilityStatements that are app-specific (what capabilities they use/require)... But there's no standard way to host that
Jenni Syed (Sep 30 2020 at 16:45):
Similarly, do we think SMART apps will ever want to declare the SMART capabilities they need?
Josh Mandel (Sep 30 2020 at 19:03):
Do you have an example of what this would be used for and what it'd look like? I'm not sure if I'm following.
Josh Mandel (Sep 30 2020 at 19:03):
re: declaring capabilities, I guess I'd say maybe. There hasn't been much interest in client CapabilityStatements overall, but maybe some of Grahame's ideas around a "features" API would help with this.
Jenni Syed (Sep 30 2020 at 20:15):
One way would be to point to the location of their capabilityStatement and required/implemented SMART features, so that during dynamic registration you could also determine compatibility
Jenni Syed (Sep 30 2020 at 20:16):
We're also looking at ways to provide better assurances to patients that the app is "trustable" - based on certs as well as the app/website/host "declaring" an intent to host the SMART app in some way...
Jenni Syed (Sep 30 2020 at 20:16):
(vs, for example, exploiting an open redirect to get a "trusted" certificate)
Isaac Vetter (Sep 30 2020 at 20:18):
Jenni, have ya'll ever looked at UDAP's endorsements? (Dennis knows alot about this). It's complicated, and thorough.
Jenni Syed (Sep 30 2020 at 20:21):
I don't think (unless I'm missing it being used outside of registration) that helps with ongoing trust validation/developer identity
Jenni Syed (Sep 30 2020 at 20:22):
It does help with compatibility (at least initially) with the auth mechanisms, but won't touch FHIR capabilities
Jenni Syed (Sep 30 2020 at 20:22):
but things often "work" or can be "trusted" when first registered. 5 years down the road, there are different issues
Jenni Syed (Sep 30 2020 at 20:28):
(specifically: without requiring "special effort" of going through some certifier - and I'm not as worried about the ones that are validated by someone... that's a different level of trust)
Ryan Howells (Oct 01 2020 at 03:13):
Hoping @Luis Maas can weigh in here as we (CARIN) like what he has done to establish trust with UDAP endorsements.
Jenni Syed (Oct 01 2020 at 14:58):
To be clear, the type of trust I'm trying to establish here would hopefully not require an app to be validated - that is a different level of trust, and it's not something we can require for 21CC apps
Jenni Syed (Oct 01 2020 at 14:59):
This would hopefully be a "low bar" approach that a developer could do on their own to essentially "prove" they own the URL they're redirecting to, in addition to using the certificates advertised on the URL itself.
Jenni Syed (Oct 01 2020 at 15:00):
The certs get us pretty far in what we can tell the patient we know about an app, but there are some scenarios it doesn't account for (eg: hosting platforms, security vulnerabilities like open redirect)
Jenni Syed (Oct 01 2020 at 15:01):
And in an ongoing fashion - not just at initial reg
Jenni Syed (Oct 01 2020 at 15:02):
And I still think it's useful for an app to have a well known (even if not well_known) like FHIR servers have to declare their functionality and requirements :)
Jenni Syed (Oct 01 2020 at 15:03):
I can see wanting to align with UDAP, as those features may be things an org would "certify" as well
Isaac Vetter (Oct 02 2020 at 19:57):
Jenni - I think I understand your goal. A clarification to the above (that Luis is better qualified to make) -- UDAP's self-signed certification is a technical mechanism for an app to make an attestation during registration.
Back to your goal, I'm sure you're familiar with the variety of non-standard methods used to verify domain ownership. It's usually some form of: developer given auto-generated code to place in a specifically named file on their domain. An interesting variation of this is a DNS TXT file containing a one-time generated code used by Google Cloud.
These domain ownership verification methods are intended to be single use though. What have you already considered?
Jenni Syed (Oct 02 2020 at 22:15):
@Isaac Vetter yes, and we were curious about something from well known being that "non-standard" (but standard for SMART) way to do something like that. That both verifies "I own this" AND "I intended it to host a SMART app" (open redirect/hosting issues)
Jenni Syed (Oct 02 2020 at 22:17):
That is ongoing b/c the certs can be consistently checked/the file that proves intention can be checked (it would need to be more of a signed approach - lowest fi from a server perspective is "sign this with your private key" b/c we have the public cert, but that may not be easy for all)
Last updated: Apr 12 2022 at 19:14 UTC
