* When using a FHIR Questionnaire to request data, the [DTR Standard Questionnaire] Profile is used to profile the Questionnaire. 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. The Task's signature input parameter represents the need for a verification signature for the QuestionnaireResponse. The [DTR Standard Questionnaire] profile supports many reasons for signatures, including verification signatures.

1. 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. This Signature DataType profile enforces the various elements of digital signatures documented in this section.

1. Implementers SHALL follow the following FHIR R6 JSON Signature rules

• The JWS mime type application/jose SHALL be indicated in the Signature.sigFormat element.

• CDEX is pre-adopting the changes to FHIR R6 json canonicalization guidance and SHALL use the IETF JSON Canonicalization Scheme (JCS) (see [RFC 8785]) to generate the canonical form of the resource. JCS is a well-documented standardized canonicalization algorithm with multiple open-source implementations across several programming languages.

• This canonicalization method is identified by the URI application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json#document and SHALL be indicated in the Signature.targetFormat element.

• identifying This canonicalization method by the URI application/fhir+json;canonicalization=http://hl7.org/fhir/canonicalization/json+xml#document and SHALL indicate it in the Signature.targetFormat element.

• Bundle.id, and Bundle.meta SHALL be removed before canonicalization. In other words, everything in a Bundle is signed except for these elements.

• 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.

• 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.

• 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).

• The "srCms" header SHALL contain an "id": "urn:oid:1.2.840.10065.1.12.1.5" (Verification Signature)

• The Signature.type.code elements SHALL contain the same values as the "srCms" header ids.

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

3. 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]).

1. SHALL include a "sigT" header parameter with a timestamp of the signature.

2. SHALL include a "srCms" signer commitments as defined above.

2. SHALL support JWS compact serialization format for single signatures

4. The certificate SHALL include a Subject Alternative Name (SAN) which

include a Subject Alternative Name (SAN) which SHALL match the Signature.who.identifier

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

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

• The certificate Issuer SHOULD be a trusted CA for the Consumer

• The certificate KeyUsage SHOULD include 'DigitalSignature'

• The certificate Validity Dates SHOULD be appropriate/long enough as determined by the business partners

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