Stream: cds hooks/github
Topic: docs / Issue #7 Determine an approach to security
Github Notifications (May 18 2017 at 21:05):
yashaskram commented on Issue #7
@kpshek - thx for putting together the security proposal.
Is there an option to use the same trust detailed in https://github.com/cds-hooks/docs/wiki/Proposed-Security-Model#ehr-trust-of-cds-services for the CDS Service trust on EHR + client credential flow https://tools.ietf.org/html/rfc6749#section-4.4 (with unsigned jwt token ) assuming offline client registration (cds service registration on the EHRauth server)
There will be two calls [1) token endpoint 2) token requestover] over the wire which can bring up latency concerns. In the proposed model there will be similar calls to discover jwks_uri and inturn get the public key (or atleast one)
While I generally prefer to use JWS and moved beyond JWT even for SMART on FHIR token response, I was wondering if we should be aligned with SMART on FHIR at this point atleast to begin with.
I missed the discussion happened in San Antonia early this year and also Security WG presentation in Madrid. So appreciate any input
To the outstanding question at the end of proposed model (if we decide go with the proposed model), I am inclined to having FHIR server as the issuer (again to be in sync with SMART on FHIR) and adding jwks_uri ( or public key) to Conformance
Github Notifications (Jul 10 2017 at 20:25):
kpshek assigned Issue #7
Github Notifications (Aug 14 2017 at 20:39):
yashaskram commented on Issue #7
The latest iteration - [_link_] looks good and covers both ends robustly which is great.
id_token should be signed. I don't think CDS vendors would like to trust an unsigned jwt for SSO (authentication) when pushed as opposed to pulling (or requesting) the token in the case of the authorization grant or client credential flow. I agree with preference to have an FHIR extension to serve the public key uri
With the assumption of requiring id_token to be signed and using the same for discovery end point calls, we should think about how to exchange the FHIR base URL assuming FHIR Conformance is used serve public key uri
Keeping the cost of handling the token proactively on the EHR for performance reasons is great, but there will be over the wire transactions to get the public key (basically hitting FHIR server to get the conformance to get the public key (jwks_uri) end point and in turn public key for CDS Service provider to validate the id_token with incoming requests. Question: Based on the scope authorized by a particular CDS Hook service, I would assume there will be more than one access token generated and cached at the EHR side based on the user/cds hook service. How do EHR plan to handle this?
Github Notifications (Sep 05 2017 at 16:10):
isaacvetter commented on Issue #7
Hey Guys,
We're assuming / leaning towards documenting the FHIR Server's public key (that's used to sign/encrypt the JWT) in the CapabilityStatement. Note that this is not consistent with the SMART spec that's being balloted, which essentially locates the key outside of FHIR: http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context/#steps-for-using-an-id-token
I think that CDS Hooks should stay consistent with SMART.
Github Notifications (Sep 05 2017 at 16:38):
Good point! It's worth proposing this as part of a ballot comment on the SMART spec if you haven't already done so @Isaac Vetter :-)
Github Notifications (Sep 05 2017 at 16:55):
isaacvetter commented on Issue #7
Thanks, @Josh Mandel -- Will do.
@whitehatguy, @kpshek - are you currently publishing a public key for the purposes of OIDC validation? If so, does a client follow these steps to retrieve it, or rather, have you extended your Conformance/CapabilityStatement resource?
Github Notifications (Oct 19 2017 at 20:37):
isaacvetter labeled Issue #7
Github Notifications (Oct 30 2017 at 21:04):
Resolving this issue with the merge of #72 (ae86854). We are embarking on a external security assessment with a 3rd party security firm. We will address any changes from that on additional issues.
Closing.
Github Notifications (Oct 30 2017 at 21:04):
kpshek closed Issue #7
Last updated: Apr 12 2022 at 19:14 UTC
