docs icon indicating copy to clipboard operation
docs copied to clipboard

Remove "subject" property from "fhirAuthorization" object

Open jmandel opened this issue 6 years ago • 3 comments

Currently we define a "fhirAuthorization" object with a subject property:

image

This is the only place in the specification where the CDS Service's client_id (as issued by the EHR at registration time) is used, and it doesn't provide any benefit. The CDS Service already has an EHR-issued JWT at this point in the workflow, including a signature that can be used to authenticate the request, and an aud field tying the request to this particular Service endpoint. Adding a client_id into the mix creates confusion without benefit.

I'd recommend:

  1. Removing this property from the fhirAuthorization object definition
  2. Removing this property from all examples
  3. Strike the indicated six words from: "Pre-registration MUST include ~registering a CDS client identifier, and~ agreeing upon the scope of FHIR access..."
  4. Strike the indicated parenthetical from: "The specification requires that each CDS Service provider be registered ~(client_id, key-pair identifier)~ with the EHR Authorization Server, but does not dictate how registration is accomplished (e.g., dynamic vs. manual)". Since the client_id should be unnecessary, and we do not in fact require or even describe the use of a CDS-service-held keypair.

jmandel avatar May 15 '18 12:05 jmandel

@jmandel - This slipped through as our focus was on ballot issues over the past several months. As we near our final publication of the specification, I found this and wanted to reach out to you about this. How strongly do you feel about this?

Thoughts @brynrhodes @isaacvetter?

kpshek avatar Jan 10 '19 14:01 kpshek

I think it's a targeted fix that will eliminate confusion down the line. Also in favor of mixing this change: old clients that happen to include this extra subject property should still work. So unless we know we've got servers that somehow check the subject property (against ... what?), I'd like to pursue this change.

jmandel avatar Jan 10 '19 17:01 jmandel

Agreed, all for a simple change that will decrease confusion downstream. It would be good to know whether there are any systems that actually check it now.

brynrhodes avatar Jan 13 '19 15:01 brynrhodes