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

sigD parameter SHALL be included as per 5.2.8.1 of the JAdES Specification
mID member SHALL be present and set to "http://uri.etsi.org/19182/ObjectIdByURI"
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.
ctys member SHALL be present

* Note: 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.2 of JAdES, the JWS Payload SHALL contribute as a stream of octets to the computation of JWS Signature Value

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 as well as SHA1.

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)