Both CDex Task Attachment Request Profile and the DTR Standard Questionnaire profile have the overlapping capability to indicate that a signature is required. Signers SHALL meet both the Task and Questionnaire signature expectations.

SHALL use the CDex Digital Signature Profile with the CDex Signature Bundle Profile for digitally signed Bundles and with the CDex SDC QuestionnaireResponse Profile for digitally signed QuestionnaireResponse.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The Signature.data is base64 encoded JWS-Signature [RFC 7515]: JSON Web Signature (JWS)

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The JWS mime type application/jose SHALL be indicated in the Signature.sigFormat element.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]:...SHALL use the IETF JSON Canonicalization Scheme (JCS) (see RFC 8785) to generate the canonical form of the resource.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]:... the URI application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json#document ... SHALL be indicated in the Signature.targetFormat element.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: Bundle.id, and Bundle.meta SHALL be removed before canonicalization. In other words, everything in a Bundle is signed except for these elements.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: For signatures representing the entire QuestionnaireResponse, QuestionnaireResponse.id, and QuestionnaireResponse.meta elements SHALL be removed before canonicalization. In other words, everything in a QuestionnaireResponse is signed except for these elements.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: For signatures representing an item in the QuestionnaireResponse, the QuestionnaireResponse.item.id SHALL be removed before canonicalization. In other words, everything in the QuestionnaireResponse.item is signed except for these elements.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The signature SHALL include a "srCms" signer commitments" header element for the Purpose(s) of the Signature (see JAdES-B-T, page 17). The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from ASTM E1762-95(2013).

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The "srCms" header SHALL contain an "id": "urn:oid:1.2.840.10065.1.12.1.5" (Verification Signature)

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The Signature.type.code elements SHALL contain the same values as the "srCms" header ids.

[The signature header] SHALL include an "alg" parameter for the JSON Web Algorithms (JWA) (see RFC 7518). "alg": "RS256" is preferred.

[The signature header] SHALL have "x5c" (X.509 certificate chain) equal to an array of one or more base64-encoded (not base64url-encoded) DER representations of the public certificate or certificate chain (see RFC 7517).

[The signature header] SHALL include a "sigT" header parameter with a timestamp of the signature.

[The signature header] SHALL include a "srCms" signer commitments as defined above.[ commitments header element for the Purpose(s) of the Signature]

[The signature] SHALL support JWS compact serialization format for single signatures

The [signature] certificate SHALL include a Subject Alternative Name (SAN)

[The] Subject Alternative Name (SAN) ... SHALL match the Signature.who.identifier[element].

[The signature] SHOULD use the hashing algorithm SHA256. The signature validation policy will apply to the signature and determine the acceptability

[The signature] SHOULD support JWS JSON Serialization format to represent multiple signatures with identical parameter values except "x5c".

Implementers that support both XML and JSON wire formats MAY support cross format signatures by:

• Validating the JSON Web Signatures in the JSON format.
• Canonicalizing the XHTMLtext.div narrative element following the FHIR R6 XML Canonicalization rules prior to the JSON canonicalization of the resource.
• identifying this canonicalization method by the URI application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json+xml#document in the Signature.targetFormat element.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The signature is a [Detached] Signature (where the content that is signed is removed from the JWS)

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: The Bundle.signature or the QuestionnaireResponse [signatureRequired] extension is removed before signing.

[Implementers SHALL follow the following FHIR R6 JSON Signature rules]: When FHIR Resources are signed, the signature is across the Canonical JSON form of the resource(s)