Hi, see attached the PDF output of the markdown version. The 'single-line-code' flaw pointed out by Ernst Jan was an artifact of the Word->Markdown conversion.Fixed now. I discussed the pro and cons of MarkDown and Word with Stefan. My major aspects are - November nearly over and no version ready - Word is an capricious beast - MarkDown allows reuse of content in Swagger Do you see other relevant topics? Greetings, Andreas Attachment: md_test-18.11.21_22.18.02.pdf Description: Adobe PDF document  *** ** * ** *** Digital Signature Service Core Protocols, Elements, and Bindings Version 2.0 ============================================================================ Committee Specification Draft 02 WD01 ------------------------------------- 07 October 2018 --------------- ### Specification URIs #### This version: *
http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd02/dss-core-v2.0-csprd02.md (Authoritative) *
http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd02/dss-core-v2.0-csprd02.html *
http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd02/dss-core-v2.0-csprd02.pdf #### Previous 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 #### Latest version: *
http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.md (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](
https://www.oasis-open.org/committees/dss-x/ ) #### Chairs * Andreas Kuehne (
kuehne@trustable.de), Individual * 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/csprd02/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](
https://www.oasis-open.org/policies-guidelines/ipr#RF-on-Limited-Mode ) 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](
https://www.oasis-open.org/policies-guidelines/tc-process#wpComponentsCompLang )) 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. 07 October 2018. OASIS Committee Specification Draft 02 / Public Review Draft 02.
http://docs.oasis-open.org/dss-x/dss-core/v2.0/csprd02/dss-core-v2.0-csprd02.html . Latest version:
http://docs.oasis-open.org/dss-x/dss-core/v2.0/dss-core-v2.0.html . Notices ------- 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](
https://www.oasis-open.org/policies-guidelines/ipr ) 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](
https://www.oasis-open.org/ ), 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. *** ** * ** *** Table of Contents ----------------- [[TOC]] *** ** * ** *** 1 Introduction ============== 1.1 IPR Policy -------------- This specification is provided under the [RF on Limited Terms](
https://www.oasis-open.org/policies-guidelines/ipr#RF-on-Limited-Mode ) Mode of the [OASIS IPR Policy](
https://www.oasis-open.org/policies-guidelines/ipr ), 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 specification are to be interpreted as described in IETF RFC 2119 [[RFC2119](#RFC2119)] and RFC 8174 [[RFC8174](#RFC8174)]. 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](#refRFC2119)] and [[RFC8174](#refRFC8174)]. ### 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](
http://docs.oasis-open.org/dss/v1.0/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](
http://docs.oasis-open.org/dss/v1.0/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](
http://www.etsi.org/deliver/etsi_tr/119000_119099/119001/01.02.01_60/tr_119001v010201p.pdf )******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 Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119 . #### RFC2396 Berners-Lee, T., "Uniform Resource Identifiers (URI): Generic Syntax.", RFC 2396, DOI 10.17487/RFC2396, August 1998,
http://www.rfc-editor.org/info/rfc2396 . replace with: **[RFC3986]** Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
https://www.rfc-editor.org/info/rfc3986 . #### RFC2440 Callas J., Donnerhacke L., Finney H., Thayer R., "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, November 1998,
http://www.rfc-editor.org/info/rfc2440 . replace with: **[RFC4880]** Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007,
https://www.rfc-editor.org/info/rfc4880 . #### RFC2616 Fielding R., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999,
http://www.rfc-editor.org/info/rfc2616 . replace with (maybe the right individual RFC): **[RFC7230]** Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
https://www.rfc-editor.org/info/rfc7230 . **[RFC7231]** Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014,
https://www.rfc-editor.org/info/rfc7231 . **[RFC7232]** Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014,
https://www.rfc-editor.org/info/rfc7232 . **[RFC7233]** Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
https://www.rfc-editor.org/info/rfc7233 . **[RFC7234]** Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014,
https://www.rfc-editor.org/info/rfc7234 . **[RFC7235]** Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014,
https://www.rfc-editor.org/info/rfc7235 . #### RFC2648 Moats, R., "A URN Namespace for IETF Documents", RFC 2648, DOI 10.17487/RFC2648, August 1999,
https://www.rfc-editor.org/info/rfc2648 . #### RFC2822 Resnick, P., "Internet Message Format", BCP_ETC, RFC 2822, DOI 10.17487/RFC2822, April 2001,
http://www.rfc-editor.org/info/rfc2822 . replace with: **[RFC5322]** Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008,
https://www.rfc-editor.org/info/rfc5322 . #### RFC3161 Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001,
https://www.rfc-editor.org/info/rfc3161 . #### RFC5652 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009,
https://www.rfc-editor.org/info/rfc5652 . 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 Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, DOI 10.17487/RFC8259, December 2017,
http://www.rfc-editor.org/info/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 ](
http://www.w3.org/TR/1999/REC-xml-names-19990114/ ) **[XML-NT-Document]** [
http://www.w3.org/TR/2004/REC-xml-20040204/#NT-document ](
http://www.w3.org/TR/2004/REC-xml-20040204/ ) **[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 ](
https://www.iso.org/obp/ui#iso:std:iso:639:-1:ed-1:v1:en ). [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 Non-normative examples use this paragraph style. All examples in this document are non-normative and informative only. Representation-specific text is indented and marked with vertical lines. Representation-Specific Headline Normative representation-specific text All other text is normative unless otherwise labeled e.g. like: Non-normative Comment: This is a pure informative comment that may be present, because the information conveyed is deemed useful advice or common pitfalls learned from implementer or operator experience and often given including the rationale. 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]](#refDSSAsync). 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**](#refRFC5652) **]** . 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](#sec_AsyncProcessingModel) 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 [Design Considerations](#sec_DesignConsiderations) ==================================================== 2.1 [Version 2.0 goal](#sec_ver2goal) [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]](#refDSSAsync) 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]](#refRFC7515). 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](#sec_vtransform1to2) -------------------------------------------------------- This section describes the several actions taken to fulfil the goals listed in the previous section. ### 2.2.1 [Circumventing xs:any](#sec_avoidXsdAny) 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](#sec_substituteMixedSchemaAttribute) 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](#sec_introduceNsPrefixMappingTypeComp) 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](#sec_importedXmlSchemas) 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: <xs:complexType name="TransformType" mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other" processContents="lax"/> <!-- (1,1) elements from (0,unbounded) namespaces --> <xs:element name="XPath" type="string"/> </xs:choice> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType> 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. <xs:complexType name="TransformType"> <xs:sequence> <xs:element maxOccurs="1" minOccurs="0" name="value" type="string"/> <xs:element maxOccurs="1" minOccurs="0" name="Base64Content" type="xs:base64Binary"/> <xs:element maxOccurs="unbounded" minOccurs="0" name="XPath" type="string"/> <xs:element maxOccurs="unbounded" minOccurs="0" name="NsPrefixMapping" type="dsb:NsPrefixMappingType"/> </xs:sequence> <xs:attribute name="Algorithm" type="xs:string" use="required"/> </xs:complexType> 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](#sec_SyntaxVariants) 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](#sec_JsonSyntaxVExtensions) JSON, as described in [[RFC8259]](#ref_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](#sec_JConstructionPrinciples) ----------------------------------------------------------- ### 2.3.1 [Multi Syntax approach](#sec_MultiSyntaxApproach) 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](#refXML) and [JSON](#refRFC8259).  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](#refASN_1) or [CBOR](#refRFC7049). 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]](#refXMLDSIG) and the aspects described in 2.2.1 [Circumventing xs:any](#sec_avoidXsdAny), 2.2.2 [Substituting the mixed Schema Attribute](#sec_substituteMixedSchemaAttribute) and 2.2.3 [Introducing the NsPrefixMappingType Component](#sec_introduceNsPrefixMappingTypeComp) apply. 2.4 [Schema Organization and Namespaces](#sec_SchemaOrgaAndNamespaces) ---------------------------------------------------------------------- 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
http://docs.oasis-open.org/dss-x/ns/base and
http://docs.oasis-open.org/dss-x/ns/core 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](#refDSS2XSD) * The prefix dsb: stands for the DSS base namespace**[[DSBXSD].](#refDSBXSD)**[refDSS2XSD](#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: <xs:schema xmlns:dss2="
http://docs.oasis-open.org/dss-x/ns/core" ; xmlns:dsb="
http://docs.oasis-open.org/dss-x/ns/base" ; xmlns:ds-rw="
http://docs.oasis-open.org/dss-x/ns/xmldsig/rewritten" ; xmlns:xs="
http://www.w3.org/2001/XMLSchema" ; xmlns:saml-rw="
http://docs.oasis-open.org/dss-x/ns/SAML\_1.0/assertion/rewritten" ; xmlns:saml2-rw="
http://docs.oasis-open.org/dss-x/ns/saml2/rewritten" ; targetNamespace="
http://docs.oasis-open.org/dss-x/ns/core" ; elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:documentation xml:lang="en">This Schema defines the Digital Signature Service Core Protocols, Elements, and Bindings Committee Draft 1 for Public Review</xs:documentation> </xs:annotation> <xs:import namespace="
http://docs.oasis-open.org/dss-x/ns/xmldsig/rewritten" ; schemaLocation=" xmldsig-core-schema-dss-rw.xsd"/> <xs:import namespace="
http://docs.oasis-open.org/dss-x/ns/SAML\_1.0/assertion/rewritten" ; schemaLocation="oasis-sstc-saml-schema-protocol-1.1-dss-rw.xsd"/> <xs:import namespace="
http://docs.oasis-open.org/dss-x/ns/saml2/rewritten" ; schemaLocation="saml-schema-assertion-2.0-dss-rw.xsd"/> <xs:import namespace="
http://www.w3.org/XML/1998/namespace" ; schemaLocation="
http://www.w3.org/2001/xml.xsd"/ > 2.5 [DSS Component Overview](#sec_DssComponentsOverview) -------------------------------------------------------- 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]](#ref_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](#sec_SchemaExtensions) 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: <xs:redefine schemaLocation="core-schema.xsd"> <xs:complexType name="dss:OptionalOutputsVerifyType"> <xs:complexContent> <xs:extension base="dss:OptionalOutputsVerifyType"> <xs:group ref="prf:optionalOutputGroup"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> 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: "dss2-OptionalOutputsVerifyType": { "allOf": [ {"$ref": "#/definitions/prf-OptionialElement"}, { "type": "object", "properties": { "policy": { "type": "array", "items": { "type": "string" } }, // [...] } } ] } 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 [Data Type Models](#sec_DataTypeModels) ============================================== 3.1 [Boolean Model](#sec_BooleanModel) -------------------------------------- The boolean data type is used to specify a true or false 3.2 [Integer Model](#sec_IntegerModel) -------------------------------------- The integer data type is used to specify a numeric value without a fractional component. 3.3 [String Model](#sec_StringModel) ------------------------------------ The string data type can represent characters, line feeds, carriage returns, and tab characters. 3.4 [Binary Data Model](#sec_BinaryDataModel) --------------------------------------------- The base64Binary type holds Base64-encoded binary data 3.5 [URI Model](#sec_URIModel) ------------------------------ Uniform Resource Identifier (URI) is a string of characters used to identify a resource 3.6 [Unique Identifier Model](#sec_UniqueIdentifierModel) --------------------------------------------------------- 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](#sec_DateAndTimeModel) ------------------------------------------------ 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](#refISO8601)] 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](#sec_LangModel) -------------------------------- 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]](#refISO639_1) format (as given there in section 4 "Two-letter language code". >> [DSS-3.8-1]. 4 [Data Structure Models](#sec_DataStructureModels) ======================================================== Operation requests and responses -------------------------------- The XML elements of this section are defined in the XML namespace '
http://docs.oasis-open.org/dss/ns/core '.<var component="
http://docs.oasis-open.org/dss/ns/core-operation" ; element="
http://docs.oasis-open.org/dss/ns/core-operation.-explain" ;><span style="color:green">[category operation in namespace
http://docs.oasis-open.org/dss/ns/core explanation]</span></var> ### Component SignRequest <var component="dss2-SignRequestType" element="dss2-SignRequestType.-normative"><span style="color:green">The </span><span style="color:green">SignRequest</span><span style="color:green"> </span><span style="color:green">component</span><span style="color:green"> is sent by the client to request a signature or timestamp on some inpu</span><span style="color:green">t documents.</span></var> Below follows a list of the sub-components that MAY be present within this component: The optional InputDocuments element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [InputDocumentsType](#sec_22BB140F). <var alias="dss2-SignRequestType.inDocs" component="dss2-SignRequestType" element="dss2-SignRequestType.InputDocuments"><span style="color:green">[sub component InputDocuments details]</span></var> The optional OptionalInputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [OptionalInputsSignType](#sec_84D46F92). <var alias="dss2-SignRequestType.optInp" component="dss2-SignRequestType" element="dss2-SignRequestType.OptionalInputs"><span style="color:green">It is intended to transport additional input elements</span><span style="color:green"> </span><span style="color:green">of</span><span style="color:green"> the </span><span style="color:green">signing </span><span style="color:green">request.</span></var> #### Non-normative Comment: <var component="dss2-SignRequestType" element="dss2-SignRequestType.-nonNormative"><span style="color:green">[component SignRequest non normative details]</span></var> #### SignRequest -- JSON Syntax The SignRequestType JSON object SHALL implement in JSON syntax the requirements defined in the SignRequest component. Properties of the JSON object SHALL implement the sub-components of SignRequestType using JSON-specific names mapped as shown in the table below. Element Implementing JSON member name Comments ---------------- ------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- InputDocuments inDocs <var alias="dss2-SignRequestType.inDocs" component="dss2-SignRequestType" element="dss2-SignRequestType.-jsonComment.InputDocuments"><span style="color:green">[]</span></var> OptionalInputs optInp <var alias="dss2-SignRequestType.optInp" component="dss2-SignRequestType" element="dss2-SignRequestType.-jsonComment.OptionalInputs"><span style="color:green">[]</span></var> The SignRequestType JSON object is defined in the JSON schema [[DSS2JSON](#refDSS2JSON)] and is provided below as a service to the reader. "dss2-SignRequestType" : { "type" : "object", "properties" : { "profile" : { "type" : "array", "items" : { "type" : "string" } }, "reqID" : { "type" : "string" }, "inDocs" : { "$ref" : "#/definitions/dss2-InputDocumentsType" }, "optInp" : { "$ref" : "#/definitions/dss2-OptionalInputsSignType" } } } <var component="dss2-SignRequestType" element="dss2-SignRequestType.-jsonSchema"><span style="color:green">[component SignRequest JSON schema details]</span></var> #### SignRequest -- XML Syntax The XML type SignRequestType SHALL implement the requirements defined in the SignRequestcomponent. The SignRequestType XML element is defined in XML Schema [[DSS2XSD](#refDSS2XSD)], and is copied below for information. <xs:complexType name="SignRequestType"> <xs:complexContent> <xs:extension base="dsb:RequestBaseType"> <xs:sequence> <xs:element minOccurs="0" name="InputDocuments" type="dss2:InputDocumentsType"/> <xs:element minOccurs="0" name="OptionalInputs" type="dss2:OptionalInputsSignType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> Each child element of SignRequestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. <var component="dss2-SignRequestType" element="dss2-SignRequestType.-xmlSchema"><span style="color:green">[component SignRequest XML schema details]</span></var> ### Component SignResponse <var component="dss2-SignResponseType" element="dss2-SignResponseType.-normative"><span style="color:green">The </span><span style="color:green">SignResponse</span><span style="color:green"> component returns the requested signature or timestamp to the </span><span style="color:green">requestor</span><span style="color:green">.</span></var> Below follows a list of the sub-components that MAY be present within this component: The optional OptionalOutputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [OptionalOutputsSignType](#sec_F7F54724). <var alias="dss2-SignResponseType.optOutp" component="dss2-SignResponseType" element="dss2-SignResponseType.OptionalOutputs"><span style="color:green">The </span><span style="color:green">OptionalOutputs</span><span style="color:green"> element </span><span style="color:green">contains </span><span style="color:green">additional </span><span style="color:green">signing related </span><span style="color:green">outputs returned by the server.</span></var> The optional SignatureObject element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [SignatureObjectType](#sec_A5E5C69F). <var alias="dss2-SignResponseType.sigObj" component="dss2-SignResponseType" element="dss2-SignResponseType.SignatureObject"><span style="color:green">[sub component SignatureObject details]</span></var> #### Non-normative Comment: <var component="dss2-SignResponseType" element="dss2-SignResponseType.-nonNormative"><span style="color:green">[component SignResponse non normative details]</span></var> #### SignResponse -- JSON Syntax The SignResponseType JSON object SHALL implement in JSON syntax the requirements defined in the SignResponse component. Properties of the JSON object SHALL implement the sub-components of SignResponseType using JSON-specific names mapped as shown in the table below. Element Implementing JSON member name Comments ----------------- ------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- OptionalOutputs optOutp <var alias="dss2-SignResponseType.optOutp" component="dss2-SignResponseType" element="dss2-SignResponseType.-jsonComment.OptionalOutputs"><span style="color:green">[]</span></var> SignatureObject sigObj <var alias="dss2-SignResponseType.sigObj" component="dss2-SignResponseType" element="dss2-SignResponseType.-jsonComment.SignatureObject"><span style="color:green">[]</span></var> The SignResponseType JSON object is defined in the JSON schema [[DSS2JSON](#refDSS2JSON)] and is provided below as a service to the reader. "dss2-SignResponseType" : { "type" : "object", "properties" : { "result" : { "$ref" : "#/definitions/dsb-ResultType" }, "profile" : { "type" : "array", "items" : { "type" : "string" } }, "reqID" : { "type" : "string" }, "respID" : { "type" : "string" }, "optOutp" : { "$ref" : "#/definitions/dss2-OptionalOutputsSignType" }, "sigObj" : { "$ref" : "#/definitions/dss2-SignatureObjectType" } } } <var component="dss2-SignResponseType" element="dss2-SignResponseType.-jsonSchema"><span style="color:green">[component SignResponse JSON schema details]</span></var> #### SignResponse -- XML Syntax The XML type SignResponseType SHALL implement the requirements defined in the SignResponsecomponent. The SignResponseType XML element is defined in XML Schema [[DSS2XSD](#refDSS2XSD)], and is copied below for information. <xs:complexType name="SignResponseType"> <xs:complexContent> <xs:extension base="dsb:ResponseBaseType"> <xs:sequence> <xs:element minOccurs="0" name="OptionalOutputs" type="dss2:OptionalOutputsSignType"/> <xs:element minOccurs="0" name="SignatureObject" type="dss2:SignatureObjectType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> Each child element of SignResponseType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. <var component="dss2-SignResponseType" element="dss2-SignResponseType.-xmlSchema"><span style="color:green">[component SignResponse XML schema details]</span></var> ### Component VerifyRequest <var component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-normative"><span style="color:green">Th</span><span style="color:green">e </span><span style="color:green">VerifyRequest</span><span style="color:green"> </span><span style="color:green">component</span><span style="color:green"> is sent by the client to verify a signature or timestamp on some input documents.</span></var> Below follows a list of the sub-components that MAY be present within this component: The optional InputDocuments element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [InputDocumentsType](#sec_22BB140F). <var alias="dss2-VerifyRequestType.inDocs" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.InputDocuments"><span style="color:green">[sub component InputDocuments details]</span></var> The optional OptionalInputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [OptionalInputsVerifyType](#sec_5BA2A20A). <var alias="dss2-VerifyRequestType.optInp" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.OptionalInputs"><span style="color:green">[sub component OptionalInputs details]</span></var> The optional SignatureObject element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section [SignatureObjectType](#sec_A5E5C69F). <var alias="dss2-VerifyRequestType.sigObj" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.SignatureObject"><span style="color:green">Th</span><span style="color:green">e </span><span style="color:green">SignatureObject</span><span style="color:green"> element</span><span style="color:green"> contains a signature or timestamp, or else contains a <SignaturePtr> that points to an XML signature in one of the input documents.</span></var> #### Non-normative Comment: <var component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-nonNormative"><span style="color:green">[component VerifyRequest non normative details]</span></var> #### VerifyRequest -- JSON Syntax The VerifyRequestType JSON object SHALL implement in JSON syntax the requirements defined in the VerifyRequest component. Properties of the JSON object SHALL implement the sub-components of VerifyRequestType using JSON-specific names mapped as shown in the table below. Element Implementing JSON member name Comments ----------------- ------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- InputDocuments inDocs <var alias="dss2-VerifyRequestType.inDocs" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-jsonComment.InputDocuments"><span style="color:green">[]</span></var> OptionalInputs optInp <var alias="dss2-VerifyRequestType.optInp" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-jsonComment.OptionalInputs"><span style="color:green">[]</span></var> SignatureObject sigObj <var alias="dss2-VerifyRequestType.sigObj" component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-jsonComment.SignatureObject"><span style="color:green">[]</span></var> The VerifyRequestType JSON object is defined in the JSON schema [[DSS2JSON](#refDSS2JSON)] and is provided below as a service to the reader. "dss2-VerifyRequestType" : { "type" : "object", "properties" : { "profile" : { "type" : "array", "items" : { "type" : "string" } }, "reqID" : { "type" : "string" }, "inDocs" : { "$ref" : "#/definitions/dss2-InputDocumentsType" }, "optInp" : { "$ref" : "#/definitions/dss2-OptionalInputsVerifyType" }, "sigObj" : { "$ref" : "#/definitions/dss2-SignatureObjectType" } } } <var component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-jsonSchema"><span style="color:green">[component VerifyRequest JSON schema details]</span></var> #### VerifyRequest -- XML Syntax The XML type VerifyRequestType SHALL implement the requirements defined in the VerifyRequestcomponent. The VerifyRequestType XML element is defined in XML Schema [[DSS2XSD](#refDSS2XSD)], and is copied below for information. <xs:complexType name="VerifyRequestType"> <xs:complexContent> <xs:extension base="dsb:RequestBaseType"> <xs:sequence> <xs:element minOccurs="0" name="InputDocuments" type="dss2:InputDocumentsType"/> <xs:element minOccurs="0" name="OptionalInputs" type="dss2:OptionalInputsVerifyType"/> <xs:element minOccurs="0" name="SignatureObject" type="dss2:SignatureObjectType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> Each child element of VerifyRequestType XML element SHALL implement in XML syntax the sub-component that has a name equal to its local name. <var component="dss2-VerifyRequestType" element="dss2-VerifyRequestType.-xmlSchema"><span style="color:green">[component VerifyRequest XML schema details]</span>