Specification URIs

This version:

http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd01/dss-core-v2.0-csprd01.docx (Authoritative)

http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd01/dss-core-v2.0-csprd01.html

http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd01/dss-core-v2.0-csprd01.pdf

Previous version:

N/A

Latest version:

http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.docx (Authoritative)

http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.html

http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.pdf

Technical Committee:

OASIS Digital Signature Services eXtended (DSS-X) TC

Chair:

Stefan Hagen (stefan@hagen.link), Individual

Editors:

Andreas Kuehne (kuehne@trustable.de), Individual

Stefan Hagen (stefan@hagen.link), Individual

Additional artifacts:

This prose specification is one component of a Work Product that also includes:

·         JSON and XML schemas: http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd01/schema/

Related work:

This specification replaces or supersedes:

·         Digital Signature Service Core Protocols, Elements, and Bindings Version 1.0. Edited by Stefan Drees. 11 April 2007. OASIS Standard. http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html.

Declared XML namespaces:

·         http://docs.oasis-open.org/dss-x/ns/core

·         http://docs.oasis-open.org/dss-x/ns/base

Abstract:

This document defines JSON and XML based request/response protocols for signing and verifying documents and other data. It also defines a timestamp format, and a signature property for use with these protocols. Finally, it defines transport and security bindings for the protocols.

Status:

This document was last revised or approved by the OASIS Digital Signature Services eXtended (DSS-X) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x#technical.

TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/dss-x/.

This specification is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/dss-x/ipr.php).

Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.

Citation format:

When referencing this specification the following citation format should be used:

[DSS-v2.0]

Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0. Edited by Andreas Kuehne and Stefan Hagen. 29 August 2018. OASIS Committee Specification Draft 01 / Public Review Draft 01. http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd01/dss-core-v2.0-csprd01.html. Latest version: http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.html.

Copyright © OASIS Open 2018. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

1        Introduction. 10

1.1 IPR Policy. 10

1.2 Terminology. 10

1.2.1 Terms and Definitions. 10

1.2.2 Abbreviated Terms. 10

1.3 Normative References. 10

1.4 Non-Normative References. 12

1.5 Typographical Conventions. 12

1.6 DSS Overview (Non-normative) 13

2        Design Considerations. 15

2.1 Version 2.0 goal [non-normative] 15

2.2 Transforming DSS 1.0 into 2.0. 15

2.2.1 Circumventing xs:any. 15

2.2.2 Substituting the mixed Schema Attribute. 16

2.2.3 Introducing the NsPrefixMappingType Component 16

2.2.4 Imported XML schemes. 16

2.2.5 Syntax variants. 17

2.2.6 JSON Syntax Extensions. 17

2.3 Construction Principles. 17

2.3.1 Multi Syntax approach. 17

2.4 Schema Organization and Namespaces. 18

2.5 DSS Component Overview. 18

2.5.1 Schema Extensions. 19

3        Data Type Models. 21

3.1 Boolean Model 21

3.2 Integer Model 21

3.3 String Model 21

3.4 Binary Data Model 21

3.5 URI Model 21

3.6 Unique Identifier Model 21

3.7 Date and Time Model 21

3.8 Lang Model 21

4        Data Structure Models. 22

4.1 Data Structure Models defined in this document 22

4.1.1 Component NsPrefixMapping. 22

4.1.1.1 NsPrefixMapping – JSON Syntax. 22

4.1.1.2 NsPrefixMapping – XML Syntax. 22

4.1.2 Component Any. 23

4.1.2.1 Any – JSON Syntax. 23

4.1.2.2 Any – XML Syntax. 23

4.1.3 Component InternationalString. 24

4.1.3.1 InternationalString – JSON Syntax. 24

4.1.3.2 InternationalString – XML Syntax. 24

4.1.4 Component DigestInfo. 25

4.1.4.1 DigestInfo – JSON Syntax. 25

4.1.4.2 DigestInfo – XML Syntax. 26

4.1.5 Component AttachmentReference. 26

4.1.5.1 AttachmentReference – JSON Syntax. 27

4.1.5.2 AttachmentReference – XML Syntax. 27

4.1.6 Component Base64Data. 27

4.1.6.1 Base64Data – JSON Syntax. 28

4.1.6.2 Base64Data – XML Syntax. 29

4.1.7 Component Result 29

4.1.7.1 Result – JSON Syntax. 30

4.1.7.2 Result – XML Syntax. 31

4.1.8 Component OptionalInputs. 31

4.1.8.1 OptionalInputs – JSON Syntax. 32

4.1.8.2 OptionalInputs – XML Syntax. 32

4.1.9 Component OptionalOutputs. 32

4.1.9.1 OptionalOutputs – JSON Syntax. 32

4.1.9.2 OptionalOutputs – XML Syntax. 33

4.1.10 Component RequestBase. 33

4.1.10.1 RequestBase – JSON Syntax. 33

4.1.10.2 RequestBase – XML Syntax. 33

4.1.11 Component ResponseBase. 33

4.1.11.1 ResponseBase – JSON Syntax. 34

4.1.11.2 ResponseBase – XML Syntax. 35

4.2 Request/Response related data structures defined in this document 35

4.2.1 Component InputDocuments. 35

4.2.1.1 InputDocuments – JSON Syntax. 35

4.2.1.2 InputDocuments – XML Syntax. 36

4.2.2 Component DocumentBase. 37

4.2.2.1 DocumentBase – JSON Syntax. 37

4.2.2.2 DocumentBase – XML Syntax. 38

4.2.3 Component Document 38

4.2.3.1 Document – JSON Syntax. 39

4.2.3.2 Document – XML Syntax. 39

4.2.4 Component TransformedData. 40

4.2.4.1 TransformedData – JSON Syntax. 40

4.2.4.2 TransformedData – XML Syntax. 41

4.2.5 Component DocumentHash. 42

4.2.5.1 DocumentHash – JSON Syntax. 42

4.2.5.2 DocumentHash – XML Syntax. 43

4.2.6 Component SignRequest 44

4.2.6.1 SignRequest – JSON Syntax. 44

4.2.6.2 SignRequest – XML Syntax. 45

4.2.7 Component SignResponse. 45

4.2.7.1 SignResponse – JSON Syntax. 45

4.2.7.2 SignResponse – XML Syntax. 46

4.2.8 Component SignatureObject 46

4.2.8.1 SignatureObject – JSON Syntax. 47

4.2.8.2 SignatureObject – XML Syntax. 48

4.2.9 Component SignaturePtr 48

4.2.9.1 SignaturePtr – JSON Syntax. 49

4.2.9.2 SignaturePtr – XML Syntax. 49

4.2.10 Component VerifyRequest 50

4.2.10.1 VerifyRequest – JSON Syntax. 50

4.2.10.2 VerifyRequest – XML Syntax. 51

4.2.11 Component VerifyResponse. 51

4.2.11.1 VerifyResponse – JSON Syntax. 52

4.2.11.2 VerifyResponse – XML Syntax. 52

4.2.12 Component PendingRequest 53

4.2.12.1 PendingRequest – JSON Syntax. 53

4.2.12.2 PendingRequest – XML Syntax. 54

4.3 Optional data structures defined in this document 54

4.3.1 Component RequestID.. 54

4.3.1.1 RequestID – JSON Syntax. 54

4.3.1.2 RequestID – XML Syntax. 54

4.3.2 Component ResponseID.. 55

4.3.2.1 ResponseID – JSON Syntax. 55

4.3.2.2 ResponseID – XML Syntax. 55

4.3.3 Component OptionalInputsBase. 55

4.3.3.1 OptionalInputsBase – JSON Syntax. 56

4.3.3.2 OptionalInputsBase – XML Syntax. 56

4.3.4 Component OptionalInputsSign. 57

4.3.4.1 OptionalInputsSign – JSON Syntax. 58

4.3.4.2 OptionalInputsSign – XML Syntax. 60

4.3.5 Component OptionalInputsVerify. 61

4.3.5.1 OptionalInputsVerify – JSON Syntax. 62

4.3.5.2 OptionalInputsVerify – XML Syntax. 64

4.3.6 Component OptionalOutputsBase. 64

4.3.6.1 OptionalOutputsBase – JSON Syntax. 65

4.3.6.2 OptionalOutputsBase – XML Syntax. 65

4.3.7 Component OptionalOutputsSign. 66

4.3.7.1 OptionalOutputsSign – JSON Syntax. 66

4.3.7.2 OptionalOutputsSign – XML Syntax. 66

4.3.8 Component OptionalOutputsVerify. 67

4.3.8.1 OptionalOutputsVerify – JSON Syntax. 67

4.3.8.2 OptionalOutputsVerify – XML Syntax. 69

4.3.9 Component ClaimedIdentity. 70

4.3.9.1 ClaimedIdentity – JSON Syntax. 70

4.3.9.2 ClaimedIdentity – XML Syntax. 71

4.3.10 Component Schemas. 71

4.3.10.1 Schemas – JSON Syntax. 72

4.3.10.2 Schemas – XML Syntax. 72

4.3.11 Component AugmentSignatureInstruction. 73

4.3.11.1 AugmentSignatureInstruction – JSON Syntax. 73

4.3.11.2 AugmentSignatureInstruction – XML Syntax. 73

4.3.12 Component IntendedAudience. 74

4.3.12.1 IntendedAudience – JSON Syntax. 74

4.3.12.2 IntendedAudience – XML Syntax. 74

4.3.13 Component KeySelector 75

4.3.13.1 KeySelector – JSON Syntax. 75

4.3.13.2 KeySelector – XML Syntax. 76

4.3.14 Component X509Digest 76

4.3.14.1 X509Digest – JSON Syntax. 77

4.3.14.2 X509Digest – XML Syntax. 77

4.3.15 Component PropertiesHolder 77

4.3.15.1 PropertiesHolder – JSON Syntax. 78

4.3.15.2 PropertiesHolder – XML Syntax. 78

4.3.16 Component Properties. 79

4.3.16.1 Properties – JSON Syntax. 79

4.3.16.2 Properties – XML Syntax. 79

4.3.17 Component Property. 79

4.3.17.1 Property – JSON Syntax. 80

4.3.17.2 Property – XML Syntax. 80

4.3.18 Component IncludeObject 81

4.3.18.1 IncludeObject – JSON Syntax. 81

4.3.18.2 IncludeObject – XML Syntax. 82

4.3.19 Component SignaturePlacement 82

4.3.19.1 SignaturePlacement – JSON Syntax. 83

4.3.19.2 SignaturePlacement – XML Syntax. 84

4.3.20 Component DocumentWithSignature. 84

4.3.20.1 DocumentWithSignature – JSON Syntax. 85

4.3.20.2 DocumentWithSignature – XML Syntax. 85

4.3.21 Component SignedReferences. 85

4.3.21.1 SignedReferences – JSON Syntax. 86

4.3.21.2 SignedReferences – XML Syntax. 86

4.3.22 Component SignedReference. 86

4.3.22.1 SignedReference – JSON Syntax. 87

4.3.22.2 SignedReference – XML Syntax. 88

4.3.23 Component VerifyManifestResults. 88

4.3.23.1 VerifyManifestResults – JSON Syntax. 88

4.3.23.2 VerifyManifestResults – XML Syntax. 89

4.3.24 Component ManifestResult 89

4.3.24.1 ManifestResult – JSON Syntax. 89

4.3.24.2 ManifestResult – XML Syntax. 90

4.3.25 Component UseVerificationTime. 90

4.3.25.1 UseVerificationTime – JSON Syntax. 91

4.3.25.2 UseVerificationTime – XML Syntax. 91

4.3.26 Component AdditionalTimeInfo. 92

4.3.26.1 AdditionalTimeInfo – JSON Syntax. 92

4.3.26.2 AdditionalTimeInfo – XML Syntax. 93

4.3.27 Component VerificationTimeInfo. 93

4.3.27.1 VerificationTimeInfo – JSON Syntax. 94

4.3.27.2 VerificationTimeInfo – XML Syntax. 94

4.3.28 Component AdditionalKeyInfo. 95

4.3.28.1 AdditionalKeyInfo – JSON Syntax. 95

4.3.28.2 AdditionalKeyInfo – XML Syntax. 96

4.3.29 Component ProcessingDetails. 96

4.3.29.1 ProcessingDetails – JSON Syntax. 97

4.3.29.2 ProcessingDetails – XML Syntax. 98

4.3.30 Component Detail 98

4.3.30.1 Detail – JSON Syntax. 99

4.3.30.2 Detail – XML Syntax. 100

4.3.31 Component SigningTimeInfo. 100

4.3.31.1 SigningTimeInfo – JSON Syntax. 100

4.3.31.2 SigningTimeInfo – XML Syntax. 101

4.3.32 Component AugmentedSignature. 102

4.3.32.1 AugmentedSignature – JSON Syntax. 102

4.3.32.2 AugmentedSignature – XML Syntax. 103

4.3.33 Component ReturnTransformedDocument 103

4.3.33.1 ReturnTransformedDocument – JSON Syntax. 103

4.3.33.2 ReturnTransformedDocument – XML Syntax. 104

4.3.34 Component TransformedDocument 104

4.3.34.1 TransformedDocument – JSON Syntax. 104

4.3.34.2 TransformedDocument – XML Syntax. 105

4.4 Referenced Data Structure Models from other documents. 105

4.4.1 Component NameID.. 105

4.4.1.1 NameID – JSON Syntax. 106

4.4.1.2 NameID – XML Syntax. 107

4.4.2 Component Transforms. 107

4.4.2.1 Transforms – JSON Syntax. 108

4.4.2.2 Transforms – XML Syntax. 108

4.4.3 Component Transform.. 108

4.4.3.1 Transform – JSON Syntax. 109

4.4.3.2 Transform – XML Syntax. 110

4.5 Element / JSON Name Lookup Tables. 111

4.5.1 JSON Member to Element Name. 111

4.5.2 Element to Implementing JSON Member Name. 116

5        Data Processing Model for Signing. 121

5.1 Processing for XML Signatures. 121

5.1.1 Sub process ‘process references’ 121

5.1.2 Sub process ‘create XML signature’ 122

5.1.2.1 XML Signatures Variant Optional Input IncludeObject. 123

5.2 Processing for CMS Signatures. 124

5.2.1 Sub process ‘process digest’ 124

5.2.2 Sub process ‘create CMS signature’ 125

5.3 General Timestamp Processing. 126

5.3.1 Sub process ‘add Timestamp’ 126

5.3.1.1 Processing for CMS signatures time-stamping. 126

5.3.1.2 Processing for XML Timestamps on XML signatures. 127

5.3.1.3 Processing for RFC 3161 Timestamps on XML signatures. 127

6        Data Processing Model for Verification. 128

6.1 Processing for XML Signature Verification. 129

6.1.1 Sub process ‘retrieve XML signature’ 129

6.1.1.1 Multi-Signature Verification. 129

6.1.2 Sub process ‘recalculate references’ 130

6.1.3 Sub process ‘verify XML signature’ 131

6.1.3.1 Processing for RFC 3161 timestamp tokens on XML Signatures. 131

6.1.3.2 Processing for XML timestamp tokens on XML signatures. 132

6.2 Processing for CMS Signature Verification. 132

6.2.1 Sub process ‘retrieve CMS signature’ 133

6.2.2 Sub process ‘verify CMS signature’ 133

6.2.2.1 Processing for RFC 3161 Timestamp tokens on CMS Signatures. 134

6.3 General Processing. 134

6.3.1 Sub process ‘update Signature’ 134

6.3.2 Sub process ‘timestamp Signature’ 135

6.3.3 Task ‘build VerifyResponse’ 136

7        Asynchronous Processing Model 138

8        DSS Core Bindings. 139

8.1 HTTP POST Transport Binding. 139

8.2 SOAP 1.2 Transport Binding. 139

8.3 Security Bindings. 140

9        DSS-Defined Identifiers. 141

9.1 Signature Type Identifiers. 141

9.1.1 XML Signature. 141

9.1.2 XML TimeStampToken. 141

9.1.3 RFC 3161 TimeStampToken. 141

9.1.4 CMS Signature. 141

9.1.5 PGP Signature. 141

9.2 ResultMinors. 141

10      Security Considerations. 143

10.1 Well-Known Attack Vectors. 143

10.1.1 XML Parsing Vulnerabilities [non-normative] 143

10.1.2 XML Canonicalization Vulnerabilities [non-normative] 143

10.1.3 Injection Attacks [non-normative] 143

10.1.4 JSON Deserialization Through Evaluation Attacks [non-normative] 143

11      Conformance. 145

11.1 Conformance as a DSS version 2.0 document 145

11.1.1 Conformance for JSON format 145

11.1.2 Conformance for XML format 145

11.1.3 Conformance for DSS Server 145

11.1.4 Conformance for DSS Client 145

Appendix A. Acknowledgments. 146

Appendix B. Index of Components and Elements. 147

Appendix C. List of Figures. 150

Appendix D. Revision History. 151

 

1.1 IPR Policy

This specification is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/dss-x/ipr.php).

1.2 Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] and [RFC8174].

1.2.1 Terms and Definitions

For the purposes of this document no specific terms or definitions have been identified as deviating from the usual meaning in the context of XML / JSON schema, digital signatures or transport.

1.2.2 Abbreviated Terms

ASN.1   — Abstract Syntax Notation One

URI      — (IETF) Uniform Resource Identifier

XML     — (W3C) Extensible Markup Language

XSD     — (W3C) XML Schema

1.3 Normative References

[DSBXSD]               A. Kuehne, S. Hagen.  DSS 2.0 Base XML Schema.  OASIS.

[DSIGRWXSD]        A. Kuehne, S. Hagen.  DSS 2.0 adapted XMLDSig XML Schema.  OASIS.

[DSS1Async]          A. Kuehne.  Asynchronous Processing Abstract Profile. OASIS, oasis-dss-profiles-asynchronous_processing-spec-v1.0-os.html

[DSS1Core]            S. Hagen.  DSS 1.0 Core Protocols.  OASIS, oasis-dss-core-spec-v1.0-os.html.

[DSS2JSON]           A. Kuehne, S. Hagen.  DSS 2.0 Core JSON Schema.  OASIS.

[DSS2XSD]             A. Kuehne, S. Hagen.  DSS 2.0 Core XML Schema.  OASIS.

[ESIFrame]             TR 119 102 V1.2.1 Electronic Signatures and Infrastructures (ESI); The framework for standardization of signatures; Definitions and abbreviations

http://www.etsi.org/deliver/etsi_tr/119000_119099/119001/01.02.01_60/tr_119001v010201p.pdf

[RFC2119]               Bradner, S., "Key words for use in RFCs to Indicate Requirement evels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2396]              T. Berners-Lee et al.  Uniform Resource Identifiers (URI): Generic Syntax.  IETF RFC 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt.

[RFC 2440]             J. Callas, L. Donnerhacke, H. Finney, R. Thayer.  OpenPGP Message Format.  IETF RFC 2440, November 1998.
http://www.ietf.org/rfc/rfc2440.txt.

[RFC 2616]             R. Fielding et al.  Hypertext Transfer Protocol – HTTP/1.1.  IETF RFC 2616, June 1999.
http://www.ietf.org/rfc/rfc2616.txt.

[RFC 2648]             R. Moats.  A URN Namespace for IETF Documents.  IETF RFC 2648, August 1999.
http://www.ietf.org/rfc/rfc2648.txt.           

[RFC 2822]             P. Resnick.  Internet Message Format.  IETF RFC 2822, April 2001.  http://www.ietf.org/rfc/rfc2822.txt

[RFC 3161]             C. Adams, P. Cain, D. Pinkas, R. Zuccherato.  Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).  IETF RFC 3161, August 2001.
http://www.ietf.org/rfc/rfc3161.txt.

[RFC 5652]             R. Housley.  Cryptographic Message Syntax.  IETF RFC 5652, September 2009.
http://www.ietf.org/rfc/rfc5652.txt.
(Remark: As used in DSS, all implementations based upon RFC 5652 and previous releases of CMS will suffice. For the sake of simplicity the "urn:ietf:rfc:3369" is used throughout the document to indicate a CMS message as specified in RFC 5652 or RFC 3369 or any version (including PKCS #7).

[RFC8174]               Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8259]              T. Bray, Ed., Google, Inc., The JavaScript Object Notation (JSON) Data Interchange Format, ISSN: 2070-1721, December 2017.
https://tools.ietf.org/html/rfc8259.

[SAML2RWXSD]     A. Kuehne, S. Hagen.  DSS 2.0 adapted SAML 2.0  XML Schema.  OASIS.

[SOAP]                   M. Gudgin et al.  SOAP Version 1.2 Part 1: Messaging Framework.  W3C Recommendation, June 2003. 
http://www.w3.org/TR/xmlschema-1/

[SOAPAtt]              H. F. Nielsen, H. Ruellan SOAP Message Transmission Optimization Mechanism, W3C Working Group Note, 8 June 2004
http://www.w3.org/TR/soap12-af/

[SOAPMtom]          Martin Gudgin, Noah Mendelsohn SOAP 1.2 Attachment Feature, W3C Recommendation 25 January 2005
http://www.w3.org/TR/soap12-mtom/

[WS-I-Att]                Ch. Ferris, A. Karmarkar, C. K. Liu  Attachments Profile Version 1.0, The Web Services-Interoperability Organization (WS-I), 20 April 2006
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

[XML]                     Extensible Markup Language (XML) 1.0 (Fifth Edition), T. Bray, J. Paoli, M. Sperberg-McQueen, E. Maler, F. Yergeau, Editors, W3C Recommendation, November 26, 2008, http://www.w3.org/TR/2008/REC-xml-20081126/.
Latest version available at http://www.w3.org/TR/xml.

[XML-C14N]           J. Boyer.  Canonical XML Version 1.0.  W3C Recommendation, March 2001.
http://www.w3.org/TR/xml-c14n

[XML-xcl-c14n]       Exclusive XML Canonicalization Version 1.0. W3C Recommendation 18 July 2002 http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

[XML-ns]                T. Bray, D. Hollander, A. Layman.  Namespaces in XML.  W3C Recommendation, January 1999.
http://www.w3.org/TR/1999/REC-xml-names-19990114

[XML-NT-Document] http://www.w3.org/TR/2004/REC-xml-20040204/#NT-document

[XML-PROLOG]     Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, et al. Prolog and Document Type Declaration in Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 04 February 2004, http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

[xml:id]                  xml:id, Version 1.0, W3C Recommendation, 9 September 2005, http://www.w3.org/TR/xml-id/

[XMLDSIG]             D. Eastlake et al.  XML-Signature Syntax and Processing.  W3C Recommendation, February 2002.
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

[XML-Schema-1]     W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures, S. Gao, M. Sperberg-McQueen, H. Thompson, N. Mendelsohn, D. Beech, M. Maloney, Editors, W3C Recommendation, April 5, 2012,
http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/.
Latest version available at http://www.w3.org/TR/xmlschema11-1/.

[XML-Schema-2]     W3C XML Schema Definition Language (XSD) 1.1 Part 2: DatatypesW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes, D. Peterson, S. Gao, A. Malhotra, M. Sperberg-McQueen, H. Thompson, Paul V. Biron, Editors, W3C Recommendation, April 5, 2012,
http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/.
Latest version available at http://www.w3.org/TR/xmlschema11-2/.

[XPATH]                 XML Path Language (XPath) Version 1.0. W3C Recommendation 16 November 1999 http://www.w3.org/TR/xpath

1.4 Non-Normative References

[ASN.1]                   Introduction to ASN.1.
https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx

[CHPGW]                DSS Extension for Local Signature Computation Version 1.0, Working Draft for Committee Specification 04.
https://www.oasis-open.org/committees/download.php/62576/localsig-v1.0-csprd04.pdf

[ISO8601]               Data elements and interchange formats — Information interchange — Representation of dates and times, International Standard, ISO 8601:2004(E), December 1, 2004, https://www.iso.org/standard/40874.html.

[ISO639-1]              Codes for the representation of names of languages — Part 1: Alpha-2 code, International Standard, ISO 639-1:2002 (en), https://www.iso.org/obp/ui#iso:std:iso:639:-1.

[JENSEN-2009]       Meiko Jensen, Lijun Liao, and Jörg Schwenk. 2009. The curse of namespaces in the domain of XML signature. In Proceedings of the 2009 ACM workshop on Secure web services (SWS '09). ACM, New York, NY, USA, 29-36.
DOI: https://doi.org/10.1145/1655121.1655129

[RFC7049]               C. Bormann, University Bremen TZI, Concise Binary Object Representation (CBOR), ISSN: 2070-1721, October 2013.
https://tools.ietf.org/html/rfc7049

[RFC7515]              M. Jones, Microsoft, JSON Web Signature (JWS), ISSN: 2070-1721, May 2015.
https://tools.ietf.org/html/rfc7515.

1.5 Typographical Conventions

Keywords defined by this specification use this monospaced font.

Normative source code uses this paragraph style.

Text following the special symbol («) – an opening Guillemet (or French quotation mark) – within this specification identifies automatically testable requirements to aid assertion tools. Every such statement is separated from the following text with the special end symbol (») – a closing Guillemet and has been assigned a reference that follows that end symbol in one of the three patterns:

1.     [DSS-section#-local#] if it applies regardless of syntax

2.     [JDSS-section#-local#] if it applies only to JSON syntax

3.     [XDSS-section#-local#] if it applies only to XML syntax

Some sections of this specification are illustrated with non-normative examples.

Example 1: text describing an example uses this paragraph style

All examples in this document are non-normative and informative only.

Representation-specific text is indented and marked with vertical lines.

All other text is normative unless otherwise labeled e.g. like:

Non-normative Comment:

1.6 DSS Overview (Non-normative)

This specification describes two request/response protocols:

1.     signing protocol

2.     verifying protocol

Using the first protocol a client can send documents (or document hashes) to a server and receive back a signature on the documents. Using the second protocol a client can send documents (or document hashes) and a signature to a server and receive back an answer on whether the signature is valid or not.

The top-level components for the signing protocol are

·         SignRequest (see section 4.2.6) as input and

·         SignResponse (see section 4.2.7) as output.

For the verification protocol the top-level components are

·         VerifyRequest (see section 4.2.10) as ínput and

·         VerifyResponse (see section 4.2.11) as output.

 

Additionally, this version of the core includes asynchronous requests initially specified in the Asynchronous Processing Abstract Profile [DSSAsync].

The elements in which the protocols are formulated are provided in a sematic level and also in JSON and XML syntax. Provided are additional mappings from the generic to the specific entities.

These protocol operations could be useful in a variety of contexts – for example, they could allow clients to access a single corporate key for signing press releases, with centralized access control, auditing and archiving of signature requests.  They could also allow clients to create and verify signatures without the need for complex client software and security-sensitive configuration.

The signing and verifying protocols are chiefly designed to support the creation and verification of XML signatures [XMLDSIG], XML timestamps (see [DSS1Core], section 5.1), binary timestamps [RFC 3161] and CMS signatures [RFC 5652].  These protocols are intended be extensible to other types of signatures and timestamps, such as PGP signatures [RFC 2440].

It is expected that the signing and verifying protocols will be profiled to meet many different application scenarios. In anticipation of this, these protocols have only a minimal set of required elements, which deal with transferring “input documents” and signatures back and forth between client and server. The input documents to be signed or verified can be transferred in their entirety or the client can hash the documents themselves and only send the hash values to save bandwidth and protect the confidentiality of the document content.

All functionality besides transferring input documents and signatures is relegated to a framework of “optional inputs” and “optional outputs”.  This document defines a number of optional inputs and outputs.  Profiles of these protocols can pick and choose which optional inputs and outputs to support and can introduce their own optional inputs and outputs when they need functionality not anticipated by this specification.

Examples of optional inputs to the signing protocol include: what type of signature to produce, which key to sign with, who the signature is intended for, and what signed and unsigned properties to place in the signature.  Examples of optional inputs to the verifying protocol include: the time for which the client would like to know the signature’s validity status, additional validation data necessary to verify the signature (such as certificates and CRLs), and requests for the server to return information such as the signer’s name or the signing time.

The signing and verifying protocol messages must be transferred over some underlying protocol(s) which provide message transport and security.  A binding specifies how to use the signing and verifying protocols with some underlying protocol such as HTTP POST or TLS. Section 7 Asynchronous Processing Model provides an initial set of bindings.

The previous version of specification ([DSS1Core]) defines two elements that are related to these protocols.  First, an XML timestamp element is defined in [DSS1Core], section 5.1.  The signing and verifying protocols can be used to create and verify both XML and binary timestamps; a profile for doing so is defined in [XML-TSP].  Second, a RequesterIdentity element is defined in (see [DSS1Core], section 5.2).  This element can be used as a signature property in an XML signature, to give the name of the end-user who requested the signature. These elements remain unchanged and are not repeated in this specification.

2.1 Version 2.0 goal [non-normative]

The main changes of this version of the DSS/X core document compared to version 1.0 are:

·         Considering the set of comments and bug reports arrived since version DSS 1.0 became standard

·         Inclusion of requirements that became known only after publication of version 1.0

·         Simplification of the core schema, e.g. by dropping elements seldom used

·         Support for syntaxes other than XML

·         Support transport formats other than SOAP

·         Integration of the ‘Asynchronous Processing Profile’ [DSSAsync] into the core

Define a sematic model that can be mapped to different syntaxes. In this document the focus is on XML and JSON, but support for other syntaxes should be possible. Therefore, only the common denominator of syntax features can be used:

·         Focus on Base64 as the most versatile way to transport documents and signatures

·         Avoid the use of XML specifics (like e.g. mixed content)

·         Provide namespace / URI for XPath evaluation explicitly

·         Avoid xs:any by replacing it with an enumeration of possible types, and if that is not feasible, use base64 blobs as a fallback

To support implementers and to ease the use of the protocol with common frameworks the following list of requirements was compiled:

·         One unique object model for all transport syntaxes

·         Define type and cardinality of OptionalInputs and OptionalOutputs child elements explicitly

·         Rearrange sequences and choices to produce a strongly typed object model

Regardless of the use of JSON as a transport syntax the handling of JSON signatures will not be covered by this document. Specific profiles will address signatures e.g. conformant to [RFC7515].

The provided schemes of DSS-X version 2 reflect these requirements. The XML schemes of version 1 and 2 share many similarities but are not compatible.

2.2 Transforming DSS 1.0 into 2.0

This section describes the several actions taken to fulfil the goals listed in the previous section.

2.2.1 Circumventing xs:any

The XML schema type ‘any’ allows an object to contain arbitrary structures. This comes handy for writers of specifications as an extension point because the structures transported don’t need to be defined upfront. But this advantage at the specification stage comes with a price at the implementation stage. The structures intended to be supported by a client or a server system MUST be known to be implementable. But the usual tools for schema support leave the task of handling the content of an any type to the developer. Without extensive testing problems with unexpected content may occur at runtime, even while using typed languages.

As a successor of the OptionalInputs element (see section 2.7 of version 1.0 of this document) the component OptionalInputsVerify (see section 4.3.5) defines its child elements and their cardinality explicitly. When using additional profiles, the relevant components of the core schema can be redefined using the XML schema’s ‘redefine’ element or JSON schema’s ‘allOf’ as described in section 2.5.1 .

Another usage scenario for ‘xs:any’ is the transport of unknown data objects. As sample use case is the Property component (see section 4.3.17). This component is intended to contain signature attributes of unknown structure. In this version of the specification the ‘xs:any’ type is replaced by a structure containing base64-encoded data and meta data (component Any, see section 4.1.2). When using XML as the transport syntax this seems to be a disadvantage. But direct XML fragment copying may introduce namespace problems and security concerns. Most importantly the cherry-picking of transport syntax features would inhibit a transport independent object model, both on the client and the server side. More complex programming and testing would be inevitable.

2.2.2 Substituting the mixed Schema Attribute

Mixing sub-elements and text within a single element is a great advantage of XML. But when XML is applied for serializing an object model this ‘markup language’ feature is of little use. Other serialization syntaxes (like JSON) don’t support such a feature. There is the need to substitute the ‘mixed’ construct to become syntax independent. The substitution is done by removing the mixed attribute and introduce an additional ‘value’ element to contain the textual content.

2.2.3 Introducing the NsPrefixMappingType Component

Namespaces are an outstanding feature of the XML world. A replacement is required for all syntaxes that don’t such a feature. The use of naming conventions and prefixes are used to avoid naming collisions. A special challenge is the use of XPath-Expression as elements. The XPath expression itself is represented as a simple string. But the expression may depend on namespace/prefix mappings that are defined within the namespace context of the XML element. The NsPrefixMappingType component (see section 4.1.1) represents the required namespace/prefix mapping. It is recommended to use this element for XML syntax, too. This simplifies the handling on the consumer side and circumvents problems with namespace prefix assignments handled by web frameworks.

2.2.4 Imported XML schemes

A special challenge is imposed by the imported schemes, like the [XMLDSIG] scheme, that uses features not supportable by the mentioned ‘multi-syntax’ approach. For example, the [XMLDSIG] type ‘Transform’ is defined like this:

 Most of the restrictions listed above do apply here:

·         The complexType may contain mixed content (child elements and text). This concept is not supported by JSON. The workaround for this limitation is to drop the ‘mixed’ attribute and to introduce a ‘value’ element.

·         The choice construct is mapped in an untyped way by Java’s JAXB framework. Therefore, the choice element is changed to a sequence.

·         The any type is replaced by a base64 encoded blob.

·         The option to provide arbitrary namespace / prefix mappings to support the evaluation of XPath expression is not available in e.g. JSON syntax. Therefore an element mapping prefixes to namespaces (of type dsb:NsPrefixMappingType) is added.

To apply the necessary changes to the imported schemes the XML schema language provides the override functionality to change existing schemes. But Java’s JAXB framework’s schema compiler does not support override so the adapted schemes are provided alongside DSS-X core schemes.

2.2.5 Syntax variants

This version of the DSS/X core document handles the representation of requests and response elements according to the JSON and XML syntax. The general semantics of the elements is discussed in the element’s main section. Details of the JSON or XML formats are discussed in specific subsections

·         Component – JSON Syntax

·         Component – XML Syntax

2.2.6 JSON Syntax Extensions

JSON, as described in [RFC8259], defines a text format for serializing structured data. Objects are serialized as an unordered collection of name/value pairs.

JSON does not define any semantics around the name/value pairs that make up an object, nor does it define an extensibility mechanism for adding control information to a payload.

DSS’s JSON format extends JSON by defining general conventions for name/value pairs that annotate a JSON object, property or array. DSS defines a set of canonical annotations for control information such as ids, types, and links, and custom annotations MAY be used to add domain-specific information to the payload.

Annotations are used in JSON to capture control information that cannot be predicted as well as a mechanism to provide values where a computed value would be wrong.

2.3 Construction Principles

2.3.1 Multi Syntax approach

In the years since DSS 1.0 became standard many other formats (like JSON) became popular for data interchange. Nevertheless, XML is still an important and commonly used format. To support these developments DSS 2.0 is taking a multi-syntax approach:

·         For each structural component there is semantic section describing the elements, restrictions and relations to other components in a syntax-neutral way.

·         Following the sematic definition there are syntax-specific sections describing the mapping of the given requirements to XML and JSON.

·         Schemes are provided for XML and JSON.

·         Element name mappings are given for JSON.

Subsequent versions of this protocol may define additional syntax mappings, e.g. for ASN.1 or CBOR.

The restriction of this approach is limitation to the common denominator of capabilities of the used transfer formats. The section ‘Transforming DSS 1.0 into 2.0’ targets these limitations. The imported schema files defined by other parties are also affected. An example is the ‘Component Transform’, that was originally defined in [XMLDSIG] and the aspects described in 2.2.1 Circumventing xs:any, 2.2.2 Substituting the mixed Schema Attribute and 2.2.3 Introducing the NsPrefixMappingType Component apply.

2.4 Schema Organization and Namespaces

The structures described in this specification are contained in the schema file [Core2.0-XSD].  All schema listings in the current document are excerpts from the schema file.  In the case of a disagreement between the schema file and this document, the schema file shall take precedence.

This schema is associated with the following XML namespace

and

If a future version of this specification is needed, it will use a different namespace.

Conventional XML namespace prefixes are used in the schema:

• The prefix dss2: stands for the DSS core version 2.0 namespace [DSS2XSD].refDSS2XSD
• The prefix dsb: stands for the DSS base namespace [DSBXSD].refDSS2XSD
• The prefix ds-rw: stands for a namespace of elements based on the W3C XML Signature [XMLDSIG].
• The prefix xs: stands for the W3C XML Schema namespace [Schema1].
• The prefix saml2-rw: stands for a namespace of elements based on the OASIS SAML 2 Schema namespace [SAMLCore2.0].

Applications MAY use different namespace prefixes, and MAY use whatever namespace defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML specification [XML-ns].

The following schema fragment defines the XML namespaces and other header information for the DSS core schema:

2.5 DSS Component Overview

The DSS core is designed to be extended by profiles to support additional functionalities. The DSS specification comes with a set of profiles (see https://www.oasis-open.org/standards#dssv1.0). With version 2.0 there will be extensions to augment the use cases beyond the sign and verify scope of the previous version. The extensions will define other requests and responses while using e.g. the ResultType. A sample for an extension is the ChipGateway Protocol (c.f. clause 3.4 of [CHPGW]). To support this approach, the DSS 2.0 schema is split into a generic ‘base’ and the more specific ‘core’ schema.

Figure 1:Component overview

The diagram above shows the relationship between the different building blocks.

2.5.1 Schema Extensions

Most profiles define additional OptionalInputs or OptionalOutputs. To support a type-safe extension of the set of optional elements it is recommended to use the XML schema redefine mechanism to extend the core schema and derive the related JSON schema from it:

The snippet above extends the set of sub-components of OptionalOutputsVerifyType with the group of elements of the profile.

In a similar way extension of the core’s JSON scheme can be performed by using the ‘allOf’ keyword:

With this mechanism it is possible to extend the core schema to specific requirements while preserving the advantage of type safety and tool / IDE support. This sample illustrates the use of ‘extension’. in the same way restriction can be applied. In more complex scenarios (e.g. multiple profiles apply, need for extending and restriction the core schema) the use of other techniques (e.g. XSLT) may be required.

It may be useful to process a profile (or a set of profiles) using a distinct endpoint. This enables the server instance to provide a specific WSDL including an appropriate schema with all profile-related elements.

3.1 Boolean Model

The boolean data type is used to specify a true or false

3.2 Integer Model

The integer data type is used to specify a numeric value without a fractional component.

3.3 String Model

The string data type can represent characters, line feeds, carriage returns, and tab characters.

3.4 Binary Data Model

The base64Binary type holds Base64-encoded binary data

3.5 URI Model

Uniform Resource Identifier (URI) is a string of characters used to identify a resource

3.6 Unique Identifier Model

A unique identifier is a numeric or alphanumeric string that is associated with a single entity within a given system.

3.7 Date and Time Model

The specific concept of date and time used in this document is defined in this section and noted in subsequent usage as:

DateTime

« All date time values inside a DSS document MUST adhere to the ISO 8601 [ISO8601] basic or extended Format (as given there in section 4.3.2 “Complete representations” and with the addition of decimal fractions for seconds, similar to ibid. section 4.2.2.4 “Representations with decimal fraction” but with the full stop (.) being the preferred separator for DSS). » [DSS-3.7-1].

3.8 Lang Model

The specific concept of language used in this document is defined in this section and noted in subsequent usage as:

Language

« All language values inside a DSS document MUST adhere to the ISO 639-1 [ISO639-1] format (as given there in section 4 “Two-letter language code”. » [DSS-3.8-1].

4.1 Data Structure Models defined in this document

The XML elements of this section are defined in the XML namespace:

http://docs.oasis-open.org/dss-x/ns/base

4.1.1 Component NsPrefixMapping

The NsPrefixMapping component defines the mapping of namespace URIs to namespace prefixes. This is required to evaluate XPath expression when using transport syntaxes that don’t support namespace.

Below follows a list of the sub-components that MAY be present within this component:

4.1.1.1 NsPrefixMapping – JSON Syntax

« The NsPrefixMappingType JSON object SHALL implement in JSON syntax the requirements defined in the NsPrefixMapping component. » [JDSS-4.1.1.1-1].

« Properties of the JSON object SHALL implement the sub-components of NsPrefixMapping using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
NamespaceURI	uri
NamespacePrefix	pre

 » [JDSS-4.1.1.1-2]. The NsPrefixMappingType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.1.2 NsPrefixMapping – XML Syntax

« The XML type NsPrefixMappingType SHALL implement the requirements defined in the NsPrefixMapping component. » [XDSS-4.1.1.2-1].

The NsPrefixMappingType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of NsPrefixMappingType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.1.2-2].

4.1.2 Component Any

« This element SHALL hold a set of base64 encoded arbitrary data if it is present. » [DSS-4.1.2-1]. To help the processing of the data it can be further qualified by the mime type element.

Below follows a list of the sub-components that are allowed to be present within this component:

A set of sub-components is inherited from component 4.1.6 and is not repeated here.

Non-normative Comment:

4.1.2.1 Any – JSON Syntax

« The AnyType JSON object SHALL implement in JSON syntax the requirements defined in the Any component. » [JDSS-4.1.2.1-1].

The AnyType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.2.2 Any – XML Syntax

« The XML type AnyType SHALL implement the requirements defined in the Any component. 
» [XDSS-4.1.2.2-1].

The AnyType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of AnyType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.2.2-2].

4.1.3 Component InternationalString

This element attaches an element to a human-readable string to specify the string’s language.

Below follows a list of the sub-components that are allowed to be present within this component:

4.1.3.1 InternationalString – JSON Syntax

« The InternationalStringType JSON object SHALL implement in JSON syntax the requirements defined in the InternationalString component. » [JDSS-4.1.3.1-1].

« Properties of the JSON object SHALL implement the sub-components of InternationalString using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
value	value
lang	lang

 » [JDSS-4.1.3.1-2]. The InternationalStringType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.3.2 InternationalString – XML Syntax

« The XML type InternationalStringType SHALL implement the requirements defined in the InternationalString component. » [XDSS-4.1.3.2-1].

The InternationalStringType XML element is defined in XML Schema [DSBXSD] and is copied below a service for the reader.

« Each child element of InternationalStringType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.3.2-2].  The element 'value' is represented by the component's XML tag text content.

4.1.4 Component DigestInfo

The DigestInfo component holds a digest value and an identification of the used digest algorithm. The DigestMethod isn’t strongly typed intentionally to support a broad variety of identifiers.

Below follows a list of the sub-components that are allowed to be present within this component:

4.1.4.1 DigestInfo – JSON Syntax

« The DigestInfoType JSON object SHALL implement in JSON syntax the requirements defined in the DigestInfo component. » [JDSS-4.1.4.1-1].

« Properties of the JSON object SHALL implement the sub-components of DigestInfo using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
DigestMethod	alg
DigestValue	val

 » [JDSS-4.1.4.1-2]. The DigestInfoType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.4.2 DigestInfo – XML Syntax

« The XML type DigestInfoType SHALL implement the requirements defined in the DigestInfo component. » [XDSS-4.1.4.2-1].

The DigestInfoType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of DigestInfoType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.4.2-2].

4.1.5 Component AttachmentReference

Applications MAY support SOAP 1.2 attachment feature [SOAPAtt] or other attachment specifications (e.g. [SOAPMtom]) to transmit documents.

Below follows a list of the sub-components that MAY be present within this component:

4.1.5.1 AttachmentReference – JSON Syntax

« The AttachmentReferenceType JSON object SHALL implement in JSON syntax the requirements defined in the AttachmentReference component. » [JDSS-4.1.5.1-1]

« Properties of the JSON object SHALL implement the sub-components of AttachmentReference using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
DigestInfo	di
AttRefURI	attURI

 » [JDSS-4.1.5.1-2] The AttachmentReferenceType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.5.2 AttachmentReference – XML Syntax

« The XML type AttachmentReferenceType SHALL implement the requirements defined in the AttachmentReference component. » [XDSS-4.1.5.2-1]

The AttachmentReferenceType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of AttachmentReferenceType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.5.2-2]

4.1.6 Component Base64Data

The Base64Data component is a generic holder for arbitrary data. In addition to the data itself it also contains additional elements to qualify the MimeType of the data. It also offers an Id / Reference pair to implement a deduplication strategy, useful especially for bigger data blobs. The content is contained inside the mutually exclusive elements Value or AttRefURI.

Below follows a list of the sub-components that MAY be present within this component:

Non-normative Comment:

4.1.6.1 Base64Data – JSON Syntax

« The Base64DataType JSON object SHALL implement in JSON syntax the requirements defined in the Base64Data component. » [JDSS-4.1.6.1-1]

« Properties of the JSON object SHALL implement the sub-components of Base64Data using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Value	val
AttRef	attRef
MimeType	mimeType
Id	ID
IdRef	idRef

 » [JDSS-4.1.6.1-2] The Base64DataType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.6.2 Base64Data – XML Syntax

« The XML type Base64DataType SHALL implement the requirements defined in the Base64Data component. » [XDSS-4.1.6.2-1]

The Base64DataType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of Base64DataType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.6.2-2]

4.1.7 Component Result

The Result element is returned with every response message.

Below follows a list of the sub-components that MAY be present within this component:

4.1.7.1 Result – JSON Syntax

« The ResultType JSON object SHALL implement in JSON syntax the requirements defined in the Result component. » [JDSS-4.1.7.1-1]

« Properties of the JSON object SHALL implement the sub-components of Result using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
ResultMajor	maj
ResultMinor	min
ResultMessage	msg
ProblemReference	pRef

 » [JDSS-4.1.7.1-2] The ResultType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.7.2 Result – XML Syntax

« The XML type ResultType SHALL implement the requirements defined in the Result component. » [XDSS-4.1.7.2-1]

The ResultType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of ResultType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.7.2-2]

4.1.8 Component OptionalInputs

Non-normative Comment:

Below follows a list of the sub-components that MAY be present within this component:

4.1.8.1 OptionalInputs – JSON Syntax

The component OptionalInputs is used as a base type only, not as a JSON instance.

4.1.8.2 OptionalInputs – XML Syntax

« The XML type OptionalInputsType SHALL implement the requirements defined in the OptionalInputs component. » [XDSS-4.1.8.2-1]

The OptionalInputsType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of OptionalInputsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.8.2-2]

4.1.9 Component OptionalOutputs

Below follows a list of the sub-components that MAY be present within this component:

4.1.9.1 OptionalOutputs – JSON Syntax

The component OptionalOutputs is used as a base type only, not as a JSON instance.

4.1.9.2 OptionalOutputs – XML Syntax

« The XML type OptionalOutputsType SHALL implement the requirements defined in the OptionalOutputs component. » [XDSS-4.1.9.2-1]

The OptionalOutputsType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of OptionalOutputsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.9.2-2]

4.1.10 Component RequestBase

The RequestBase component is the base structure for request elements defined by the core protocol or profiles.

Below follows a list of the sub-components that MAY be present within this component:

4.1.10.1 RequestBase – JSON Syntax

The component RequestBase is abstract and therefore has no JSON definition.

4.1.10.2 RequestBase – XML Syntax

« The XML type RequestBaseType SHALL implement the requirements defined in the RequestBase component. » [XDSS-4.1.10.2-1]

The RequestBaseType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of RequestBaseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.10.2-1]

4.1.11 Component ResponseBase

The ResponseBase component is the base structure for response elements defined by the core protocol or profiles.

Below follows a list of the sub-components that MAY be present within this component:

4.1.11.1 ResponseBase – JSON Syntax

« The ResponseBaseType JSON object SHALL implement in JSON syntax the requirements defined in the ResponseBase component. » [JDSS-4.1.11.1-1]

« Properties of the JSON object SHALL implement the sub-components of ResponseBase using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Result	result
AppliedProfile	profile
RequestID	reqID
ResponseID	respID

 » [JDSS-4.1.11.1-2] The ResponseBaseType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.1.11.2 ResponseBase – XML Syntax

« The XML type ResponseBaseType SHALL implement the requirements defined in the ResponseBase component. » [XDSS-4.1.11.2-1]

The ResponseBaseType XML element is defined in XML Schema [DSBXSD] and is provided below as a service to the reader.

« Each child element of ResponseBaseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.1.11.2-2]

4.2 Request/Response related data structures defined in this document

The XML elements of this section are defined in the XML namespace:

http://docs.oasis-open.org/dss-x/ns/core

4.2.1 Component InputDocuments

This element is used to send input documents to a DSS server, whether for signing or verifying. An input document can be any piece of data that can be used as input to a signature or timestamp calculation. An input document can even be a signature or timestamp (for example, a pre-existing signature can be counter-signed or timestamped). An input document can also be a <ds:Manifest>, allowing the client to handle manifest creation while using the server to create the rest of the signature. Manifest validation is supported by an optional input / output.

Below follows a list of the sub-components that MAY be present within this component:

4.2.1.1 InputDocuments – JSON Syntax

« The InputDocumentsType JSON object SHALL implement in JSON syntax the requirements defined in the InputDocuments component. » [JDSS-4.2.1.1-1]

« Properties of the JSON object SHALL implement the sub-components of InputDocuments using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Document	doc
TransformedData	transformed
DocumentHash	docHash

 » [JDSS-4.2.1.1-2]

The InputDocumentsType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.1.2 InputDocuments – XML Syntax

« The XML type InputDocumentsType SHALL implement the requirements defined in the InputDocuments component. » [XDSS-4.2.1.2-1]

The InputDocumentsType XML element is defined in XML Schema [DSS2XSD] and is copied below as a service for the reader.

« Each child element of InputDocumentsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name.   » [XDSS-4.2.1.2-2]

4.2.2 Component DocumentBase

The DocumentBaseType forwards its elements to the components DocumentType, TransformedDataType and DocumentHashType. The DocumentBaseType contains the basic information shared by the inheriting components and remaining persistent during the process from input document retrieval until digest calculation for the relevant document.

Below follows a list of the sub-components that MAY be present within this component:

Non-normative Comment:

4.2.2.1 DocumentBase – JSON Syntax

« The DocumentBaseType JSON object SHALL implement in JSON syntax the requirements defined in the DocumentBase component. » [JDSS-4.2.2.1-1]

« Properties of the JSON object SHALL implement the sub-components of DocumentBase using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Id	ID
RefURI	refURI
RefType	refType
SchemaRefs	schemaRefs

 » [JDSS-4.2.2.1-2]

The DocumentBaseType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.2.2 DocumentBase – XML Syntax

« The XML type DocumentBaseType SHALL implement the requirements defined in the DocumentBase component. » [XDSS-4.2.2.2-1]

The DocumentBaseType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of DocumentBaseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.2.2-2]

4.2.3 Component Document

The Document component contains input data for DSS processing.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.2.2 and is not repeated here.

4.2.3.1 Document – JSON Syntax

« The DocumentType JSON object SHALL implement in JSON syntax the requirements defined in the Document component. » [JDSS-4.2.3.1-1]

« Properties of the JSON object SHALL implement the sub-components of Document using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Base64Data	b64Data

 » [JDSS-4.2.3.1-2]

The DocumentType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.3.2 Document – XML Syntax

« The XML type DocumentType SHALL implement the requirements defined in the Document component. » [XDSS-4.2.3.2-1]

The DocumentType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of DocumentType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.3.2-2]

4.2.4 Component TransformedData

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.2.2 and is not repeated here.

Non-normative Comment:

4.2.4.1 TransformedData – JSON Syntax

« The TransformedDataType JSON object SHALL implement in JSON syntax the requirements defined in the TransformedData component. » [JDSS-4.2.4.1-1]

« Properties of the JSON object SHALL implement the sub-components of TransformedData using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Transforms	transforms
Base64Data	b64Data
WhichReference	whichRef

 » [JDSS-4.2.4.1-2]

The TransformedDataType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.4.2 TransformedData – XML Syntax

« The XML type TransformedDataType SHALL implement the requirements defined in the TransformedData component. » [XDSS-4.2.4.2-1]

The TransformedDataType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of TransformedDataType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.4.2-2]

4.2.5 Component DocumentHash

The DocumentHash component represents a document that will not be transported to the server but just the calculated digest of it. This is intended to limit the amount of data transferred or to ensure privacy of the document.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.2.2 and is not repeated here.

4.2.5.1 DocumentHash – JSON Syntax

« The DocumentHashType JSON object SHALL implement in JSON syntax the requirements defined in the DocumentHash component. » [JDSS-4.2.5.1-1]

« Properties of the JSON object SHALL implement the sub-components of DocumentHash using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Transforms	transforms
DigestInfos	di
WhichReference	whichRef

 » [JDSS-4.2.5.1-2]

The DocumentHashType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.5.2 DocumentHash – XML Syntax

« The XML type DocumentHashType SHALL implement the requirements defined in the DocumentHash component. » [XDSS-4.2.5.2-1]

The DocumentHashType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of DocumentHashType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [JDSS-4.2.5.2-2]

4.2.6 Component SignRequest

The SignRequest component is sent by the client to request a signature or timestamp on some input documents.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.10 and is not repeated here.

4.2.6.1 SignRequest – JSON Syntax

« The SignRequestType JSON object SHALL implement in JSON syntax the requirements defined in the SignRequest component. » [JDSS-4.2.6.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignRequest using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
InputDocuments	inDocs
OptionalInputs	optInp

 » [JDSS-4.2.6.1-2]

The SignRequestType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.6.2 SignRequest – XML Syntax

« The XML type SignRequestType SHALL implement the requirements defined in the SignRequest component. » [XDSS-4.2.6.2-1]

The SignRequestType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignRequestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.6.2-2]

4.2.7 Component SignResponse

The SignResponse component returns the requested signature or timestamp to the requestor.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.11 and is not repeated here.

4.2.7.1 SignResponse – JSON Syntax

« The SignResponseType JSON object SHALL implement in JSON syntax the requirements defined in the SignResponse component. » [JDSS-4.2.7.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignResponse using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
OptionalOutputs	optOutp
SignatureObject	sigObj

 » [JDSS-4.2.7.1-2]

The SignResponseType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.7.2 SignResponse – XML Syntax

« The XML type SignResponseType SHALL implement the requirements defined in the SignResponse component. » [XDSS-4.2.7.2-1]

The SignResponseType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignResponseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.7.2-2]

4.2.8 Component SignatureObject

The SignatureObject component contains a signature or timestamp of some sort. This element is returned in a sign response message and sent in a verify request message.

Below follows a list of the sub-components that MAY be present within this component:

4.2.8.1 SignatureObject – JSON Syntax

« The SignatureObjectType JSON object SHALL implement in JSON syntax the requirements defined in the SignatureObject component. » [JDSS-4.2.8.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignatureObject using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Base64Signature	b64Sig
SignaturePtr	sigPtr
SchemaRefs	schemaRefs

 » [JDSS-4.2.8.1-2]

The SignatureObjectType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.8.2 SignatureObject – XML Syntax

« The XML type SignatureObjectType SHALL implement the requirements defined in the SignatureObject component. » [XDSS-4.2.8.2-1]

The SignatureObjectType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignatureObjectType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.8.2-2]

4.2.9 Component SignaturePtr

Non-normative Comment:

The SignaturePtr component is used to point to a signature in an input (for a verify request) or output (for a sign response) document in which a signature is enveloped.

Below follows a list of the sub-components that MAY be present within this component:

4.2.9.1 SignaturePtr – JSON Syntax

« The SignaturePtrType JSON object SHALL implement in JSON syntax the requirements defined in the SignaturePtr component. » [JDSS-4.2.9.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignaturePtr using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
NsPrefixMapping	nsDecl
WhichDocument	whichDoc
XPath	xPath

 » [JDSS-4.2.9.1-2]

The SignaturePtrType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.9.2 SignaturePtr – XML Syntax

« The XML type SignaturePtrType SHALL implement the requirements defined in the SignaturePtr component. » [XDSS-4.2.9.2-1]

The SignaturePtrType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignaturePtrType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.9.2-2]

4.2.10 Component VerifyRequest

The VerifyRequest component is sent by the client to verify a signature or timestamp on some input documents.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.10 and is not repeated here.

4.2.10.1 VerifyRequest – JSON Syntax

« The VerifyRequestType JSON object SHALL implement in JSON syntax the requirements defined in the VerifyRequest component. » [JDSS-4.2.10.1-1]

« Properties of the JSON object SHALL implement the sub-components of VerifyRequest using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
InputDocuments	inDocs
OptionalInputs	optInp
SignatureObject	sigObj

 » [JDSS-4.2.10.1-2]

The VerifyRequestType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.10.2 VerifyRequest – XML Syntax

« The XML type VerifyRequestType SHALL implement the requirements defined in the VerifyRequest component. » [XDSS-4.2.10.2-1]

The VerifyRequestType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of VerifyRequestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.10-2]

4.2.11 Component VerifyResponse

The VerifyResponse component is returned by the server to provide the results of verification.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.11 and is not repeated here.

4.2.11.1 VerifyResponse – JSON Syntax

« The VerifyResponseType JSON object SHALL implement in JSON syntax the requirements defined in the VerifyResponse component. » [JDSS-4.2.11.1-1]

« Properties of the JSON object SHALL implement the sub-components of VerifyResponse using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
OptionalOutputs	optOutp

 » [JDSS-4.2.11.1-2]

The VerifyResponseType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.11.2 VerifyResponse – XML Syntax

« The XML type VerifyResponseType SHALL implement the requirements defined in the VerifyResponse component. » [XDSS-4.2.11.2-1]

The VerifyResponseType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of VerifyResponseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.11.2-2]

4.2.12 Component PendingRequest

The PendingRequest component is sent by the client to retrieve the result of a previous request.

« The client MUST provide the ResponseID received with the initial response. » [DSS-4.2.12-1]

« The Profile element MUST NOT be present as the profile selection was done with the initial request. » [DSS-4.2.12-2]

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.10 and is not repeated here.

4.2.12.1 PendingRequest – JSON Syntax

« The PendingRequestType JSON object SHALL implement in JSON syntax the requirements defined in the PendingRequest component. » [JDSS-4.2.12.1-1]

« Properties of the JSON object SHALL implement the sub-components of PendingRequest using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
ClaimedIdentity	claimedIdentity

 » [JDSS-4.2.12.1-2]

The PendingRequestType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.2.12.2 PendingRequest – XML Syntax

« The XML type PendingRequestType SHALL implement the requirements defined in the PendingRequest component. » [XDSS-4.2.12.2-1]

The PendingRequestType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of PendingRequestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.2.12.2-2]

4.3 Optional data structures defined in this document

The XML elements of this section are defined in the XML namespace:

http://docs.oasis-open.org/dss-x/ns/core

4.3.1 Component RequestID

Below follows a list of the sub-components that MAY be present within this component:

4.3.1.1 RequestID – JSON Syntax

The component RequestID is derived from the string type.

4.3.1.2 RequestID – XML Syntax

« The XML type RequestID SHALL implement the requirements defined in the RequestID component. » [XDSS-4.3.1.2-1]

The RequestID XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of RequestID XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.1.2-2]

4.3.2 Component ResponseID

Below follows a list of the sub-components that MAY be present within this component:

4.3.2.1 ResponseID – JSON Syntax

The component ResponseID is derived from the string type.

4.3.2.2 ResponseID – XML Syntax

« The XML type ResponseID SHALL implement the requirements defined in the ResponseID component.

 » [XDSS-4.3.2.2-1]

The ResponseID XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of ResponseID XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.2.2-2]

4.3.3 Component OptionalInputsBase

Non-normative Comment:

The OptionalInputsBase contains a common set of additional inputs associated with the processing of the request. Profiles will specify the allowed optional inputs and their default values. « If a server doesn’t recognize or can’t handle any optional input, it MUST reject the request with a ResultMajor code of RequesterError and a ResultMinor code of NotSupported. » [DSS-4.3.3-1]

All request messages can contain an OptionalInputSign or OptionalInputVerify element depending on the method called. The OptionalInputsBase component defines the elements that are common to all optional inputs defined in this document. Several optional inputs are defined in this document, and profiles can define additional ones.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.8 and is not repeated here.

4.3.3.1 OptionalInputsBase – JSON Syntax

The component OptionalInputsBase is abstract and therefore has no JSON definition.

4.3.3.2 OptionalInputsBase – XML Syntax

« The XML type OptionalInputsBaseType SHALL implement the requirements defined in the OptionalInputsBase component. » [XDSS-4.3.3.2-1]

The OptionalInputsBaseType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalInputsBaseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.3.2-2]

4.3.4 Component OptionalInputsSign

Non-normative Comment:

The OptionalInputsSign component defines a set of additional inputs associated with the processing of a signing request. The OptionalInputsSign component contains additional inputs associated with the processing of a signing request. Profiles MAY specify the allowed optional inputs and their default values. The definition of an optional input MAY include a default value, so that a client may omit the OptionalInputsSign yet still get service from any profile-compliant DSS server. « If a server doesn’t recognize or can’t handle any optional input, it MUST reject the request with a ResultMajor code of RequesterError and a ResultMinor code of NotSupported.» [DSS-4.3.4-1]

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.3.3 and is not repeated here.

4.3.4.1 OptionalInputsSign – JSON Syntax

« The OptionalInputsSignType JSON object SHALL implement in JSON syntax the requirements defined in the OptionalInputsSign component. » [JDSS-4.3.4.1-1]

« Properties of the JSON object SHALL implement the sub-components of OptionalInputsSign using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
SignatureType	sigType
IntendedAudience	aud
KeySelector	keySel
Properties	props
IncludeObject	incObj
IncludeEContent	incContent
SignaturePlacement	sigPlacement
SignedReferences	sigRefs
Nonce	nonce
SignatureAlgorithm	sigAlgo
SignatureQualityLevel	quality

 » [JDSS-4.3.4.1-2]

The OptionalInputsSignType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.4.2 OptionalInputsSign – XML Syntax

« The XML type OptionalInputsSignType SHALL implement the requirements defined in the OptionalInputsSign component. » [XDSS-4.3.4.2-1]

The OptionalInputsSignType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalInputsSignType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.4.2-2]

4.3.5 Component OptionalInputsVerify

Note, that the prescribed font family renders a lowercase letter L and an uppercase letter i nearly the same. So, for clarity it is stated here, that the component described in this section is the combination of the three words Optional, Inputs and Verify.

The OptionalInputsVerify component defines a set of additional inputs associated with the processing of a verification request. Profiles MAY specify the allowed optional inputs and their default values. The definition of an optional input MAY include a default value, so that a client may omit the OptionalInputsVerify yet still get service from any profile-compliant DSS server. « If a server doesn’t recognize or can’t handle any optional input, the server MUST reject the request with a ResultMajor code of RequesterError and a ResultMinor code of NotSupported. » [DSS-4.3.5-1]

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.3.3 and is not repeated here.

4.3.5.1 OptionalInputsVerify – JSON Syntax

« The OptionalInputsVerifyType JSON object SHALL implement in JSON syntax the requirements defined in the OptionalInputsVerify component. » [JDSS-4.3.5.1-1]

« Properties of the JSON object SHALL implement the sub-components of OptionalInputsVerify using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
UseVerificationTime	useVerificationTime
ReturnVerificationTimeInfo	returnVerificationTime
AdditionalKeyInfo	addKeyInfo
ReturnProcessingDetails	returnProcDetails
ReturnSigningTimeInfo	returnSigningTime
ReturnSignerIdentity	returnSigner
ReturnAugmentedSignature	returnAugmented
ReturnTransformedDocument	returnTransformed
ReturnTimestampedSignature	returnTimestamped
VerifyManifests	verifyManifests

 » [JDSS-4.3.5.1-2]

The OptionalInputsVerifyType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.5.2 OptionalInputsVerify – XML Syntax

« The XML type OptionalInputsVerifyType SHALL implement the requirements defined in the OptionalInputsVerify component. » [XDSS-4.3.5.2-1]

The OptionalInputsVerifyType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalInputsVerifyType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.5.2-2]

4.3.6 Component OptionalOutputsBase

The OptionalOutputsBase contains a common set of additional outputs associated with the processing of the request. The client MAY request the server to respond with certain optional outputs by sending certain optional inputs. The server MAY also respond with outputs the client didn’t request, depending on the server’s profile and policy. « If a server does not recognize or can not handle any optional input, it MUST reject the request with a ResultMajor code of RequesterError and a ResultMinor code of NotSupported. » [DSS-4.3.6-1]

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.1.9 and is not repeated here.

4.3.6.1 OptionalOutputsBase – JSON Syntax

The component OptionalOutputsBase is abstract and therefore has no JSON definition.

4.3.6.2 OptionalOutputsBase – XML Syntax

« The XML type OptionalOutputsBaseType SHALL implement the requirements defined in the OptionalOutputsBase component. » [XDSS-4.3.6.2-1]

The OptionalOutputsBaseType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalOutputsBaseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.6.2-2]

4.3.7 Component OptionalOutputsSign

The OptionalOutputsSignType component defines a set of additional outputs associated with the processing of a signing request. This document does not define any additional outputs but profiles may extend the set of additional outputs.

Below follows a list of the sub-components that MAY be present within this component:

There are no sub-components specific to this component.

A set of sub-components is inherited from component 4.3.6 and is not repeated here.

4.3.7.1 OptionalOutputsSign – JSON Syntax

« The OptionalOutputsSignType JSON object SHALL implement in JSON syntax the requirements defined in the OptionalOutputsSign component. » [JDSS-4.3.7.1-1]

The OptionalOutputsSignType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.7.2 OptionalOutputsSign – XML Syntax

« The XML type OptionalOutputsSignType SHALL implement the requirements defined in the OptionalOutputsSign component. » [XDSS-4.3.7.2-1]

The OptionalOutputsSignType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalOutputsSignType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.7.2-2]

4.3.8 Component OptionalOutputsVerify

The OptionalOutputsVerify component defines a set of additional outputs associated with the processing of a verification request.

Below follows a list of the sub-components that MAY be present within this component:

A set of sub-components is inherited from component 4.3.6 and is not repeated here.

4.3.8.1 OptionalOutputsVerify – JSON Syntax

« The OptionalOutputsVerifyType JSON object SHALL implement in JSON syntax the requirements defined in the OptionalOutputsVerify component. » [JDSS-4.3.8.1-1]

« Properties of the JSON object SHALL implement the sub-components of OptionalOutputsVerify using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
VerifyManifestResults	result
SigningTimeInfo	signingTimeInfo
VerificationTimeInfo	verificationTimeInfo
ProcessingDetails	procDetails
SignerIdentity	signerIdentity
AugmentedSignature	augSig
TimestampedSignature	timestampedSig

 » [JDSS-4.3.8.1-2]

The OptionalOutputsVerifyType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.8.2 OptionalOutputsVerify – XML Syntax

« The XML type OptionalOutputsVerifyType SHALL implement the requirements defined in the OptionalOutputsVerify component. » [XDSS-4.3.8.2-1]

The OptionalOutputsVerifyType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of OptionalOutputsVerifyType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.8.2-2]

4.3.9 Component ClaimedIdentity

This element indicates the identity of the client who is making a request. The server MAY use this to parameterize any aspect of its processing. « Profiles that make use of this element MUST define its semantics. » [DSS-4.3.9-1]

Below follows a list of the sub-components that MAY be present within this component:

4.3.9.1 ClaimedIdentity – JSON Syntax

« The ClaimedIdentityType JSON object SHALL implement in JSON syntax the requirements defined in the ClaimedIdentity component. » [JDSS-4.3.9.1-1]

« Properties of the JSON object SHALL implement the sub-components of ClaimedIdentity using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Name	name
SupportingInfo	suppInfo

 » [JDSS-4.3.9.1-2]

The ClaimedIdentityType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.9.2 ClaimedIdentity – XML Syntax

« The XML type ClaimedIdentityType SHALL implement the requirements defined in the ClaimedIdentity component. » [XDSS-4.3.9.2-1]

The ClaimedIdentityType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of ClaimedIdentityType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.9.2-2]

4.3.10 Component Schemas

The Schemas component provides an in-band mechanism for communicating XML schemas required for validating an XML document.

Below follows a list of the sub-components that MAY be present within this component:

Non-normative Comment:

4.3.10.1 Schemas – JSON Syntax

« The SchemasType JSON object SHALL implement in JSON syntax the requirements defined in the Schemas component. » [JDSS-4.3.10.1-1]

« Properties of the JSON object SHALL implement the sub-components of Schemas using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Schema	schema

 » [JDSS-4.3.10.1-2]

The SchemasType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.10.2 Schemas – XML Syntax

« The XML type SchemasType SHALL implement the requirements defined in the Schemas component. » [XDSS-4.3.10.2-1]

The SchemasType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SchemasType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.10.2-2]

4.3.11 Component AugmentSignatureInstruction

The AugmentSignatureInstruction component can be used as an optional input for both signing and verification requests and defines the type of augmentation that SHOULD be applied. The augmented signature will be returned in an AugmentedSignature (see section 4.3.32) or a DocumentWithSignature component. ESI defines the term ‘augmentation’ as follows in ETSI TR 119 001 [ESIFrame]: "signature augmentation: process of incorporating to a digital signature information aiming to maintain the validity of that signature over the long term"

Below follows a list of the sub-components that MAY be present within this component:

4.3.11.1 AugmentSignatureInstruction – JSON Syntax

« The AugmentSignatureInstructionType JSON object SHALL implement in JSON syntax the requirements defined in the AugmentSignatureInstruction component. » [JDSS-4.3.11.1-1]

« Properties of the JSON object SHALL implement the sub-components of AugmentSignatureInstruction using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Type	type

 » [JDSS-4.3.11.1-2]

The AugmentSignatureInstructionType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.11.2 AugmentSignatureInstruction – XML Syntax

« The XML type AugmentSignatureInstructionType SHALL implement the requirements defined in the AugmentSignatureInstruction component. » [XDSS-4.3.11.2-1]

The AugmentSignatureInstructionType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of AugmentSignatureInstructionType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.11.2-2]

4.3.12 Component IntendedAudience

The IntendedAudience element tells the server who the target audience of this signature is. The server MAY use this to parameterize any aspect of its processing (for example, the server MAY choose to sign with a key that it knows a particular recipient trusts).

Below follows a list of the sub-components that MAY be present within this component:

4.3.12.1 IntendedAudience – JSON Syntax

« The IntendedAudienceType JSON object SHALL implement in JSON syntax the requirements defined in the IntendedAudience component. » [JDSS-4.3.12.1-1]

« Properties of the JSON object SHALL implement the sub-components of IntendedAudience using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Recipient	recipient

 » [JDSS-4.3.12.1-2]

The IntendedAudienceType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.12.2 IntendedAudience – XML Syntax

« The XML type IntendedAudienceType SHALL implement the requirements defined in the IntendedAudience component. » [XDSS-4.3.12.2-1]

The IntendedAudienceType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of IntendedAudienceType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.12.2-2]

4.3.13 Component KeySelector

The KeySelector component holds data that selects a specific key or certificate or group of certificates. « Only one of its sub-components MUST be present. » [DSS-4.3.13-1]

But a KeySelector component can occur multiple times as a sub-component in the OptionalInputsSign component

Below follows a list of the sub-components that MAY be present within this component:

4.3.13.1 KeySelector – JSON Syntax

« The KeySelectorType JSON object SHALL implement in JSON syntax the requirements defined in the KeySelector component. » [JDSS-4.3.13.1-1]

« Properties of the JSON object SHALL implement the sub-components of KeySelector using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
X509Digest	x509Digest
X509SubjectName	sub
X509SKI	ski
X509Certificate	cert
KeyName	name

 » [JDSS-4.3.13.1-2]

The KeySelectorType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.13.2 KeySelector – XML Syntax

« The XML type KeySelectorType SHALL implement the requirements defined in the KeySelector component. » [XDSS-4.3.13.2-1]

The KeySelectorType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of KeySelectorType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.13.2-2]

4.3.14 Component X509Digest

The X509Digest component contains a base64-encoded digest of a certificate. The digest algorithm URI is identified with a required Algorithm element. « The input to the digest MUST be the raw octets that would be base64-encoded of a X509Certificate. » [DSS-4.3.14-1]

Below follows a list of the sub-components that MAY be present within this component:

4.3.14.1 X509Digest – JSON Syntax

« The X509DigestType JSON object SHALL implement in JSON syntax the requirements defined in the X509Digest component. » [JDSS-4.3.14.1-1]

« Properties of the JSON object SHALL implement the sub-components of X509Digest using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
value	value
Algorithm	alg

 » [JDSS-4.3.14.1-2]

The X509DigestType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.14.2 X509Digest – XML Syntax

« The XML type X509DigestType SHALL implement the requirements defined in the X509Digest component. » [XDSS-4.3.14.2-1]

The X509DigestType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of X509DigestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.14.2-2]

The element 'value' holding the base64 content is represented by the component's XML tag text content.

4.3.15 Component PropertiesHolder

The PropertiesHolder component is used to request that the server add certain signed or unsigned properties (aka “signature attributes”) into the signature. The client can send the server a particular value to use for each property, or leave the value up to the server to determine. The server can add additional properties, even if these aren’t requested by the client.

Below follows a list of the sub-components that MAY be present within this component:

4.3.15.1 PropertiesHolder – JSON Syntax

« The PropertiesHolderType JSON object SHALL implement in JSON syntax the requirements defined in the PropertiesHolder component. » [JDSS-4.3.15.1-1]

« Properties of the JSON object SHALL implement the sub-components of PropertiesHolder using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
SignedProperties	signedProps
UnsignedProperties	unsignedProps

 » [JDSS-4.3.15.1-2]

The PropertiesHolderType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.15.2 PropertiesHolder – XML Syntax

« The XML type PropertiesHolderType SHALL implement the requirements defined in the PropertiesHolder component. » [XDSS-4.3.15.2-1]

The PropertiesHolderType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of PropertiesHolderType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.15-2]

4.3.16 Component Properties

Below follows a list of the sub-components that MAY be present within this component:

4.3.16.1 Properties – JSON Syntax

« The PropertiesType JSON object SHALL implement in JSON syntax the requirements defined in the Properties component. » [JDSS-4.3.16.1-1]

« Properties of the JSON object SHALL implement the sub-components of Properties using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Property	prop

 » [JDSS-4.3.16.1-2]

The PropertiesType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.16.2 Properties – XML Syntax

« The XML type PropertiesType SHALL implement the requirements defined in the Properties component. » [XDSS-4.3.16.2-1]

The PropertiesType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of PropertiesType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.16.2-2]

4.3.17 Component Property

Below follows a list of the sub-components that MAY be present within this component:

4.3.17.1 Property – JSON Syntax

« The PropertyType JSON object SHALL implement in JSON syntax the requirements defined in the Property component. » [JDSS-4.3.17.1-1]

« Properties of the JSON object SHALL implement the sub-components of Property using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Identifier	id
Value	val

 » [JDSS-4.3.17.1-2]

The PropertyType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.17.2 Property – XML Syntax

« The XML type PropertyType SHALL implement the requirements defined in the Property component. » [XDSS-4.3.17.2-1]

The PropertyType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of PropertyType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.17.2-2]

Therefore, it occurs in the XML schema, too.

4.3.18 Component IncludeObject

The IncludeObject component is used to request the creation of an XMLSig enveloping signature. Multiple occurrences of this optional input can be present in a single SignRequest message. Each occurrence will cause the inclusion of an object inside the signature being created.

Below follows a list of the sub-components that MAY be present within this component:

4.3.18.1 IncludeObject – JSON Syntax

« The IncludeObjectType JSON object SHALL implement in JSON syntax the requirements defined in the IncludeObject component. » [JDSS-4.3.18.1-1]

« Properties of the JSON object SHALL implement the sub-components of IncludeObject using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
WhichDocument	whichDoc
hasObjectTagsAndAttributesSet	hasObjectTagsAndAttributesSet
ObjId	objId
createReference	createRef

 » [JDSS-4.3.18.1-2]

The IncludeObjectType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.18.2 IncludeObject – XML Syntax

« The XML type IncludeObjectType SHALL implement the requirements defined in the IncludeObject component. » [XDSS-4.3.18.2-1]

The IncludeObjectType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of IncludeObjectType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.18.2-2]

4.3.19 Component SignaturePlacement

The SignaturePlacement component is used to request the creation of an XMLSig enveloped signature placed within an input document. The resulting document with the enveloped signature is placed in the optional output DocumentWithSignature element. The server places the signature in the document identified using the WhichDocument attribute. In the case of a non-XML input document then the server will return an error unless alternative procedures are defined by a profile or in the server policy for handling such a situation.

Below follows a list of the sub-components that MAY be present within this component:

4.3.19.1 SignaturePlacement – JSON Syntax

« The SignaturePlacementType JSON object SHALL implement in JSON syntax the requirements defined in the SignaturePlacement component. » [JDSS-4.3.19.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignaturePlacement using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
XPathAfter	xPathAfter
XPathFirstChildOf	xPathFirstChildOf
NsPrefixMapping	nsDecl
WhichDocument	whichDoc
CreateEnvelopedSignature	createEnvelopedSignature

 » [JDSS-4.3.19.1-2]

The SignaturePlacementType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.19.2 SignaturePlacement – XML Syntax

« The XML type SignaturePlacementType SHALL implement the requirements defined in the SignaturePlacement component. » [XDSS-4.3.19.2-1]

The SignaturePlacementType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignaturePlacementType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.19.2-2]

4.3.20 Component DocumentWithSignature

The DocumentWithSignature component contains document with the signature inserted as requested with the SignaturePlacement component.

Below follows a list of the sub-components that MAY be present within this component:

4.3.20.1 DocumentWithSignature – JSON Syntax

« The DocumentWithSignatureType JSON object SHALL implement in JSON syntax the requirements defined in the DocumentWithSignature component. » [JDSS-4.3.20.1-1]

« Properties of the JSON object SHALL implement the sub-components of DocumentWithSignature using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Document	doc

 » [JDSS-4.3.20.1-2]

The DocumentWithSignatureType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.20.2 DocumentWithSignature – XML Syntax

« The XML type DocumentWithSignatureType SHALL implement the requirements defined in the DocumentWithSignature component. » [XDSS-4.3.20.2-1]

The DocumentWithSignatureType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of DocumentWithSignatureType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.20.2-2]

4.3.21 Component SignedReferences

The SignedReferences component gives the client greater control over how the <ds:Reference> elements are formed.

Below follows a list of the sub-components that MAY be present within this component:

4.3.21.1 SignedReferences – JSON Syntax

« The SignedReferencesType JSON object SHALL implement in JSON syntax the requirements defined in the SignedReferences component. » [JDSS-4.3.21.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignedReferences using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
SignedReference	signedRef

 » [JDSS-4.3.21.1-2]

The SignedReferencesType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.21.2 SignedReferences – XML Syntax

« The XML type SignedReferencesType SHALL implement the requirements defined in the SignedReferences component. » [XDSS-4.3.21.2-1]

The SignedReferencesType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignedReferencesType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.21.2-2]

4.3.22 Component SignedReference

Each SignedReference component refers to an input document and allows multiple <ds:Reference> elements to be based on a single input document. Furthermore, the client can request additional transforms to be applied to each <ds:Reference>, and can set each <ds:Reference> element’s Id or URI attribute. These aspects of the <ds:Reference> can only be set through the SignedReference component; they cannot be set through the input documents, since they are aspects of the reference to the input document, not the input document itself.

Below follows a list of the sub-components that MAY be present within this component:

4.3.22.1 SignedReference – JSON Syntax

« The SignedReferenceType JSON object SHALL implement in JSON syntax the requirements defined in the SignedReference component. » [JDSS-4.3.22.1-1]

« Properties of the JSON object SHALL implement the sub-components of SignedReference using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Transforms	transforms
WhichDocument	whichDoc
RefURI	refURI
RefId	refId

 » [JDSS-4.3.22.1-2]

The SignedReferenceType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.22.2 SignedReference – XML Syntax

« The XML type SignedReferenceType SHALL implement the requirements defined in the SignedReference component. » [XDSS-4.3.22.2-1]

The SignedReferenceType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SignedReferenceType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.22.2-2]

4.3.23 Component VerifyManifestResults

The results of verifying individual <ds:Reference>'s within a <ds:Manifest> are returned in the VerifyManifestResults component.

Below follows a list of the sub-components that MAY be present within this component:

4.3.23.1 VerifyManifestResults – JSON Syntax

« The VerifyManifestResultsType JSON object SHALL implement in JSON syntax the requirements defined in the VerifyManifestResults component. » [JDSS-4.3.23.1-1]

« Properties of the JSON object SHALL implement the sub-components of VerifyManifestResults using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
ManifestResult	signedRef

 » [JDSS-4.3.23.1-2]

The VerifyManifestResultsType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.23.2 VerifyManifestResults – XML Syntax

« The XML type VerifyManifestResultsType SHALL implement the requirements defined in the VerifyManifestResults component. » [XDSS-4.3.23.2-1]

The VerifyManifestResultsType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of VerifyManifestResultsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.23.2-2]

4.3.24 Component ManifestResult

The VerifyManifestResults component is comprised of one or more ManifestResult

Below follows a list of the sub-components that MAY be present within this component:

4.3.24.1 ManifestResult – JSON Syntax

« The ManifestResultType JSON object SHALL implement in JSON syntax the requirements defined in the ManifestResult component. » [JDSS-4.3.24.1-1]

« Properties of the JSON object SHALL implement the sub-components of ManifestResult using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
ReferenceXpath	xPath
Status	status
NsPrefixMapping	nsDecl

 » [JDSS-4.3.24.1-2]

The ManifestResultType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.24.2 ManifestResult – XML Syntax

« The XML type ManifestResultType SHALL implement the requirements defined in the ManifestResult component. » [XDSS-4.3.24.2-1]

The ManifestResultType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of ManifestResultType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.24.2-2]

4.3.25 Component UseVerificationTime

This UseVerificationTime component instructs the server to attempt to determine the signature’s validity at the specified time, instead of a time determined by the server policy.

Below follows a list of the sub-components that MAY be present within this component:

4.3.25.1 UseVerificationTime – JSON Syntax

« The UseVerificationTimeType JSON object SHALL implement in JSON syntax the requirements defined in the UseVerificationTime component. » [JDSS-4.3.25.1-1]

« Properties of the JSON object SHALL implement the sub-components of UseVerificationTime using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
CurrentTime	currTime
SpecificTime	specTime
Base64Content	b64Content

 » [JDSS-4.3.25.1-2]

The UseVerificationTimeType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.25.2 UseVerificationTime – XML Syntax

« The XML type UseVerificationTimeType SHALL implement the requirements defined in the UseVerificationTime component. » [XDSS-4.3.25.2-1]

The UseVerificationTimeType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of UseVerificationTimeType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.25.2-2]

4.3.26 Component AdditionalTimeInfo

The AdditionalTimeInfo component contains other time instant(s) relevant in the context of the verification time determination.

Below follows a list of the sub-components that MAY be present within this component:

4.3.26.1 AdditionalTimeInfo – JSON Syntax

« The AdditionalTimeInfoType JSON object SHALL implement in JSON syntax the requirements defined in the AdditionalTimeInfo component. » [JDSS-4.3.26.1-1]

« Properties of the JSON object SHALL implement the sub-components of AdditionalTimeInfo using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
value	value
Type	type
Ref	ref

 » [JDSS-4.3.26.1-2]

The AdditionalTimeInfoType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.26.2 AdditionalTimeInfo – XML Syntax

« The XML type AdditionalTimeInfoType SHALL implement the requirements defined in the AdditionalTimeInfo component. » [XDSS-4.3.26.2-1]

The AdditionalTimeInfoType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of AdditionalTimeInfoType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.26.2-2]

The element 'value' holding a date/time is represented by the component's XML tag text content.

4.3.27 Component VerificationTimeInfo

The VerificationTimeInfo component allows the client to obtain the time instant used by the server to validate the signature.

Below follows a list of the sub-components that MAY be present within this component:

4.3.27.1 VerificationTimeInfo – JSON Syntax

« The VerificationTimeInfoType JSON object SHALL implement in JSON syntax the requirements defined in the VerificationTimeInfo component. » [JDSS-4.3.27.1-1]

« Properties of the JSON object SHALL implement the sub-components of VerificationTimeInfo using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
VerificationTime	verificationTime
AdditionalTimeInfo	additionalTimeInfo

 » [JDSS-4.3.27.1-2]

The VerificationTimeInfoType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.27.2 VerificationTimeInfo – XML Syntax

« The XML type VerificationTimeInfoType SHALL implement the requirements defined in the VerificationTimeInfo component. » [XDSS-4.3.27.2-1]

The VerificationTimeInfoType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of VerificationTimeInfoType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.27.2-2]

4.3.28 Component AdditionalKeyInfo

The AdditionalKeyInfo component provides the server with additional data (such as certificates and CRLs) which it can use to validate the signature.

Below follows a list of the sub-components that MAY be present within this component:

4.3.28.1 AdditionalKeyInfo – JSON Syntax

« The AdditionalKeyInfoType JSON object SHALL implement in JSON syntax the requirements defined in the AdditionalKeyInfo component. » [JDSS-4.3.28.1-1]

« Properties of the JSON object SHALL implement the sub-components of AdditionalKeyInfo using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
X509Digest	x509Digest
X509SubjectName	sub
X509SKI	ski
X509Certificate	cert
KeyName	name
X509CRL	crl

 » [JDSS-4.3.28.1-2]

The AdditionalKeyInfoType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.28.2 AdditionalKeyInfo – XML Syntax

« The XML type AdditionalKeyInfoType SHALL implement the requirements defined in the AdditionalKeyInfo component. » [XDSS-4.3.28.2-1]

The AdditionalKeyInfoType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of AdditionalKeyInfoType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.28.2-2]

4.3.29 Component ProcessingDetails

The ProcessingDetails component elaborates on what signature verification steps succeeded or failed.

Below follows a list of the sub-components that MAY be present within this component:

4.3.29.1 ProcessingDetails – JSON Syntax

« The ProcessingDetailsType JSON object SHALL implement in JSON syntax the requirements defined in the ProcessingDetails component. » [JDSS-4.3.29.1-1]

« Properties of the JSON object SHALL implement the sub-components of ProcessingDetails using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
ValidDetail	valid
IndeterminateDetail	indeterminate
InvalidDetail	invalid

 » [JDSS-4.3.29.1-1]

The ProcessingDetailsType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.29.2 ProcessingDetails – XML Syntax

« The XML type ProcessingDetailsType SHALL implement the requirements defined in the ProcessingDetails component. » [XDSS-4.3.29.2-1]

The ProcessingDetailsType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of ProcessingDetailsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.29.2-2]

4.3.30 Component Detail

Below follows a list of the sub-components that MAY be present within this component:

Non-normative Comment:

4.3.30.1 Detail – JSON Syntax

« The DetailType JSON object SHALL implement in JSON syntax the requirements defined in the Detail component. » [JDSS-4.3.30.1-1]

« Properties of the JSON object SHALL implement the sub-components of Detail using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Code	code
Message	msg
Base64Content	b64Content
Type	type

 » [JDSS-4.3.30.1-2]

The DetailType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.30.2 Detail – XML Syntax

« The XML type DetailType SHALL implement the requirements defined in the Detail component. » [XDSS-4.3.30.2-1]

The DetailType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of DetailType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.30.2-2]

4.3.31 Component SigningTimeInfo

This SigningTimeInfo component allows the client to obtain the time instant associated to the signature creation.

Below follows a list of the sub-components that MAY be present within this component:

4.3.31.1 SigningTimeInfo – JSON Syntax

« The SigningTimeInfoType JSON object SHALL implement in JSON syntax the requirements defined in the SigningTimeInfo component. » [JDSS-4.3.31.1-1]

« Properties of the JSON object SHALL implement the sub-components of SigningTimeInfo using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
SigningTime	signingTime
SigningTimeBoundaries	signingTimeBounds
LowerBoundary	lowerBound
UpperBoundary	upperBound

 » [JDSS-4.3.31-2]

The SigningTimeInfoType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.31.2 SigningTimeInfo – XML Syntax

« The XML type SigningTimeInfoType SHALL implement the requirements defined in the SigningTimeInfo component. » [XDSS-4.3.31.2-1]

The SigningTimeInfoType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of SigningTimeInfoType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.31-2]

4.3.32 Component AugmentedSignature

The AugmentedSignature component contains the resulting augmented signature or timestamp or, in the case of a signature being enveloped in an output document, a pointer to the signature.

Below follows a list of the sub-components that MAY be present within this component:

4.3.32.1 AugmentedSignature – JSON Syntax

« The AugmentedSignatureType JSON object SHALL implement in JSON syntax the requirements defined in the AugmentedSignature component. » [JDSS-4.3.32.1-1]

« Properties of the JSON object SHALL implement the sub-components of AugmentedSignature using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
SignatureObject	sigObj
Type	type

 » [JDSS-4.3.32.1-2]

The AugmentedSignatureType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.32.2 AugmentedSignature – XML Syntax

« The XML type AugmentedSignatureType SHALL implement the requirements defined in the AugmentedSignature component. » [XDSS-4.3.32.2-1]

The AugmentedSignatureType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of AugmentedSignatureType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.32.2-2]

4.3.33 Component ReturnTransformedDocument

The ReturnTransformedDocument component instructs the server to return an input document to which the XML signature transforms specified by a particular <ds:Reference> have been applied. The <ds:Reference> is indicated by the zero-based WhichReference attribute (0 means the first <ds:Reference> in the signature, 1 means the second, and so on). Multiple occurrences of this optional input can be present in a single verify request message. Each occurrence will generate a corresponding optional output.

Below follows a list of the sub-components that MAY be present within this component:

4.3.33.1 ReturnTransformedDocument – JSON Syntax

« The ReturnTransformedDocumentType JSON object SHALL implement in JSON syntax the requirements defined in the ReturnTransformedDocument component. » [JDSS-4.3.33.1-1]

« Properties of the JSON object SHALL implement the sub-components of ReturnTransformedDocument using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
WhichReference	whichRef

 » [JDSS-4.3.33.1-2]

The ReturnTransformedDocumentType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.33.2 ReturnTransformedDocument – XML Syntax

« The XML type ReturnTransformedDocumentType SHALL implement the requirements defined in the ReturnTransformedDocument component. » [XDSS-4.3.33.2-1]

The ReturnTransformedDocumentType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of ReturnTransformedDocumentType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.33.2-2]

4.3.34 Component TransformedDocument

The TransformedDocument component contains a document corresponding to the specified <ds:Reference>, after all the transforms in the reference have been applied.

Below follows a list of the sub-components that MAY be present within this component:

4.3.34.1 TransformedDocument – JSON Syntax

« The TransformedDocumentType JSON object SHALL implement in JSON syntax the requirements defined in the TransformedDocument component. » [JDSS-4.3.34.1-1]

« Properties of the JSON object SHALL implement the sub-components of TransformedDocument using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Document	doc
WhichReference	whichRef

 » [JDSS-4.3.34.1-2]

The TransformedDocumentType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.3.34.2 TransformedDocument – XML Syntax

« The XML type TransformedDocumentType SHALL implement the requirements defined in the TransformedDocument component. » [XDSS-4.3.34.2-1]

The TransformedDocumentType XML element is defined in XML Schema [DSS2XSD] and is provided below as a service to the reader.

« Each child element of TransformedDocumentType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.3.34.2-2]

4.4 Referenced Data Structure Models from other documents

4.4.1 Component NameID

The NameID component is used when an element serves to represent an entity by a string-valued name. This component reflects the structure ‘NameID’ defined in the SAML2 specification [SAML2RWXSD]. This section provides the definition required to support the DSS-X 2.0 multi-syntax approach.

Below follows a list of the sub-components that MAY be present within this component:

4.4.1.1 NameID – JSON Syntax

« The NameIDType JSON object SHALL implement in JSON syntax the requirements defined in the NameID component. » [JDSS-4.4.1.1-1]

« Properties of the JSON object SHALL implement the sub-components of NameID using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
value	value
Format	format
SPProvidedID	provId
NameQualifier	nameQual
SPNameQualifier	spNameQual

 » [JDSS-4.4.1.1-2]

The NameIDType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.4.1.2 NameID – XML Syntax

The XML element is defined in the XML namespace:

http://docs.oasis-open.org/dss-x/ns/saml2/rewritten

« The XML type NameIDType SHALL implement the requirements defined in the NameID component. » [XDSS-4.4.1.2-1]

The NameIDType XML element is defined in XML Schema [SAML2RWXSD] and is provided below as a service to the reader.

« Each child element of NameIDType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.4.1.2-2] The element 'value' is represented by the component's XML tag text content.

4.4.2 Component Transforms

This component reflects the structure ‘Transforms’ defined in the XMLDSig specification [DSIGRWXSD]. This section provides the definition required to support the DSS-X 2.0 multi-syntax approach.

Below follows a list of the sub-components that MAY be present within this component:

4.4.2.1 Transforms – JSON Syntax

« The TransformsType JSON object SHALL implement in JSON syntax the requirements defined in the Transforms component. » [JDSS-4.4.2.1-1]

« Properties of the JSON object SHALL implement the sub-components of Transforms using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
Transform	transform

 » [JDSS-4.4.2.1-2]

The TransformsType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.4.2.2 Transforms – XML Syntax

The XML element is defined in the XML namespace 'http://docs.oasis-open.org/dss-x/ns/xmldsig/rewritten'. « The XML type TransformsType SHALL implement the requirements defined in the Transforms component. » [XDSS-4.4.2.2-1]

The TransformsType XML element is defined in XML Schema [DSIGRWXSD] and is provided below as a service to the reader.

« Each child element of TransformsType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.4.2.2-2]

4.4.3 Component Transform

This component reflects the structure ‘Transforms’ defined in the XMLDSig specification [DSIGRWXSD]. This section provides the definition required to support the DSS-X 2.0 multi-syntax approach. See section ‘Transforming DSS 1.0 into 2.0’ for a detailed discussion of the applied changes.

Below follows a list of the sub-components that MAY be present within this component:

4.4.3.1 Transform – JSON Syntax

« The TransformType JSON object SHALL implement in JSON syntax the requirements defined in the Transform component. » [JDSS-4.4.3.1-1]

« Properties of the JSON object SHALL implement the sub-components of Transform using JSON-specific names mapped as shown in the table below.

Element	Implementing JSON member name
value	val
Base64Content	b64Content
XPath	xPath
NsPrefixMapping	nsDecl
Algorithm	alg

 » [JDSS-4.4.3.1-2]

The TransformType JSON object is defined in the JSON schema [DSBJSON] and is provided below as a service to the reader.

4.4.3.2 Transform – XML Syntax

The XML element is defined in the XML namespace:

http://docs.oasis-open.org/dss-x/ns/xmldsig/rewritten

The original definition of this element uses the 'mixed' content attribute. To support non-XML syntax using a common object model the attribute is dropped and a 'value' component is introduced. « The XML type TransformType SHALL implement the requirements defined in the Transform component. » [XDSS-4.4.3.2-1]

The TransformType XML element is defined in XML Schema [DSIGRWXSD] and is provided below as a service to the reader.

« Each child element of TransformType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. » [XDSS-4.4.3.2-2]

4.5 Element / JSON Name Lookup Tables

4.5.1 JSON Member to Element Name

The subsequent table allows to find the names of a component's element for a given JSON member name.

Table 4.5.1:  JSON member name to element name it was mapped from

 

JSON member name	mapped from element name
additionalTimeInfo	AdditionalTimeInfo
addKeyInfo	AdditionalKeyInfo
alg	DigestMethod Algorithm
attRef	AttRef
attURI	AttRefURI
aud	IntendedAudience
augSig	AugmentedSignature
b64Content	Base64Content
b64Data	Base64Data
b64Sig	Base64Signature
cert	X509Certificate
claimedIdentity	ClaimedIdentity
code	Code
createEnvelopedSignature	CreateEnvelopedSignature
createRef	createReference
crl	X509CRL
currTime	CurrentTime
di	DigestInfo
dis	DigestInfos
doc	Document
format	Format
hasObjectTagsAndAttributesSet	HasObjectTagsAndAttributesSet
ID	Id
id	Identifier
idRef	IdRef
incContent	IncludeEContent
incObj	IncludeObject
indeterminate	IndeterminateDetail
inDocs	InputDocuments
invalid	InvalidDetail
keySel	KeySelector
lowerBound	LowerBoundary
maj	ResultMajor
mimeType	MimeType
min	ResultMinor
msg	ResultMessage Message
name	Name KeyName
nonce	Nonce
nsDecl	NsPrefixMapping
objId	ObjId
ocsp	OCSPResponse
optInp	OptionalInputs
optOutp	OptionalOutputs
poe	PoE
pre	NamespacePrefix
pRef	ProblemReference
procDetails	ProcessingDetails
profile	AppliedProfile
prop	Property
props	Properties
provId	SPProvidedID
quality	SignatureQualityLevel
recipient	Recipient
ref	Ref
refId	RefId
refType	RefType
refURI	RefURI
reqID	RequestID
respID	ResponseID
result	Result VerifyManifestResults ManifestResult
returnAugmented	ReturnAugmentedSignature
returnProcDetails	ReturnProcessingDetails
returnSigner	ReturnSignerIdentity
returnSigningTime	ReturnSigningTimeInfo
returnTimestamped	ReturnTimestampedSignature
returnTransformed	ReturnTransformedDocument
returnVerificationTime	ReturnVerificationTimeInfo
schema	Schema
schemaRefs	SchemaRefs
sigAlgo	SignatureAlgorithm
signedProps	SignedProperties
signedRef	SignedReference
signedRefs	SignedReferences
signerIdentity	SignerIdentity
signingTime	SigningTime
signingTimeBounds	SigningTimeBoundaries
signingTimeInfo	SigningTimeInfo
sigObj	SignatureObject
sigPlacement	SignaturePlacement
sigPtr	SignaturePtr
sigType	SignatureType
ski	X509SKI
specTime	SpecificTime
status	Status
sub	X509SubjectName
suppInfo	SupportingInfo
timestampedSig	TimestampedSignature
transform	Transform
transforms	Transforms
type	Type
unsignedProps	UnsignedProperties
upperBound	UpperBoundary
uri	NamespaceURI
useVerificationTime	UseVerificationTime
val	DigestValue Value value
valid	ValidDetail
verificationTime	VerificationTime
verificationTimeInfo	VerificationTimeInfo
verifyManifests	VerifyManifests
whichDoc	WhichDocument
whichRef	WhichReference
x509Digest	X509Digest
xPath	XPath ReferenceXpath
xPathAfter	XPathAfter
xPathFirstChildOf	XPathFirstChildOf

 

4.5.2 Element to Implementing JSON Member Name

The subsequent table allows to find the abbreviated JSON member names for a given element name.

Table 4.5.2:  Element to abbreviated JSON member name it is mapped to

 

Element	Implementing JSON member name
AdditionalKeyInfo	addKeyInfo
AdditionalTimeInfo	additionalTimeInfo
Algorithm	alg
AppliedProfile	profile
AttRef	attRef
AttRefURI	attURI
AugmentedSignature	augSig
Base64Content	b64Content
Base64Data	b64Data
Base64Signature	b64Sig
ClaimedIdentity	claimedIdentity
Code	code
CreateEnvelopedSignature	createEnvelopedSignature
createReference	createRef
CurrentTime	currTime
DigestInfo	di
DigestInfos	dis
DigestMethod	alg
DigestValue	val
Document	doc
Format	format
HasObjectTagsAndAttributesSet	hasObjectTagsAndAttributesSet
Id	ID
Identifier	id
IdRef	idRef
IncludeEContent	incContent
IncludeObject	incObj
IndeterminateDetail	indeterminate
InputDocuments	inDocs
IntendedAudience	aud
InvalidDetail	invalid
KeyName	name
KeySelector	keySel
LowerBoundary	lowerBound
ManifestResult	result
Message	msg
MimeType	mimeType
Name	name
NamespacePrefix	pre
NamespaceURI	uri
Nonce	nonce
NsPrefixMapping	nsDecl
ObjId	objId
OCSPResponse	ocsp
OptionalInputs	optInp
OptionalOutputs	optOutp
PoE	poe
ProblemReference	pRef
ProcessingDetails	procDetails
Properties	props
Property	prop
Recipient	recipient
Ref	ref
ReferenceXpath	xPath
RefId	refId
RefType	refType
RefURI	refURI
RequestID	reqID
ResponseID	respID
Result	result
ResultMajor	maj
ResultMessage	msg
ResultMinor	min
ReturnAugmentedSignature	returnAugmented
ReturnProcessingDetails	returnProcDetails
ReturnSignerIdentity	returnSigner
ReturnSigningTimeInfo	returnSigningTime
ReturnTimestampedSignature	returnTimestamped
ReturnTransformedDocument	returnTransformed
ReturnVerificationTimeInfo	returnVerificationTime
Schema	schema
SchemaRefs	schemaRefs
SignatureAlgorithm	sigAlgo
SignatureObject	sigObj
SignaturePlacement	sigPlacement
SignaturePtr	sigPtr
SignatureQualityLevel	quality
SignatureType	sigType
SignedProperties	signedProps
SignedReference	signedRef
SignedReferences	signedRefs
SignerIdentity	signerIdentity
SigningTime	signingTime
SigningTimeBoundaries	signingTimeBounds
SigningTimeInfo	signingTimeInfo
SpecificTime	specTime
SPProvidedID	provId
Status	status
SupportingInfo	suppInfo
TimestampedSignature	timestampedSig
Transform	transform
Transforms	transforms
Type	type
UnsignedProperties	unsignedProps
UpperBoundary	upperBound
UseVerificationTime	useVerificationTime
ValidDetail	valid
Value	val
value	val
VerificationTime	verificationTime
VerificationTimeInfo	verificationTimeInfo
VerifyManifestResults	result
VerifyManifests	verifyManifests
WhichDocument	whichDoc
WhichReference	whichRef
X509Certificate	cert
X509CRL	crl
X509Digest	x509Digest
X509SKI	ski
X509SubjectName	sub
XPath	xPath
XPathAfter	xPathAfter
XPathFirstChildOf	xPathFirstChildOf

 

The following process diagram illustrates the major buildings blocks of the processing of a signing request. The sub processes are described in the next chapters.

Figure 2: Signing Overview

The workflow splits into the sections for XMLDSig and CMS signature processing. The input component for a signing request is SignRequest (see section 4.2.6). The signature will be selected by the server considering a given SignatureType element of OptionalInputsSign and its configuration and policies. « Profiles MAY introduce additional signature types and thus MUST define the adequate processing steps. » [DSS-5-1]

If the element AddTimestamp of OptionalInputsSign is set to ‘true’ the sub-process ‘add Timestamp’ adds a timestamp to the signature.

The task of building the SignResponse component is shared between all signature formats.

5.1 Processing for XML Signatures

The first sub-process ‘process references’ of the XML signature creation is the processing of the references. The second sub-process handles the creation of the XML signature. These two sub-processes are described in detail below.

If the element CreateEnvelopedSignature  of SignaturePlacement is set to true the signature will be inserted into the document and location selected by SignaturePlacement.

5.1.1 Sub process ‘process references’

The following process diagram illustrates the processing steps for the assembly of references.

Figure 3: Process References

The input documents are read from the Base64Data element of the referred Document component into an octet stream. « This data MUST be a well-formed XML Document as defined in [XML] section 2.1. » [DSS-5.1.1-1]

If the optional input SignedReferences is present each SignedReference element controls the creation of a corresponding <ds:Reference>. The task ‘collect references’ handles the SignedReferences.

Otherwise there will be a <ds:Reference> element for each given input document. The set of transforms and their parameter will be selected by the server. The task ‘use default transforms’ select this set of <ds:Reference>.

Note: Transforms can be applied as a server implementation MAY choose to increase robustness of the Signatures created. These Transforms may reflect idiosyncrasies of different parsers or solve encoding issues or the like. Servers MAY choose not to apply transforms in basic processing and extract the binary data for direct hashing or canonicalize the data directly if certain optional inputs are not to be implemented.

If the element CreateEnvelopedSignature  of SignaturePlacement is set to true the list of transforms will be prepended with an EnvelopedSignatureTransform entry. The task ‘add EnvelopedSignatureTransform’ processes the corresponding <ds:Reference>.

« The RefURI attribute of <ds:Reference> element MUST be set to include a “same-document” URI which references either:

·         The whole Document containing the signature (by using a RefURI=””)

·         The relevant parts of the Document to be covered/protected by the signature (by using a “same-document” RefURI attribute having a value starting with “#”, like RefURI=”#some-id”, RefURI=”#xpointer(/)”, RefURI=”#xpointer(/DocumentElement/ToBeSignedElement)” or the like).
If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the options described above, the server MUST reject the request using a ResultMajor RequesterError which MAY be qualified by a ResultMinor urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI. 

 » [DSS-5.1.1-2]

This alignment will be performed by the task ‘align same-doc references’.

5.1.2 Sub process ‘create XML signature’

Figure 4: Create XML Signature

The first task (‘calculate remaining transforms’) of this section applies the given set of transforms. If a TransformedData element is provided by the client these calculations MUST be respected and just the remaining set of transforms must be processed by the server. « The case of a Document as base for a reference processing all transform steps MUST be applied. » [DSS-5.1.2-1]

Note: « As required in [XMLDSIG] if the end result is an XML node set, the server MUST attempt to convert the node set back into an octet stream using Canonical XML [XML-C14N]. » [DSS-5.1.2-2]

The ‘calculate / use given hash’ task computes the digest upon the transformation output. If a DocumentHash element is provided by the client the hash values are used as input for the following steps. The DocumentHash MAY contain digests of different algorithms. The server selects the appropriate hash algorithm.

Performing the task ‘build XMLDSig’ the server forms a set of <ds:Reference> with the elements and attributes set as follows:

·         If the Document has a RefURI attribute, the <ds:Reference> element’s URI attribute is set to the value of the RefURI attribute, else this attribute is omitted.       
« A signature MUST NOT be created if more than one RefURI is omitted in the set of input documents and the server MUST report a RequesterError by setting ResultMajor RequesterError qualified by a ResultMinor. » [DSS-5.1.2-3]

·         If the Document has a RefType attribute, the <ds:Reference> element’s Type attribute is set to the value of the RefType attribute, else this attribute is omitted.

·         The <ds:DigestMethod> element is set to the hash method used.

·         The <ds:DigestValue> element is set to the hash value that is to be calculated as per [XMLDSIG].

·         The <ds:Transforms> element is set to the sequence of transforms applied by the server in step b. « This sequence MUST describe the effective transform as a reproducible procedure from parsing until hash. » [DSS-5.1.2-4]

·         « References resulting from processing of optional inputs MUST be included. » [DSS-5.1.2-5] In doing so, the server MAY reflect the ordering of the Document elements.

The server creates an XML signature using these <ds:Reference> elements according to the processing rules in [XMLDSIG].

The last task ‘insert ds:Object’ handles the creation of an enveloping signature. If one or more optional input elements IncludeObject are present they will cause the inclusion of an object inside the signature being created.

5.1.2.1 XML Signatures Variant Optional Input IncludeObject

An enveloping signature is a signature having <ds:Object>s which are referenced by <ds:Reference>s having a same-document URI.

For each <IncludeObject> the server creates a new <ds:Object> element containing the document, as identified using the WhichDocument element, as its child. This object is carried within the enveloping signature. The ordering of the <IncludeObject> optional inputs MAY be ignored by the server.

«  This <Document> MUST include a “same-document” RefURI attribute (having a value starting with “#”) which references either:

·         The whole newly-created <ds:Object>.

·         The relevant parts of the newly-created <ds:Object>’s contents to be covered/protected by the signature.

 » [DSS-5.1.2.1-1] « f the result of evaluating the expression included in the RefURI element doesn’t fit in any of the options described above, the server MUST reject the request using a ResultMajor RequesterError which MAY be qualified by a ResultMinor

urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI » [DSS-5.1.2.1-2]

 

Note: If the server does not support the ordering of <ds:Object>, it is recommended either to use ID-based referencing to the <ds:Object> (using the client-generated ID included in the ObjId attribute) or to rely on expressions based on <ds:Object>'s contents that allow to unambiguously refer to the included object or their relevant parts.

The URI in the RefURI element of this <Document> should at least reference the relevant parts of the Object to be included in the calculation for the corresponding reference. « Clients MUST generate requests in a way that some <ds:Reference>’s URI values actually will reference the <ds:Object> generated by the server once this element will have been included in the <ds:Signature> produced by the server. » [DSS-5.1.2.1-3]

« For each IncludeObject the server MUST carry out the following steps before performing Basic Processing:

1.     The server identifies the Document that is to be placed into a <ds:Object> as indicated by the WhichDocument element.

2.     The data to be carried in the enveloping signature is extracted and decoded.

3.     if the hasObjectTagsAndAttributesSet element is false or not present the server builds the <ds:Object> as follows:

a.     The server generates the new <ds:Object> and sets its Id attribute to the value indicated in ObjId element of the optional input if present.

b.     In the case of the Document pointed at by WhichDocument having Base64Data, <ds:Object>('s) MIME Type is to be set to the value of Base64Data('s) MIME Type value and the Encoding is to be set to http://www.w3.org/TR/xmlschema-2/#base64Binary

4.     The server splices the to-be-enveloped documents as <ds:Object>(s) into the <ds:Signature>, which is to be returned.

5.     If CreateReference is set to true generate a ds:Reference element referencing the spliced <ds:Object> and exclude this <Document> from the set of <Document>s ready for further processing. Otherwise just exclude this <Document> from the set of <Document>s ready for further processing.

 » [DSS-5.1.2.1-4]

5.2 Processing for CMS Signatures

5.2.1 Sub process ‘process digest’

The following process diagram illustrates the processing steps required to calculate the digest for a CMS signature.

Figure 5: Process Digest

The SignRequest component MUST contain either a single Document (not having RefURI or RefType set) or a single DocumentHash component not having RefURI, RefType, Transforms.

If the InputDocuments component contains a Document element, the server hashes the octet stream represented by the Document. This is performed by the task ‘calculate digest’ If the InputDocuments component contains a DocumentHash element, the server uses the hash values as an input for the following steps. The DocumentHash MAY contain digests of different algorithms. The server selects the appropriate hash algorithm.

5.2.2 Sub process ‘create CMS signature’

The following process diagram illustrates the processing steps to create a CMS signature.

Figure 6: Create CMS signature

If the InputDocuments component contains a Document element and the IncludeEContent element of the OptionalInputsSign component is set to true then the task ‘include content’ creates a CMS structure with the document enveloped within the signature. For CMS details in this context please refer to [RFC 3852] sections 5.1 “SignedData Type” and 5.2 “EncapsulatedContentInfo Type”.

« Otherwise the resulting signature MUST be detached (aka. external or “without eContent”). » [DSS-5.2.2-1]

The following task ‘build CMS signature’ builds a SignedData structure containing the SignerInfo computed as follows:

The server forms a SignerInfo structure based on the input document. The components of the SignerInfo are set as follows:

·         The digestAlgorithm field is set to the OID value for the hash method that was used in the previous processing step.

·         The signedAttributes field’s message-digest attribute contains the hash value that was calculated / provided in previous processing step. Other signedAttributes MAY be added by the server, according to its profile or policy, or according to the Properties optional input.

·         The remaining fields (sid, signatureAlgorithm, and signature) are filled in as per a normal CMS signature.

5.3 General Timestamp Processing

5.3.1 Sub process ‘add Timestamp’

The following process diagram illustrates the processing steps to insert a timestamp.

Figure 7: Add Timestamp

The AddTimestamp element of OptionalInputsSign indicates that the client wishes the server to embed a timestamp token as a property or attribute of the resultant or the supplied signature. The timestamp token will be applied to the signature value in the case of CMS/PKCS7 signatures or the <ds:SignatureValue> element in the case of XML signatures.

Note: Procedures for handling other forms of timestamp may be defined in profiles of the Core. In particular, the DSS AdES profile [DSS-AdES-P] defines procedures for generating timestamps over the content which is about to be signed (sometimes called content timestamps), and the DSS Timestamp profile [DSS-TS-P] defines procedures for handling standalone timestamps.

The Type element, if present, indicates what type of timestamp to apply. « Profiles that use this optional input MUST define the allowed values, and the default value, for the Type attribute (unless only a single type of timestamp is supported, in which case the Type attribute can be omitted). » [DSS-5.3.1-1]

Two scenarios for the timestamping of both CMS and XML signatures are supported by this Optional Input. They are as follows:

·         Create and embed a timestamp token into the signature being created as part of this SignRequest.

·         Create and embed a timestamp token into an existing signature, without verification, which is passed in the InputDocuments element of this SignRequest.

The following subsections specify the use of RFC 3161 timestamps with CMS signatures and the use of XML Timestamps or RFC 3161 timestamps with XML Signature. These subsections address both scenarios.

Note: The server SHOULD not verify the incoming signature before adding the timestamp. If a client wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the AddTimestamp optional input of the Verify protocol.

5.3.1.1 Processing for CMS signatures time-stamping

If the MimeType element of the Base64Data component is set to ‘application/pkcs7-signature’ a timestamp token is created and embedded into the existing signature, without verification, which is passed in the InputDocuments component of this SignRequest. Otherwise a timestamp token is created and embedded into the signature being created as part of the processing of this SignRequest.

« In both scenarios, the timestamp token created by the server SHALL be created according to [RFC 3161]. » [DSS-5.3.1.1-1] The MessageImprint field within the TstInfo structure of the timestamp token will be derived from the signature value of the just-created or incoming signature depending on the scenario. « The timestamp SHALL be embedded in the CMS signature as an unsigned attribute with the object identifier (see Appendix A of [RFC 3161]):

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} » [DSS-5.3.1.1-2]

The signature and its embedded timestamp is returned in the SignatureObject element of the SignResponse component.

5.3.1.2 Processing for XML Timestamps on XML signatures

« If the type attribute in the optional input AddTimestamp is urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken

and signature being timestamped is an XML signature, then the XML signature MUST contain <dss:timestamp> as defined in [DSS1Core] section 5.1, placed in a <xades:XMLTimestamp> within a <xades:SignatureTimeStamp> as defined in [XAdES]. » [DSS-5.3.1.2-1]

« The <dss:timestamp> MUST contain <ds:Signature> with at least two <ds:Reference> elements:

·         One with the Type attribute set to urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken
and referencing a <ds:Object> element whose content is a <TSTInfo> element.

·         The other referencing the <ds:SignatureValue> being timestamped.

 » [DSS-5.3.1.2-2]

The present specification defines a format for XML timestamp tokens. In addition, XAdES defines a mechanism for incorporating signature timestamps in XML signatures. « The present document mandates that signature timestamps in XML format MUST follow the syntax defined in [DSS1Core] section 5.1. » [DSS-5.3.1.2-3] « These time-stamp tokens MUST be added to XML signatures as specified by XAdES. » [DSS-5.3.1.2-4]

« The signature and its embedded timestamp SHALL be returned in the <SignatureObject> of the <SignResponse>. » [DSS-5.3.1.2-5]

5.3.1.3 Processing for RFC 3161 Timestamps on XML signatures

« If the type attribute in this optional input AddTimestamp is

urn:ietf:rfc:3161

and signature being timestamped is an XML signature then the XML signature MUST contain an RFC 3161, placed in a <xades:EncapsulatedTimeStamp> within a <xades:SignatureTimeStamp> as defined in [XAdES]. » [DSS-5.3.1.3-1]

A DSS server that verifies XML signatures SHOULD perform the following steps, upon receiving a verification with the top-level component VerifyRequest (see section 4.2.10). These steps may be changed or overridden by the optional inputs, or by the profile or policy the server is operating under. The results of the vewrification process are return to the caller within a VerifyResponse component (see section 4.2.11). For more details on multi-signature verification, see section 6.1.1.1 Multi-Signature Verification.

The following process diagram illustrates the major buildings blocks of the processing of a verification request. The sub processes are described in the following sub-chapters.

Figure 8: Verification Overview

The workflow splits into the sections for XMLDSig and CMS signature processing. « The processing path will be selected by the server considering a given SignatureType element of OptionalInputsVerify and its configuration and policies. » [DSS-6-1] Profiles may introduce additional signature types and MUST define the adequate processing steps.

·         If the element ReturnTimestampedSignature of OptionalInputsVerify is present, the sub-process ‘timestamp Signature’ adds a timestamp to the signature.

·         If the element ReturnUpdatedSignature of OptionalInputsVerify is ‘true’ the sub-process ‘update Signature’ inserts the updated signature into the OptionalOutputsVerify.

6.1 Processing for XML Signature Verification

6.1.1 Sub process ‘retrieve XML signature’

Figure 9: Retrieve XML Signature

The server retrieves one or more <ds:Signature> objects as follows: 

·         If the SignatureObject is present, the server retrieves either the <ds:Signature> that is a child element of the SignatureObject (see: Note at the end of this section), or those <ds:Signature> objects which are pointed to by the SignaturePtr in the SignatureObject. 

·         If the SignaturePtr points to an input document but not a specific element in that document, the pointed-to input document must be a Document element containing XML.

·         « If the SignatureObject is omitted, there MUST be only a single Document element. » [DSS-6.1.1-1]  This case is handled as if a SignaturePtr pointing to the single Document was present: the server will search and find every <ds:Signature> element in this input document and verify each <ds:Signature> according to the steps below.

6.1.1.1 Multi-Signature Verification

« If a client requests verification of an entire input document, either using a SignaturePtr without an XPath or a missing SignaturePtr (see section 6.1 step 1), then the server MUST determine whether the input document contains zero, one, or more than one <ds:Signature> elements. » [DSS-6.1.1.1-1]  If zero, the server SHOULD return a ResultMajor code of RequesterError.

« If more than one <ds:Signature> elements are present, the server MUST either reject the request with a ResultMajor code of RequesterError and a ResultMinor code of NotSupported, or accept the request and try to verify all of the signatures. » [DSS-6.1.1.1-2]

If the server accepts the request in the multi-signature case (or if only a single signature is present) and one of the signatures fails to verify, the server should return one of the error codes in section 6.2, reflecting the first error encountered.

If all of the signatures verify correctly, the server should return the Success ResultMajor code and the following ResultMinor code:

urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures

Non-normative Note:

Only certain optional inputs and outputs are allowed when performing multi-signature verification.  See section 5.3 General processing for details.

6.1.2 Sub process ‘recalculate references’

Figure 10: Recalculate References

For each <ds:Reference> in the <ds:Signature>, the server finds the input document with matching RefURI and RefType values (omitted attributes match omitted attributes).

·         If the <ds:Reference> uses a same-document URI, the XPointer should be evaluated against the input document the <ds:Signature> is contained within, or against the <ds:Signature> itself if it is contained within the SignatureObject element.

·         The SchemaRef element or optional input Schema of the input document or SignatureObject will be used, if present, to identify ID attributes when evaluating the XPointer expression.

·         If the <ds:Reference> uses an external URI and the corresponding input document is not present, the server will skip the <ds:Reference>, and later return a result code such as ReferencedDocumentNotPresent to indicate this.  The RefURI MAY be omitted in at most one of the set of Input documents.

·         If the input document is a Document, the server extracts and decodes as described in 4.2.3 Component Document onwards depending of the form of the input document).

·         If the input document is a TransformedData, the server MAY check that the <ds:Transforms> (if supplied) match between the TransformedData and the <ds:Reference> and then hashes the resultant data object according to <ds:DigestMethod>. « The server MUST check that the result matches <ds:DigestValue>. » [DSS-6.1.2-1]

·         If the input document is a DocumentHash, the server MAY check that the <ds:Transforms>, <ds:DigestMethod> (if supplied) and <ds:DigestValue> elements match between the DocumentHash and the <ds:Reference>.

·         « If the combination of RefURI and RefType matches more than one input document all of them MUST be either a TransformedData or a DocumentHash otherwise a RequesterError is issued qualified by result minor of ReferencedDocumentNotPresent. » [DSS-6.1.2-2]
Only one of them is allowed to have a WhichReference value that matches the order of the <ds:Reference> within the <ds:SignedInfo> in question otherwise a RequesterError is issued qualified by result minor of ReferencedDocumentNotPresent.

6.1.3 Sub process ‘verify XML signature’

Figure 11: Verify XML Signature

« If one or more timestamps are present on the given signature this / these timestamps MUST be verified. » [DSS-6.1.3-1] The ‘time of existence’ asserted by the timestamp MAY be used to decide the verification time. For details see section 6.1.3.1 and 6.1.3.2 .

The server verifies the validity of the signature at a particular time (i.e. current time, assumed signing time or other time), depending on the server policy. This behavior MAY be altered by using the optional input UseVerificationTime.

If the VerifyManifests element of OptionalInputsVerify is set to ‘true’ the server validates the manifests in an XML signature. In accordance with [XMLDSIG] section 5.1, DSS Manifest validation does not affect a signature's core validation. The results of verifying individual <ds:Reference>'s within a <ds:Manifest> are returned in the VerifyManifestResults within the OptionalOutputsVerify. If the optional input VerifyManifests is set to ’true’ and the XMLSig core validation succeeds, then the returned ResultMinor is

urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults

In case of a negative XMLSig core validation no attempt is made to verify manifests.

If the signature validates correctly, the server returns one of the first three ResultMinor codes listed in section 6.2, depending on the relationship of the signature to the input documents (not including the relationship of the signature to those XML elements that were resolved through XPointer evaluation; the client will have to inspect those relationships manually).  If the signature fails to validate correctly, the server returns some other code; either one defined in section 6.2 of this specification, or one defined by some profile of this specification.

6.1.3.1 Processing for RFC 3161 timestamp tokens on XML Signatures

The present section describes the processing rules for verifying an RFC 3161 timestamp token embedded within an XML signature as an unsigned property. This XML signature may be passed in on a Verify call within the SignatureObject or embedded within a Document’s child.

The server shall verify the timestamp token performing the steps detailed below. If any one of them results in failure, then the timestamp token SHOULD be rejected.

1.     Extract the timestamp token embedded in the incoming signature as defined in 5.3.1.2 Processing for XML Timestamps on XML signatures.

2.     Verify that the token's public verification certificate is authorized for time stamping by examining the Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8".

3.     Process the signature timestamp as defined in [XAdES] Annex G.2.2.16.1.3.

4.     Verify that the public verification certificate conforms to all relevant aspects of the relying-party's policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value.

5.     Set the Result element as appropriate.     
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.

6.1.3.2 Processing for XML timestamp tokens on XML signatures

The present section describes the processing rules for verifying and XML Signature timestamp token embedded within an XML signature using the incorporation mechanisms specified in XAdES (i.e., in the <xades:XMLTimeStamp> <xades:SignatureTimeStamp> element's child). This XML signature may be passed in on a Verify call within the SignatureObject or embedded within a Document’s child.

The server shall verify the timestamp token performing the steps detailed below. If any one of them results in failure, then the timestamp token SHOULD be rejected.

1.     Extract the timestamp token embedded in the incoming signature as defined in 5.3.1.2 Processing for XML Timestamps on XML signatures.

2.     Verify that the verification key and algorithms used conforms to all relevant aspects of the applicable policy. Should this key come within a public certificate, verify that the certificate conforms to all relevant aspects of the applicable policy including algorithm usage, policy OIDs, and time accuracy tolerances.

3.     Verify that the aforementioned verification key is consistent with the    ds:SignedInfo/SignatureMethod/@Algorithm attribute value.

4.     Verify the timestamp token signature in accordance with the rules defined in [XMLDSIG].

5.     Verify that the <ds:SignedInfo> element contains at least two <ds:Reference> elements.

6.     Verify that one of the <ds:Reference> elements has its Type attribute set to            “urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”.
Take this one and proceed as indicated below:

a.     Retrieve the referenced data object. Verify that it references a <ds:Object> element, which in turn envelopes a <TSTInfo> element.

b.     Verify that the <TSTInfo> element has a valid layout as per the present specification.

c.     Extract the digest value and associated algorithm from its <ds:DigestValue> and <ds:DigestMethod> elements respectively.

d.     Recalculate the digest of the retrieved data object as specified by [XMLDSIG] with the digest algorithm indicated in <ds:DigestMethod>, and compare this result with the contents of <ds:DigestValue>.

7.     Take each of the other <ds:Reference> elements and for each validate the hash as specified in [XMLDSIG].

8.     Check that for one of the <ds:Reference> elements the retrieved data object is actually the <ds:SignatureValue> element and that it contains its digest after canonicalization.

9.     Set the Result element as appropriate. Minor Error            
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.

6.2 Processing for CMS Signature Verification

A DSS server that verifies CMS signatures SHOULD perform the following steps, upon receiving a VerifyRequest.  These steps may be changed or overridden by the optional inputs, or by the profile or policy the server is operating under.

6.2.1 Sub process ‘retrieve CMS signature’

Figure 12: Retrieve CMS Signature

1.     The server retrieves the CMS signature by decoding the Base64Signature child of SignatureObject.

2.     The server retrieves the input data.  « If the CMS signature is detached, there MUST be a single input document: i.e. a single Document or DocumentHash element. » [DSS-6.2.1-1] « Otherwise, if the CMS signature is enveloping, it contains its own input data and there MUST NOT be any input documents present. » [DSS-6.2.1-2]

3.     The CMS signature and input data are verified in the conventional way (see [RFC 5652] for details).

4.     If the signature validates correctly, the server returns the first ResultMinor code listed in section 6.2. If the signature fails to validate correctly, the server returns some other code; either one defined in section 6.2 of this specification, or one defined by some profile of this specification.

6.2.2 Sub process ‘verify CMS signature’

Figure 13: Verify CMS Signature

« If one or more timestamps are present on the given signature this / these timestamps MUST be verified. » [DSS-6.2.2-1] The ‘time of existence’ asserted by the timestamp MAY be used to decide the verification time. For details see section 6.2.2.1 .

The server verifies the validity of the signature at a particular time (i.e. current time, assumed signing time or other time), depending on the server policy. This behavior MAY be altered by using the optional input UseVerificationTime.

If the signature validates correctly, the server returns one of the first three ResultMinor codes listed in section 4.1.7 Component Result.  If the signature fails to validate correctly, the server returns some other code; either one defined in section 4.1.7 Component Result of this specification, or one defined by some profile of this specification.

6.2.2.1 Processing for RFC 3161 Timestamp tokens on CMS Signatures.

The present section describes the processing rules for verifying a CMS RFC3161 timestamp token passed in on a Verify call within the SignatureObject of the VerifyRequest element. In the CMS case, since the "signature timestamp" is embedded in the signature as an unsigned attribute, only the time stamped signature is required for verification processing. As such, no additional input is required.

The processing by the server is broken down into the following steps:

1.     The signature timestamp is embedded in the incoming signature as an unsigned attribute whose object identifier is 1.2.840.11359.1.9.16.2.14. Extract and verify the timestamp token.

2.     Verify that the token's public verification certificate is authorized for time stamping by examining the Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8".

3.     Validate that the TstInfo structure has a valid layout as defined in [RFC 3161].

4.     Extract the MessageImprint hash value and associated algorithm from the TstInfo structure which will be compared against the hash value derived in the next step.

5.     Recalculate the hash of the signature value field of the signature in which the timestamp is embedded.

6.     Compare the hash values from the two previous steps, and if they are equivalent, then this timestamp is valid for the signature that was time stamped.

7.     Verify that the public verification certificate conforms to all relevant aspects of the relying-party's policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value.

8.     Set the Result element as defined in this specification. Minor Error            
urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.

6.3 General Processing

The following steps are shared between all signature types.

6.3.1 Sub process ‘update Signature’

The presence of the ReturnUpdatedSignature element of OptionalInputsVerify instructs the server to return an UpdatedSignature output, containing a new or updated signature.

Figure 14: Update Signature

The Type element of ReturnUpdatedSignature defines the process of “updating” a signature. For example, the updated signature may be the original signature with some additional unsigned signature properties added to it (such as timestamps, counter-signatures, or additional information for use in verification), or the updated signature could be an entirely new signature calculated on the same input documents as the input signature. « Profiles that use this optional input MUST define the allowed values and their semantics, and the default value of ReturnUpdatedSignature (unless only a single type of updated signature is supported, in which case the element can be omitted). » [DSS-6.3.1-1]

Multiple occurrences of this optional input can be present in a single verify request message. « If multiple occurrences are present, each occurrence MUST have a different value. » [DSS-6.3.1-2] Each occurrence will generate a corresponding UpdatedSignature optional output. « These optional outputs SHALL be distinguishable based on their Type element, which will match each output with an input. » [DSS-6.3.1-3]

A DSS server SHOULD perform the following steps to return the updated signature appropriately. These steps may be changed or overridden by a profile or policy the server is operating under. (e.g. for PDF documents enveloping CMS signatures).

Figure 15: Select Update Target

·         « If the detached or enveloping signature to be verified and updated appears within a Base64Signature then the UpdatedSignature optional output MUST contain the modified SignatureObject with the updated signature. » [DSS-6.3.1-4]

·         « If the signature to be verified and updated is enveloped, and if the VerifyRequest contains a SignatureObject with a SignaturePtr pointing to an InputDocument enveloping the signature then the server MUST produce the following TWO optional outputs, first a DocumentWithSignature optional output containing the document that envelopes the updated signature, second an UpdatedSignature optional output containing a SignatureObject having a SignaturePtr element that MUST point to the former DocumentWithSignature. » [DSS-6.3.1-5]

·         « If there is no SignatureObject included in the request then the server MUST produce a DocumentWithSignature optional output containing the document with the updated signature, only. » [DSS-6.3.1-6] No UpdatedSignature element will be generated.

If created the DocumentWithSignature optional output contains the input document with the given signature inserted. The server places the signature in the document identified using the SignatureObject / SignaturePtr / WhichDocument element. « This Document MUST include a same-document RefURI element which references the data updated (e.g of the form RefURI). » [DSS-6.3.1-7]

6.3.2 Sub process ‘timestamp Signature’

If the ReturnTimestampedSignature element of OptionalInputsVerify is present the server updates the signature after its verification by embedding a signature timestamp token as an unauthenticated attribute (see "unauthAttrs" in section 9.1 [RFC 5652]) or *unsigned* property (see section 6.2.5 "The UnsignedSignatureProperties element" and section 7.3 "The SignatureTimeStamp element" [XAdES]) of the supplied signature.

The timestamp token will be on the signature value in the case of CMS/PKCS7signatures or the <ds:SignatureValue> element in the case of XML signatures.

 

Figure 16: Timestamp Signature

The Type element of ReturnTimestampedSignature, if present, indicates what type of timestamp to build. This document defines two values for it, namely:

·         urn:ietf:rfc:3161 for generating a RFC 3161 timestamp token on the signature

·         urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken, for generating a XML timestamp token as defined in section 5.3 General Timestamp Processing of this document.

« Profiles that use this optional input MUST define the allowed values and the default value for the Type element (unless only a single type of timestamp is supported, in which case Type can be omitted). » [DSS-6.3.2-1]

The sub process of returning the updated signatures is the same as described in the sub process ‘update Signature’ (see section 6.3.1).

Note: Procedures for handling other forms of timestamp may be defined in profiles of the Core. In particular, the DSS XAdES profile [DSS-XAdES-P] defines procedures for handling timestamps against the document being signed, and the DSS Timestamp profile [DSS-TS-P] defines procedures for handling standalone timestamps.

6.3.3 Task ‘build VerifyResponse’

The task of building the VerifyResponse is shared between all signature formats. The OptionalInputsVerify element, server configuration and applied policies may affect the set of elements included in the OptionalOutputsVerify.

If the ReturnVerificationTimeInfo element of OptionalInputsVerify is set to ‘true’ the server returns the VerificationTimeInfo within the OptionalOutputsVerify. It contains the verification time and optionally other relevant time instants that may have been used when determining the verification time or that may be useful for its qualification.

If the ReturnSigningTimeInfo element of OptionalInputsVerify is set to ‘true’ the server returns the SigningTimeInfo within the OptionalOutputsVerify. It allows the client to obtain the time instant associated to the signature creation. Depending on the applicable server policy, this signing time needs to be qualified, in order to avoid unacceptable measurement errors or false claims, using time boundaries associated to trustworthy time values (based on timestamps or time-marks created using trusted time sources). In this case, the server MAY include these values in the LowerBoundary and UpperBoundary elements, respectively.

Criteria for determining when a time instant can be considered trustworthy and for determining the maximum acceptable delays between the signing time and their boundaries (if any) is outside the scope of this specification.

« When there's no way for the server to determine the signing time, the server MUST omit the SigningTimeInfo output. » [DSS-6.3.3-1]

If the ReturnSignerIdentity element of OptionalInputsVerify is set to ‘true’ the server returns the SignerIdentity element within the OptionalOutputsVerify. The SignerIdentity optional output contains an indication of who performed the signature. This option is not allowed in multi-signature verification.

If the ReturnTransformedDocument element of OptionalInputsVerify is present the server returns an input document to which the XML signature transforms specified by a particular <ds:Reference> have been applied. The <ds:Reference> is indicated by the zero-based WhichReference element (0 means the first <ds:Reference> in the signature, 1 means the second, and so on). Multiple occurrences of this optional input can be present in a single verify request message. Each occurrence will generate a corresponding optional output. These options are not allowed in multi-signature verification.

The TransformedDocument element within the OptionalOutputsVerify contains a document corresponding to the specified <ds:Reference> after all the transforms in the reference have been applied. In other words, the hash value of the returned document should equal the <ds:Reference> element’s <ds:DigestValue>. To match outputs to inputs, each TransformedDocument component will contain a WhichReference element which matches the corresponding ReturnTransformedDocument optional input element.

If the ReturnProcessingDetails element of OptionalInputsVerify is set to ‘true’ the server returns the ProcessingDetails element within the OptionalOutputsVerify. The ProcessingDetails element elaborates on what signature verification steps succeeded or failed. This option is not allowed in multi-signature verification.

The main functionality of the ‘Asynchronous Processing Profile’ [DSSAsync] is included in this version of the core.

The server MAY decide that the processing of a request cannot be performed within a reasonable timeframe and therefore return an instance of the ‘Component ResponseBase’ with the ResultMajor value of

urn:oasis:names:tc:dss:1.0:profiles:asynchronousprocessing:resultmajor:Pending

and the ResponseID element set to a server generated value.

The client MAY initiate a request with the top-level component PendingRequest (see section 4.2.12) from time to time with the ResponseID of the initial response included in the RequestID element.

If the server is still not able to return the requested response, it will respond with a ResultMajor of ‘Pending’ again. When the server finally succeeds with its processing the results will be delivered to the client with its next polling call. « In this case the ResultMajor value MUST NOT be ‘Pending’ but the ResultMajor resulting from the request processing. » [DSS-7-1]

Clients not able to perform the Asynchronous Processing Model MAY treat the ‘Pending’ response as an error or try to perform the operation at later point in time. Even without referring to the ResponseID the server MAY be able to respond with full result immediately.

Mappings from DSS messages into standard communications protocols are called DSS bindings.  Transport bindings specify how DSS messages are encoded and carried over some lower-level transport protocol. Security bindings specify how confidentiality, authentication, and integrity can be achieved for DSS messages in the context of some transport binding. Below we specify an initial set of bindings for DSS. Future bindings may be introduced by the OASIS DSS TC or by other parties.

8.1 HTTP POST Transport Binding

In this binding, the DSS request/response exchange occurs within an HTTP POST exchange [RFC 2616].

The following rules apply to the HTTP request:

1.     The client may send an HTTP/1.0 or HTTP/1.1 request.

2.     The Request URI may be used to indicate a particular service endpoint.

3.     « The Content-Type header MUST be set to “application/xml” or “application/json”. » [DSS-8.1-1]

4.     « The Content-Length header MUST be present and correct. » [DSS-8.1-2]

5.     « The DSS request message MUST be sent in the body of the HTTP Request. » [DSS-8.1-3]

The following rules apply to the HTTP Response:

1.     « The Content-Type header MUST be set to “text/xml” or “application/json”. » [DSS-8.1-4]

2.     « The Content-Length header MUST be present and correct. » [DSS-8.1-5]

3.     « The DSS response message MUST be sent in the body of the HTTP Response. » [DSS-8.1-6]

4.     « The HTTP status code MUST be

a.     either set to 200 if a DSS response message is returned. 

b.     or the status code can be set to

                                          i.    either 3xx to indicate a redirection

                                         ii.    or 4xx to indicate a low-level client error (such as a malformed request)

                                        iii.    or 5xx to indicate a low-level server error » [DSS-8.1-7]

8.2 SOAP 1.2 Transport Binding

In this binding, the DSS request/response exchange occurs using the SOAP 1.2 message protocol [SOAP].

The following rules apply to the SOAP request:

1.     A single DSS SignRequest or VerifyRequest element will be transmitted within the body of the SOAP message.

2.     « The client MUST NOT include any additional XML elements in the SOAP body. » [DSS-8.2-1]

3.     « The character encoding UTF-8 MUST be used for the SOAP message. » [DSS-8.2-2]

4.     Arbitrary SOAP headers may be present.

The following rules apply to the SOAP response:

1.     « The server MUST return either a single DSS SignResponse or VerifyResponse element within the body of the SOAP message, or a SOAP fault code. » [DSS-8.2-3]

2.     « The server MUST NOT include any additional XML elements in the SOAP body. » [DSS-8.2-4]

3.     « If a DSS server cannot parse a DSS request, or there is some error with the SOAP envelope, the server MUST return a SOAP fault code » [DSS-8.2-5].  Otherwise, a DSS result code should be used to signal errors.

4.     « The character encoding UTF-8 MUST be used for the SOAP message. » [DSS-8.2-6]

5.     Arbitrary SOAP headers may be present.

« On receiving a DSS response in a SOAP message, the client MUST NOT send a fault code to the DSS server. » [DSS-8.2-7]

8.3 Security Bindings

It is good practice to use a security binding (e.g. TLS) to provide confidentiality, authentication and integrity.

The selection of security mechanism and the used parameters depends on many aspects of the usage scenario, for example:

·         Required protection level of the content

·         Technical limitations (e.g. introduced by mobile clients)

·         Regulatory requirements

·         Export restrictions

Moreover, these decisions always need to be reconsidered due to new results crypto analysis and known vulnerabilities. Therefore, details regarding protocols and cipher suites are out of scope of this document.

The following sections define various URI-based identifiers.  Where possible an existing URN is used to specify a protocol.  In the case of IETF protocols the URN of the most current RFC that specifies the protocol is used (see [RFC 2648]).  URI references created specifically for DSS have the following stem:

urn:oasis:names:tc:dss:2.0:

9.1 Signature Type Identifiers

The following identifiers MAY be used as the content of the <SignatureType> optional input (see section 3.5.1).

9.1.1 XML Signature

• URI: urn:ietf:rfc:3275
• This refers to an XML signature per [XMLDSIG].

9.1.2 XML TimeStampToken

• URI: urn:oasis:names:tc:dss:2.0:core:schema:XMLTimeStampToken
• This refers to an XML timestamp containing an XML signature, per section 5.1.

9.1.3 RFC 3161 TimeStampToken

• URI: urn:ietf:rfc:3161
• This refers to an XML timestamp containing an ASN.1 TimeStampToken, per [RFC 3161].

9.1.4 CMS Signature

• URI: urn:ietf:rfc:3369
• This refers to a CMS signature per [RFC 5652] or prior versions of CMS.

9.1.5 PGP Signature

• URI: urn:ietf:rfc:2440
• This refers to a PGP signature per [RFC 2440].

9.2 ResultMinors

The following list contains the values of ResultMinor that are used in this document.

Abbreviation	URI
OnAll Documents	urn:oasis:names:tc:dss:2.0:resultminor:valid:signature:OnAllDocuments
NotAll Documents Referenced	urn:oasis:names:tc:dss:2.0:resultminor:valid:signature:NotAllDocumentsReferenced
Incorrect Signature	urn:oasis:names:tc:dss:2.0:resultminor:invalid:IncorrectSignature
HasManifest Results	urn:oasis:names:tc:dss:2.0:resultminor:valid:signature:HasManifestResults
Invalid Signature Timestamp	urn:oasis:names:tc:dss:2.0:resultminor:valid:signature:InvalidSignatureTimestamp
Referenced DocumentNot Present	urn:oasis:names:tc:dss:2.0:resultminor:ReferencedDocumentNotPresent
KeyInfoNot Provided	urn:oasis:names:tc:dss:1.0:resultminor:KeyInfoNotProvided
MoreThanOne RefUriOmitted	urn:oasis:names:tc:dss:2.0:resultminor:MoreThanOneRefUriOmitted
InvalidRefURI	urn:oasis:names:tc:dss:2.0:resultminor:InvalidRefURI
NotSupported	urn:oasis:names:tc:dss:2.0:resultminor:NotSupported
Inappropriate Signature	urn:oasis:names:tc:dss:2.0:resultminor:Inappropriate:signature
General Error	urn:oasis:names:tc:dss:2.0:resultminor:GeneralError
KeyLookup Failed	urn:oasis:names:tc:dss:2.0:resultminor:invalid:KeyLookupFailed
CrlNot Availiable	urn:oasis:names:tc:dss:2.0:resultminor:CrlNotAvailiable
OcspNot Availiable	urn:oasis:names:tc:dss:2.0:resultminor:OcspNotAvailiable
Certificate Chain NotComplete	urn:oasis:names:tc:dss:2.0:resultminor:CertificateChainNotComplete

 

There are several potential avenues for attack when processing incoming DSS documents. The following list is non-exhaustive and should not and can not replace a comprehensive security review.

A comprehensive security review considers the unique technology stack and processes specific to an implementation and not of all implementations.

10.1 Well-Known Attack Vectors

In the following subsections four well-known classes of attack vectors are highlighted:

1.     XML Parsing Vulnerabilities

2.     XML Canonicalization Vulnerabilities

3.     Injection Attacks

4.     JSON Deserialization Through Evaluation Attacks

The first two attack vector classes “XML Parsing Vulnerabilities” and “XML Canonicalization Vulnerabilities” can occur in any XML language and therefore do not rely on any specific DSS capabilities.

The third class, “Injection Attacks” applies to any format that is being processed in a deterministic way by an active processor with additional capabilities potentially being triggered by an unexpected and malicious payload.

“JSON Deserialization Through Evaluation Attacks” attack vectors consider processing programming languages and specifically collisions of constructs in the processing language used to consumer any JSON text and the allowed constructs in the JSON format.

In addition to the attack vectors listed and further detailed in the following non-normative subsections, DSS document processing requires interfaces to BASE64 and ASN.1 encoding and decoding in practical implementations, which MAY result in further attack vectors.

10.1.1 XML Parsing Vulnerabilities [non-normative]

There have been vulnerabilities in XML parsing libraries that can cause either denial of service or actual exploits. As an example, see Microsoft’s article on XML Denial of Service Attacks and Defenses. The best defense for these types of attacks is, in short, to keep the XML parser up-to-date and ensure to perform full validation prior to attempting to process the document.

10.1.2 XML Canonicalization Vulnerabilities [non-normative]

Exploitation of the use of canonicalization as content extractor MAY impact an implementation that offers e.g. inclusion and processing of XML Fragments in payloads as described e.g. in [JENSEN-2009].

10.1.3 Injection Attacks [non-normative]

Any DSS content MAY be processed somewhere, thus injection attacks MAY occur in many places which are not specific to DSS. The best defense known, is to sanitize untrusted output (and anything inside a DSS document received from outside the client or server system boundaries should be considered untrusted). For more explanation on injection attacks, see e.g. this OWASP article (https://www.owasp.org/index.php/Top_10-2017_A1-Injection).

10.1.4 JSON Deserialization Through Evaluation Attacks [non-normative]

Generally, there are security issues with processing languages that are capable to evaluate text in that processing language during runtime and dynamically. 

Sample vector for JavaScript:

“JSON is a subset of JavaScript that excludes assignment and invocation. Since JSON's syntax is borrowed from JavaScript, it is possible to use that language's "eval()" function to parse most JSON texts (but not all; certain characters such as U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript).  This generally constitutes an unacceptable security risk, since the text could contain executable code along with data declarations.  The same consideration applies to the use of eval()-like functions in any other programming language in which JSON texts conform to that language's syntax.” (cf. [RFC8259] section 12 “Security Considerations”.

11.1 Conformance as a DSS version 2.0 document

To ease communication and subsequent resolution of any specific partial conformance violation, the preceding chapters already provide minimal requirements, that a specific instance component must fulfill, to permit conformance of the complete DSS version 2.0 document.

11.1.1 Conformance for JSON format

The following clause offers a simple two step process, to either prove or disprove the conformance of a complete JSON document (formulated in terms specific to that implementation language) to this version of DSS:

« Conformance Clause 1: “Valid JSON DSS Document”
A JSON document instance conforms to this specification as a DSS document if it meets all of the following COUNT_ME conditions:

1.     Is valid JSON

2.     Validates against the JSON Schema

» DSS-11.1.1-1]

11.1.2 Conformance for XML format

The following clause offers a simple three step process, to either prove or disprove the conformance of a complete XML document (formulated in terms specific to that implementation language) to this version of DSS:

« Conformance Clause 1: “Valid XML DSS Document”
An XML document instance conforms to this specification as a DSS document if it meets all of the following three conditions:

1.     Is well-formed XML.

2.     Consists of a single root element instance as defined in
the namespace http://docs.oasis-open.org/dss-x/ns/core.

3.     Is valid XML.

» [DSS-11.1.2-1]

11.1.3 Conformance for DSS Server

« Conformance Clause 1: “Conforming DSS Server”
A DSS server instance conforms to this specification if the server fulfills all requirements on servers stated in the normative sections of this document. » [DSS-11.1.3-1]

11.1.4 Conformance for DSS Client

« Conformance Clause 1: “Conforming DSS Client”
A DSS client instance conforms to this specification if the client fulfills all requirements on clients stated in the normative sections of this document. » [DSS-11.1.4-1]

The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Andreas Kuehne, Individual

Detlef Huehnlein, Individual

Ernst Jan van Nigtevecht, Sonnenglanz Consulting

Juan Carlos Cruellas, Univ Politecnica de Cataluna

Stefan Hagen, Individual