IHE ITI TF Vol3

5.10 Document Digital Signature (DSG) JSON Signature Document Content

Document Digital Signature content SHALL conform to JAdES schema for signatures, with extensions and restrictions defined in the following. IHE is not changing any optionality, prohibiting use of options, or mandating options. Issues such as long-term archival management of certificates are out of scope of this profile. If there is a conflict in the requirements specified here versus as specified in JAdES, then the JAdES specification shall be considered as authoritative.

5.10.1 References

5.10.1.1 Normative References

[RFC 7515] JSON Web Signature (JWS) https://tools.ietf.org/html/rfc7515

[JAdES] JSON Advanced Electronic Signatures JAdES https://www.etsi.org/deliver/etsi_ts/119100_119199/11918201/01.01.01_60/ts_11918201v010101p.pdf -- aka. ETSI TS 119 182-1

[RFC 7797] JSON Web Signature (JWS) Unencoded Payload Option https://tools.ietf.org/html/rfc7797

[RFC 7518] JSON Web Algorithms (JWA) https://tools.ietf.org/html/rfc7518

[ETSI TS 119 312] Electronic Signatures and Infrastructures (ESI); Cryptographic Suites https://www.etsi.org/deliver/etsi_ts/119300_119399/119312/01.04.03_60/ts_119312v010403p.pdf

5.10.1.2 Informative References

[ASTM-E1762-05] ASTM E1762-95(2013) – Standard Guide for the Authentication of Health Care Information

[ETSI TS 119 511] Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers providing long-term preservation of digital signatures or general data using digital signature techniques https://www.etsi.org/deliver/etsi_ts/119500_119599/119511/01.01.01_60/ts_119511v010101p.pdf

[ETSI ES 201 733] Electronic Signatures Formats https://www.etsi.org/deliver/etsi_es/201700_201799/201733/01.01.02_50/es_201733v010102m.pdf

5.10.2 JSON Signature Specification

The following constraints define the JWS JSON object. This block is common to the Detached signature and Enveloping signature.

SHALL use JSON Web Signature (JWS)(see RFC 7515). JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA).
The JWS SHALL be represented as a JSON object which uses JWS JSON serialization as specified in RFC 7515.
SHALL conform to JAdES-B-LT – for support of Long Term signatures. The JAdES-B-LT specification adds the timestamp of the signing, inclusion of the signing certificate and statement of revocation.

5.10.2.1 Protected Header

5.10.2.1.1 "alg" (Algorithm) Header Parameter

SHALL be present.
It is recommend to use algorithms as specified in RFC 7518 and ETSI TS 119 312.
RS256 algorithm SHALL be implemented for the purpose of interoperability testing. However, implementors SHOULD take into account additional considerations such as jurisdictional policies, quantum safe computing, and evolving guidance from RFC 7518 and ETSI TS 119 312.

5.10.2.1.2 "kid" (key identifier) Parameter

The kid parameter, if present, is a hint indicating which key was used to secure the JWS. The kid claim is used by DSG Content Consumers for looking up the public key for verification of digital signatures.

5.10.2.1.3 "crit" (critical) Parameter

The header SHALL include the crit header parameter and conform to specifications as per JAdES

5.10.2.1.4 "sigT" (claimed signing Time) Parameter

The header SHALL include the sigT header parameter and conform to specifications as per IHE Consistent Time (CT) profile

5.10.2.1.5 Certificate Digest

SHALL have at least one of the following header parameters in its JWS Protected Header: x5t#S256 (specified in clause 4.1.8 of IETF RFC 7515), x5c (specified in clause 4.1.6 of IETF RFC 7515), sigX5ts (specified in clause 5.2.2.3 of the JAdES specification), or x5t#o (specified in clause 5.2.2 of the JAdES Specification).

5.10.2.1.6 "srCms" (signer commitments) Header Parameter

The Signature SHALL include a "srCms signer commitments" element for the Purpose(s) of Signature. The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from Signature type ValueSet as defined in FHIR.

5.10.2.1.7 "sigPId" (signature Policy Identifier) Header Parameter

The policy may be identified in the sigPId header parameter as urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature to indicate that the signature document complies with the DSG Profile.

5.10.2.2 Unprotected Header

5.10.2.2.1 "etsiU" Unprotected Header Parameter

The etsiU parameter SHALL be present in the unprotected header as per the JAdES specification
The etsiU header parameter SHALL be the only header parameter incorporated to the JWS Unprotected Header

5.10.2.2.2 "sigTst" JSON object

The sigTst parameter SHALL be present in the unprotected header as per the JAdES specification

5.10.2.3 Payload

See the Payload sections within Detached (section 5.10.3.3) and within Enveloping (section 5.10.4.3) for specific guidance

5.10.2.4 Signature

The Signature SHALL use the algorithm in the 5.10.2.1.1 alg parameter section above.

5.10.3 JSON Detached Signature

5.10.3.1 Protected Header

5.10.3.1.1 "sigD" Header Parameter

The sigD parameter SHALL be included as per 5.2.8.1 of the JAdES Specification.
The mID member SHALL be present and set to "http://uri.etsi.org/19182/ObjectIdByURIHash"¹.
The pars member SHALL be an array of strings that contain references to each data object² being signed. This array is considered the manifest of the data objects being signed. Each string in this array shall be a URI. See Section 5.10.6.1.9 for more details.
The hashV, and the hashM members SHALL be present.
The ctys member SHALL be present.

1: For minimal interoperability and to claim conformance to IHE-DSG, the recommendation is to use the objectIdByURIHash mechanism given performance and consistency reasons, as signatures may need to be calculated on low compute devices and in distributed systems, URIs can change due to network restructuring or other factors. A hash can provide a consistent identifier that remains the same even if the underlying URI changes.

2: Data Objects refer to the binary representations of documents or any other content on which the digital signature is captured and verified

5.10.3.1.2 "cty" (content type) Header Parameter

SHALL NOT be included

5.10.3.2 Unprotected Header

No additional considerations other than the ones specified in the section 5.10.2.2

5.10.3.3 Payload

The Detached Signature is accomplished by deleting the "payload" member of the JWS JSON Object

5.10.3.4 Signature

As per section 5.2.8.3.3 of JAdES, the JWS Payload SHALL contribute shall contribute as an empty stream to the computation of the JWS Signature Value.

5.10.3.5 JSON SubmissionSet Signature

The SubmissionSet Signature is a variant of the Detached Signature used to digitally sign a complete SubmissionSet. The signature can later be validated to assure that the SubmissionSet is complete and the same as when it was created. The SubmissionSet Signature shall be a Detached Signature that has references for:

the SubmissionSet uniqueId as per 5.10.3.5.1 "iheSSId" (SubmissionSet uniqueId) Header Parameter
the document uniqueId for each of the documents contained in the SubmissionSet not including the SubmissionSet Signature document within the manifest as per above section

The SubmissionSet Signature creation is informatively described here with the Content Creator grouped with an XDS Document Source and is equally applicable with grouping the Content Creator with the other Document Sharing infrastructure. The document publication transaction is not specific to the SubmissionSet Signature process or content, and is included here only to show overall workflow. Informative process for creating a SubmissionSet Signature:

A set (n) of Documents of interest are gathered, or generated to be published.
A SubmissionSet is created for the Documents, for example in preparation for using the Provide and Register Document Set-b [ITI-41] transaction or equivalent.
A Digital Signature document is created which includes reference of:

The SubmissionSet.uniqueId is included in the iheSSId header parameter.
All of the (n) documents to be included in the SubmissionSet, other than the signature document, are listed in the manifest.
The signature document is processed according to Section 5.10.3, and thus signed.

The signature document would be added to the SubmissionSet according to Section 5.10.6. The SubmissionSet may, but is not required, include all the “SIGNS” association defined in Section 5.10.6.4 with associations to all the other documents in the SubmissionSet. The “SIGNS” association is redundant in this case as the SubmissionSet already groups these documents.
The SubmissionSet with the (n) documents and the Digital Signature document is submitted using the Provide and Register Document Set-b [ITI-41] transaction, or equivalent from the other Document Sharing infrastructures.

5.10.3.5.1 "iheSSId" (SubmissionSet uniqueId) Header Parameter

Semantics

The iheSSId header parameter shall be a new signed (protected) header parameter that qualifies the signature.

The iheSSId header parameter's value shall specify the SubmissionSet uniqueId as per the 4.2.3.3.12 SubmissionSet.uniqueId

Syntax

The iheSSId header parameter is defined below:

"iheSSId" : {"type":"string","format":"oid"}.

Note: The crit header parameter shall include the "iheSSId" extension header parameter when the SubmissionSet Option is used.

5.10.4 JSON Enveloping Signature

5.10.4.1 Protected Header

5.10.4.1.1 "cty" (content type) Header Parameter

SHALL be included as per syntax specified in IETF RFC 7515, clause 4.1.10

5.10.4.2 Unprotected Header

No additional considerations other than the ones specified in the section 5.10.2.2

5.10.4.3 Payload

When FHIR Resources are signed, the signature is across the BASE64URL(JWS Payload) form of the Payload. The DSGj profile does not create any additional expectations of transformation on the Payload of any form.

5.10.4.4 Signature

No additional considerations other than the ones specified in the section 5.10.2.4

5.10.5 JSON Signature Verification

There are three levels of signature verification:

verifying that the JWS JSON object itself has integrity through verifying the signature,
confirming that the signer was authentic, not revoked, and appropriate to the signature purpose, and
confirming that the signed Documents of interest are unmodified using the hash algorithm.

The Content Consumer SHALL verify the JWS JSON object has integrity.

The Content Consumer SHALL be able to be configured with local policy on PKI trust models and management that supports the confirmation that the signer was authentic, not revoked, and appropriate to the signature purpose. The Content Consumer SHALL use this configuration when confirming the validity of the signature.

The Content Consumer SHALL be able to confirm the validity of the documents that are signed.

Workflow or local policy may direct that all or a subset of the signed documents be validated. There are use cases where only one document within a signed set of documents is all that is called for by the workflow.
Workflow or local policy may direct that all or a subset of the signatures found within a Digital Signature Document be validated. The Digital Signature Document may contain signatures for purposes that are not relevant to the Content Consumer purpose that may not be possible to fully validate. A Content Consumer SHOULD silently ignore signatures that are not necessary to the purpose of the Content Consumer. For example, a signature may be from a different organization.
The document may not be accessible to the user, for example authorization denied, so confirmation of valid signed content may be impossible.

The decision on what degree of verification is needed is determined by the application and use case.

The Content Consumer SHALL be able to validate content that uses SHA256.

5.10.6 JSON Document Sharing Metadata

This section applies when the Content Creator or Content Consumer is utilizing a Document Sharing Profile for transport. This section defines the source for all required Document Sharing attributes and as many optional attributes as makes sense for implementers’ applications.

5.10.6.1 Document Sharing – DocumentEntry Metadata

The Signature Document SHALL have a compliant DocumentEntry with the following constraints:

5.10.6.1.1 XDSDocumentEntry.formatCode

The XDSDocumentEntry.formatCode SHALL be urn:ihe:iti:dsg:detached:2014 when the signature document is a Detached Signature and urn:ihe:iti:dsg:enveloping:2014 when the signature document is an Enveloping Signature. The formatCode codeSystem SHALL be 1.3.6.1.4.1.19376.1.2.3. .

5.10.6.1.2 XDSDocumentEntry.classCode

The classCode value SHALL be a value representing the high-level classification of Digital Signature type documents within the XDS Affinity Domain or Community.

5.10.6.1.3 XDSDocumentEntry.typeCode

Where policy does not define a workflow specific typeCode, the following code SHOULD be used:

Coding schema = "ASTM"

Code value = "E1762"

Code value display name = "Full Document"

5.10.6.1.4 XDSDocumentEntry.author

The author SHOULD represent the signer.

5.10.6.1.5 XDSDocumentEntry.eventCodeList

The eventCodeList SHALL contain the signature Purpose(s) from the Protected Header's "srCms signer commitments" element, using the Signature type ValueSet

5.10.6.1.6 XDSDocumentEntry.mimeType

SHALL be "application/json"

5.10.6.1.7 XDSDocumentEntry.title

SHOULD be the same as the display name for the signature purpose

5.10.6.1.8 XDSDocumentEntry.language

The language of the signature content SHALL be ‘art’ as in "artificial".

5.10.6.1.9 XDSDocumentEntry.uniqueId

SHALL use a URI format to hold the document uniqueId. For documents that do not use a URI as the uniqueId, the Affinity Domain SHOULD determine an appropriate way to encode the DocumentEntry.uniqueId. See ebRIM Representation Section 4.2.3.2.26

5.10.6.3 Document Sharing - Folder Metadata

This document content profile makes no changes to the structure of Folders.

5.10.6.4 Document Associations

When Detached Signature Option is used, the Content Creator SHALL use the "SIGNS" associationType Document Relationship to associate the signature (sourceObject) to the documents that it signs (targetObjects). See ebRIM Representation Section 4.2.2.

5.10.7 Security Considerations

See ETSI ES 201 733 and ETSI TS 119 511 specifications for risk assessment and mitigation plan on Digital Signatures. Note that Content Creators and Content Consumers SHOULD be capable of being configured to other conformance policies to support other jurisdictional policies.

5.10.7.1 Content Creator

When a Content Creator is grouped with an ATNA Secure Node or Secure Application, it SHALL create an Audit Message indicating the Signature Creation event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(113031, DCM, "Signed Manifest")
	EventActionCode	M	"C" (Create)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Creation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)

5.10.7.2 Content Consumer

When a Content Consumer is grouped with an ATNA Secure Node or Secure Application, it SHALL create an Audit Message indicating the Signature Verification event.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110007, DCM, "Report Verification")
	EventActionCode	M	"R" (Read)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV("urn:ihe:iti:dsg", "IHE Transactions", "Document Digital Signature")
Audit Source (Content Consumer) (1)
ActiveParticipant (User/System that requested Signature Validation) (0..n)
ActiveParticipant (Patient indicated in the Signature Document) (0..n)
ParticipantObjectIdentification (Digital Signature Document) (1)