Stream: cds hooks/github
Topic: docs / Issue #188 What should a CDS Service do with this ...
Github Notifications (Mar 28 2018 at 16:08):
isaacvetter opened Issue #188
There's some disparate guidance to CDS Services in the Trusting EHRs section of the spec now, about how the EHR-created JWT should be validated.
Currently, we say:
- CDS Services SHOULD whitelist the iss, jku and sub fields to only the EHRs they trust.Additional best-practices to verify the JWT are:
1) Respect the exp field. A CDS Service SHOULD reject a request containing a JWT with an _exp_ value greater than now.
2) Use the jti / nonce field. A CDS Service SHOULD reject a request containing a _jti_ that has been previously used by the EHR.
3) Perhaps even reject requests with an old iat. A CDS Service MAY reject a request containing a _iat_ older than 8 minutes.
4) Verify that the public key used to sign the JWT is valid. A CDS Service SHOULD verify that the public key used to sign the JWT exists within the JWK set at the location identified by the jku and is identified by the kid.Is this worthwhile? What am I missing?
In a brief conversation with @kpshek , he pointed out that this type of guidance may be best placed in an implementation guide and not in the spec.
Github Notifications (Apr 11 2018 at 15:29):
isaacvetter labeled Issue #188
Github Notifications (Jun 05 2018 at 07:51):
kpshek milestoned Issue #188
Github Notifications (Jun 05 2018 at 07:52):
kpshek commented on Issue #188
I agree with @isaacvetter that we need this documentation. I originally was thinking this should be placed in an implementation guide but my thoughts are that we should just have this directly in the spec now.
Github Notifications (Jun 06 2018 at 16:49):
bvdh commented on Issue #188
My worry is that if we put it in the specification we run the risk of deviating with the RFC's.
On the other hand. More explanation on how this should work is valuable and an implementation guide that describes the common implementation way is valuable. It should be placed outside of the spec and should not contain mandatory text.
Alternatively a profile on the recommended security approach could be considered.
Github Notifications (Jun 06 2018 at 22:00):
isaacvetter commented on Issue #188
## :telephone_receiver: CDS Working Group Call (6-6-2018)
Meeting notes: http://wiki.hl7.org/index.php?title=File:2018-06-06_CDS_WG_Call_Minutes.docx
@isacvetter moved the following disposition, seconded by @bvhd
Disposition: Persuasive with Mod
Disposition Comment:
"The CDS Hooks website should contain a set of CDS Services security best practices. This content should exist outside of the specification. We should be careful to not conflict with the existing and primary JWT spec and further should link out to the JWT specification. These security best practices should not be mandatory.We will add content following the above guidance to the CDS Hooks website."
:+1: For: 13
:expressionless: Abstain: 0
:-1: Against: 0:tada: The motion passed! :tada:
Github Notifications (Jun 14 2018 at 13:45):
cds-hooks-bot assigned Issue #188
Last updated: Apr 12 2022 at 19:14 UTC
