Thanks for putting this together. I have a couple of items for feedback.
1. Regarding TLS versions, in IHE we've trended toward asserting that the use of TLS SHALL be compliant with IETF BCP 195 rather than referencing specific TLS versions. Doing so reduces the risk that the security guidance in our specifications will fall out of alignment with current best practices established by IETF's security community. BCP 195 was recently updated to deprecate TLS versions 1.0 and 1.1, so the desire to set a floor of TLS 1.2 is currently consistent with BCP 195.
2. Outside of UDAP, it is common for systems to exchange authentication keys using an out of band mechanism rather than using X.509 certificates. They might do so by exchanging bare keys or by establishing a URL at which a JWKS object can be retrieved. Existing implementations of SMART are likely to not support using X.509 certificates. I recommend making the "SHALL be tied to the client system's certificate" be applicable only to UDAP implementations, and allow SMART systems to exchange keys in other ways.
We have received feedback for CA:FeX specification indicating that CA:FeX security page references security guidance from the base FHIR spec, and it sets minimal requirements (FHIR has a checklist, but doesn't impose any requirements). Based on this feedback, it was discussed in CA:FeX working group to create more specific requirements in terms of exchange security. In response, we have reviewed other Implementation Guides (Da Vinci IG, US Core) to develop our 'Exchange Security' section.
Additionally, we've included considerations for
CA:FeX cross-profile interactions
. This enhancement provides guidance on how CA:FeX actors can be grouped with other IHE profiles, such as CT, IUA, and ATNA, for enhanced security capabilities.
Please take a moment to review these
added CA:FeX security sections
and share your feedback on any elements that may require removal or further expansion.
Request for Review: New CA:FeX Security Sections
Imprimer
Courriel
Twitter