Digital Signature Service Core Protocols, Elements, and Bindings Version 0 oasis standard 11 April 2007




старонка3/11
Дата канвертавання24.04.2016
Памер0.54 Mb.
1   2   3   4   5   6   7   8   9   10   11

1.3Schema Organization and Namespaces


The structures described in this specification are contained in the schema file [Core-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 takes precedence.

This schema is associated with the following XML namespace:

urn:oasis:names:tc:dss:1.0:core:schema

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 dss: stands for the DSS core namespace [Core-XSD].

  • The prefix ds: stands for the W3C XML Signature namespace [XMLDSIG].

  • The prefix xs: stands for the W3C XML Schema namespace [Schema1].

  • The prefix saml: stands for the OASIS SAML Schema namespace [SAMLCore1.1].

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:



xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"

elementFormDefault="qualified"

attributeFormDefault="unqualified">



This Schema defines the Digital Signature Service Core Protocols, Elements, and Bindings Committee Draft 5 for Public Review








1.4DSS Overview (Non-normative)


This specification describes two XML-based request/response protocols – a signing protocol and a verifying protocol. Through these protocols a client can send documents (or document hashes) to a server and receive back a signature on the documents; or send documents (or document hashes) and a signature to a server, and receive back an answer on whether the signature verifies the documents.

These 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 needing complex client software and configuration.

The signing and verifying protocols are chiefly designed to support the creation and verification of XML signatures [XMLDSIG], XML timestamps (see section 5.1), binary timestamps [RFC 3161] and CMS signatures [RFC 3852]. These protocols may also 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 6 provides an initial set of bindings.

In addition to defining the signing and verifying protocols, this specification defines two XML elements that are related to these protocols. First, an XML timestamp element is defined in 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 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.


2Common Protocol Structures


The following sections describe XML structures and types that are used in multiple places.
1   2   3   4   5   6   7   8   9   10   11


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка