dss-x — archive

[Andreas Kuehne]

Hi all, based on Stefan's markdown version of the core spec 2.0 I applied the 'usual' generation step . See the generated markdown / HTML files attached. To reuse the given setup and the options of the available markdown libraries the most convenient approach is to use the 'var' tag of HTML. In the markdown the user content to be preserved can be inserted between the <var> and </var> in the same way Word offered it in the 'green' sections. Please take a look whether my approach and the results do make sense. Greetings, Andreas -- Andreas KÃhne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas KÃhne Company UK Company No: 5218868 Registered in England and Wales 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 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 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. 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 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. Table of Contents [[TOC]] 1 Introduction 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 specification are to be interpreted as described in IETF RFC 2119 [ RFC2119 ] and RFC 8174 [ 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 ] 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 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 [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 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] . 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 Design Considerations 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: <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 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 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 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: <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 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: <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 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 Data Structure Models Operation requests and responses The XML elements of this section are defined in the XML namespace 'http://docs.oasis-open.org/dss/ns/core'. [category operation in namespace http://docs.oasis-open.org/dss/ns/core explanation] Component SignRequest The SignRequest component is sent by the client to request a signature or timestamp on some inpu t documents. 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 . [sub component InputDocuments details] The optional OptionalInputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section OptionalInputsSignType . It is intended to transport additional input elements of the signing request. Non-normative Comment: [component SignRequest non normative details] 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 [] OptionalInputs optInp [] The SignRequestType JSON object is defined in the JSON schema [ DSS2JSON ] 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 } } } [component SignRequest JSON schema details] 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 ], 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. [component SignRequest XML schema details] 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: The optional OptionalOutputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section OptionalOutputsSignType . The OptionalOutputs element contains additional signing related outputs returned by the server. The optional SignatureObject element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section SignatureObjectType . [sub component SignatureObject details] Non-normative Comment: [component SignResponse non normative details] 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 [] SignatureObject sigObj [] The SignResponseType JSON object is defined in the JSON schema [ DSS2JSON ] 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 } } } [component SignResponse JSON schema details] 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 ], 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. [component SignResponse XML schema details] Component VerifyRequest Th e 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: The optional InputDocuments element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section InputDocumentsType . [sub component InputDocuments details] The optional OptionalInputs element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section OptionalInputsVerifyType . [sub component OptionalInputs details] The optional SignatureObject element MUST contain a sub-component. A given element MUST satisfy the requirements specified in this document in section SignatureObjectType . Th e SignatureObject element contains a signature or timestamp, or else contains a <SignaturePtr> that points to an XML signature in one of the input documents. Non-normative Comment: [component VerifyRequest non normative details] 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 [] OptionalInputs optInp