Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document serves to publish RELAX NG schemas for XML Security specifications, including XML Signature 1.0 and 1.1, XML Encryption 1.0 and 1.1, Exclusive Canonicalization, XML Signature Properties, XML-Signature XPath Filter 2.0, and XML Security Generic Hybrid Ciphers.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This Note track Working Draft collects non-normative RELAX NG Schemas for XML Security specifications, including XML Signature 1.0 and 1.1, XML Encryption 1.0 and 1.1, Exclusive Canonicalization, XML Signature Properties, XML-Signature XPath Filter 2.0, and XML Security Generic Hybrid Ciphers. The normative description of the respective data formats are included in the Recommendation-track specifications.
These schemas are drafts and subject to further revisions. This is a work in progress. This document is intended to evolve to include additional RELAX NG schemas.
This version of this specification differs from the the previous version as follows (redline):
http://www.w3.org/2009/xmlenc11#rsa-oaep"
          (xenc-schema-11.rnc
          xenc-schema-11.rng)This document was published by the XML Security Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-xmlsec@w3.org (subscribe, archives). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The XML Security specifications include normative XML Schema [XMLSCHEMA-1], [XMLSCHEMA-2]. This note provides non-normative RELAX NG schemas in the compact syntax as well as the XML syntax [RELAXNG-SCHEMA].
The biggest difference from the original XSD schemas is that these
      RELAX NG schemas provide co-occurrence constraints between the
      Algorithm attribute and child parameter elements.  Thus, RELAX NG
      validation can report an error when a DigestMethod element with
      Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" has an
      HMACOutputLength element, which is allowed only when
      Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1".
Schemas in this group invoke other schemas, and further define the start pattern and wildcard patterns. These driver schemas are written from scratch.
A driver schema is required for each combination of strict, lenient, and supplementary schemas (see below). This note provides some driver schemas, but does not cover all possible combinations. It is believed that driver schemas for other combinations are easy to write.
Moreover, the driver schemas in this note allow signature or encryption elements anywhere in the given XML document. When one wants to allow signature or encryption elements at a certain location only, dedicated schemas are required.
Schemas in this group play the key role, and they are derived from the
        original XSD schemas.  Unlike the original XSD schemas, strict schemas
        allow specific values of the Algorithm attribute and further specify
        permissible child parameter elements for each of the values.  For
        example, a strict schema xmldsig-core-schema.rnc allows
        "http://www.w3.org/2000/09/xmldsig#sha1" as the value of the Algorithm
        attribute of the DigestMethod element and an empty sequence of child
        elements. 
Schemas in this group complement strict schemas, and they are derived mainly from xsd:any in the original XSD schemas. Lenient schemas are expected to be used together with strict schemas.
Unlike strict schemas, lenient schemas allow any value for the
        Algorithm attribute and allow any child parameter elements.  For
        example, xmldsig-allowAnyForeign.rnc allows any value for the
        Algorithm attribute of the DigestMethod element and any child
        parameter element.  However, when the Algorithm attribute value is
        explicitly specified in strict schemas, child parameter elements
        continue to be tightly constrained.
Schemas in this group are derived from XSD schemas not constraining
        the Algorithm attribute.  These schemas are used together with strict
        schemas.  These schemas are intended to exactly capture the original
        XSD schemas.
Schemas in this group define common patterns for RELAX NG.  These
        schemas are not derived from XSD schemas.  There is one common schema,
        namely security_any.rnc (security_any.rng).  It defines
        security_anyElement and security_anyAttribute, which allow any element
        and attribute, respectively.
Strict schemas provide strict definitions of the Algorithm attribute
        as well as permissible child elements.  For example, a strict schema
        xmldsig-core-schema.rnc has a definition shown below.  It specifies
        that "http://www.w3.org/2000/09/xmldsig#sha1" is allowed for the
        Algorithm attribute and an empty sequence of child elements are
        allowed.  This definition is used for defining attributes and contents
        of the DigestMethod element.
ds_DigestMethodType =
        attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2000/09/xmldsig#sha1" }
        
        Another definition (shown below) from the same schema specifies that either
Algorithm
          attribute and an optional HMACOutputLength element is allowed,Algorithm
          attribute and no child elements are  allowed, or Algorithm
        attribute and no child elements are  allowed.Note that RELAX NG allow the use of attribute definitions in the choice construct.
ds_SignatureMethodType =
        (attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2000/09/xmldsig#hmac-sha1" }, 
        element HMACOutputLength { ds_HMACOutputLengthType }?) 
        | attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2000/09/xmldsig#dsa-sha1" } 
        | attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2000/09/xmldsig#rsa-sha1" } 
        
        Furthermore, strict or supplementary schemas may extend definitions
        provided by other strict schemas.  This is done by the combine feature
        of [RELAXNG-SCHEMA].  For example, another strict schema,
        xmldsig11-schema.rnc, extends the definition ds_DigestMethodType in
        xmldsig-core-schema.rnc.
ds_DigestMethodType |=
        attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha256"
        }
        | attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2001/04/xmldsig-more#sha384"
        }
        | attribute Algorithm { 
        xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha512"
        }
        
        It specifies that "http://www.w3.org/2001/04/xmlenc#sha256",
        "http://www.w3.org/2001/04/xmldsig-more#sha384", and
        "http://www.w3.org/2001/04/xmlenc#sha512" are also allowed as 
        values of the Algorithm attribute.
Note that the original strict definition is NOT overshadowed.  
        The value "http://www.w3.org/2000/09/xmldsig#sha1" continues 
        to be allowed for the Algorithm attribute.
Lenient schemas provide lenient definitions of the Algorithm attribute as well
        as permissible child elements.  For example,
        xmldsig-allowAnyForeign.rnc has a definition shown below.  It
        specifies that any value except ds_DigestAlgorithms (see 3.1.3) is
        allowed for the Algorithm attribute and a possibly-empty sequence of
        foreign elements is allowed as the content.  Again, note that 
        the combine feature of  RELAX NG is used to combine strict 
        definitions and lenient definitions.
ds_DigestMethodType |=
        attribute Algorithm { xsd:anyURI - ds_DigestAlgorithms },
        ds_anyForeignElement*
      Lenient definitions do not allow any value except those explicitly allowed by strict schemas. This is done by the except pattern of RELAX NG.
The above lenient definition of ds_DigestMethodType contains "- ds_DigestAlgorithms". It is an except pattern, and allows any value except those matching ds_DigestAlgorithms, which is defined by the strict schema xmldsig-core-schema.rnc.
ds_DigestAlgorithms =
        xsd:anyURI "http://www.w3.org/2000/09/xmldsig#sha1"
        
        Since other strict schemas introduce other values for the Algorithm attribute, they also extend such definitions for the except pattern. For example, xmldsig11-schema.rnc, extends the above definition.
ds_DigestAlgorithms |=
        xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha256"
        | xsd:anyURI "http://www.w3.org/2001/04/xmldsig-more#sha384"
        | xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha512"
      Wildcard patterns, namely ds_anyForeignElement,
        dsig11_anyForeignElement, xenc_anyForeignElement, and
        xenc11_anyForeignElement, in driver schemas capture foreign elements.  These wildcard
        patterns are defined as elements not belonging to
        any of the known namespaces.
This subsection provides a list of driver schemas and also provides a list of included schemas for each driver schema.
Dated references below are to the latest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported.
No normative references.