diff --git a/README.md b/README.md index 5238934..c666a42 100644 --- a/README.md +++ b/README.md @@ -53,7 +53,8 @@ This profile is motivated by customer requirements for Document Digital Signatur 1. [Notes about deviation from profile are not being stated in the DSGj profile.](https://github.com/IHE/ITI.DSGj/issues/13) 2. [The usage of DSGj with MHD(ITI-105) is not covered by the DSGj chapter.](https://github.com/IHE/ITI.DSGj/issues/14) 3. [DSGj does not contain guidance around homeCommunityID](https://github.com/IHE/ITI.DSGj/issues/15) -4. [Will add examples after Public-Comment](https://github.com/IHE/ITI.DSGj/issues/19) +4. [Will add examples after Public-Comment](https://github.com/IHE/ITI.DSGj/issues/19) +5. [Provision of a JSON Schema file](https://github.com/IHE/ITI.DSGj/issues/31) # Closed Issues diff --git a/Volume1/ch-37.html b/Volume1/ch-37.html index 24b2040..8f93ff2 100644 --- a/Volume1/ch-37.html +++ b/Volume1/ch-37.html @@ -173,7 +173,7 @@

37.2 DSG Actor Options

- Content Creator (Note 1) + Content Creator (Note 1) Detached Signature ITI TF-1: 37.2.1 @@ -197,6 +197,12 @@

37.2 DSG Actor Options

ITI TF-1: 37.2.3 + + JSON Submission Set Signature + + ITI TF-1: 37.2.3.1 + + JSON Enveloping Signature @@ -204,7 +210,7 @@

37.2 DSG Actor Options

- Content Consumer (Note 1) + Content Consumer (Note 1) Detached Signature ITI TF-1: 37.2.1 @@ -228,6 +234,12 @@

37.2 DSG Actor Options

ITI TF-1: 37.2.3 + + JSON Submission Set Signature + + ITI TF-1: 37.2.3.1 + + JSON Enveloping Signature @@ -313,6 +325,18 @@

37.2.3 JSON Detached Signature Option

for documents signed with a Detached Signature.

+

37.2.3.4 JSON SubmissionSet Signature Option

+

The JSON SubmissionSet Signature Option is a variant on the JSON Detached Signature Option.

+

The Content Creator shall have the ability to create a Detached Signature document that includes + reference to all the documents included in the SubmissionSet, except for the Detached Signature + document itself; and a reference to the SubmissionSet unique ID. This Detached Signature document is included in the SubmissionSet.

+

The JSON SubmissionSet Signature Option requires the use of a Document Sharing Profile.

+

+ Content Consumers that support the SubmissionSet Signature Option shall have the capability to + perform signature verification specified in + ITI TF-3: 5.10.5 + for all the documents contained within the Detached Signature. +

37.2.4 JSON Enveloping Signature Option

diff --git a/Volume3/ch-5.10.html b/Volume3/ch-5.10.html index 6f09eb1..c4d1c1d 100644 --- a/Volume3/ch-5.10.html +++ b/Volume3/ch-5.10.html @@ -176,10 +176,9 @@

5.10.3.1 Protected Header

5.10.3.1.1 "sigD" Header Parameter

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

@@ -190,8 +189,47 @@

5.10.3.2 Unprotected Header

5.10.3.3 Payload

5.10.3.4 Signature

- -

5.10.4 JSON Enveloping Signature

+ +

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 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: +

+
    +
  1. A set (n) of Documents of interest are gathered, or generated to be published
    2. +
  2. 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
    3. +
  3. + A Digital Signature document is created which includes reference of:
    4. +
      +
    1. The SubmissionSet.uniqueId is included in the IheSSId header parameter.
      2. +
    2. All of the (n) documents to be included in the SubmissionSet, other than the signature document, are listed in the manifest.
      3. +
    3. The signature document is processed according to Section 5.10.3, and thus signed.
      4. +
    + +
  4. 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.
    5. +
  5. 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.
    6. +
+
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
@@ -251,7 +289,7 @@
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

+ 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