1. Capability to check each Reference to to see if the data object matches with the expected data object.
2. The cryptographic signature validation of the signature calculated over SignedInfo.
3. Reference validation, the verification of the digest contained in each Reference in SignedInfo.

Test Cases for C14N 1.1 and XMLDSig Interoperability
http://www.w3.org/2007/xmlsec/interop/xmlsig-interop-doc/testcases.html

3.1 Signature Generation

3.1.1 Reference Generation

3.1.2 Signature Generation

3.2 Core Validation

3.2.1 Reference Validation

3.2.2 Signature Validation

All?

4.1 The ds:CryptoBinary Simple Type

4.2 The Signature element

4.3 The SignatureValue Element

4.4 The SignedInfo Element

4.4.1 The CanonicalizationMethod Element
4.4.2 The SignatureMethod Element
4.4.3 The Reference Element

4.4.3.1 The URI Attribute
4.4.3.2 The Reference Processing Model
4.4.3.3 Same-Document URI-References
4.4.3.4 The Transforms Element
4.4.3.5 The DigestMethod Element
4.4.3.6 The DigestValue Element

4.5 The KeyInfo Element

4.5.1 The KeyName Element
4.5.2 The KeyValue Element

4.5.2.1 The DSAKeyValue Element
4.5.2.2 The RSAKeyValue Element
4.5.2.3 The ECKeyValue Element

4.5.2.3.1 Explicit Curve Parameters
4.5.2.3.2 Compatibility with RFC 4050

4.5.3 The RetrievalMethod Element
4.5.4 The X509Data Element

4.5.4.1 Distinguished Name Encoding Rules

4.5.5 The PGPData Element
4.5.6 The SPKIData Element
4.5.7 The MgmtData Element
4.5.8 XML Encryption EncryptedKey and DerivedKey Elements

4.5.9 The DEREncodedKeyValue Element
4.5.10 The KeyInfoReference Element

4.6 The Object Element

5.1 The Manifest Element

5.2 The SignatureProperties Element

5.3 Processing Instructions in Signature Elements

5.4 Comments in Signature Elements

6. Algorithms

6.1 Algorithm Identifiers and Implementation Requirements

6.2 Message Digests

6.2.1 SHA-1
6.2.2 SHA-256
6.2.3 SHA-384
6.2.4 SHA-512

6.3 Message Authentication Codes

6.3.1 HMAC

6.4 Signature Algorithms

6.4.1 DSA
6.4.2 RSA (PKCShttp://www.w3.org/TR/xmldsig-core1/#1 v1.5)
6.4.3 ECDSA

6.5 Canonicalization Algorithms

6.5.1 Canonical XML 1.0
6.5.2 Canonical XML 1.1
6.5.3 Exclusive XML Canonicalization 1.0

3.2 Test Cases for Canonicalization 1.1
        3.2.1 Test Cases for xml:lang attribute
        3.2.2 Test Cases for xml:space attribute
        3.2.3 Test Cases for xml:id attribute
        3.2.4 Test Cases for xml:base attribute
            3.2.4.1 Test Cases for checking xml:base attribute propagation
                3.2.4.1.1 Test case c14n11/xmlbase-prop-1
                3.2.4.1.2 Test case c14n11/xmlbase-prop-2
                3.2.4.1.3 Test case c14n11/xmlbase-prop-3
                3.2.4.1.4 Test case c14n11/xmlbase-prop-4
                3.2.4.1.5 Test case c14n11/xmlbase-prop-5
                3.2.4.1.6 Test case c14n11/xmlbase-prop-6
                3.2.4.1.7 Test case c14n11/xmlbase-prop-7
            3.2.4.2 Test Cases for checking XML-C14N1.1 specification tests
                3.2.4.2.1 Test case c14n11/xmlbase-c14n11spec-102
                3.2.4.2.2 Test case c14n11/xmlbase-c14n11spec2-102
                3.2.4.2.3 Test case c14n11/xmlbase-c14n11spec3-103
        3.2.5 Test Cases for checking examples in the XML-C14N1.1 Appendix

3.3.1 Test Cases for C14N 1.1 in XMLDSig

6.6 Transform Algorithms

6.6.1 Canonicalization
6.6.2 Base64
6.6.3 XPath Filtering
6.6.4 Enveloped Signature Transform
6.6.5 XSLT Transform

1. Data Model
   1. XPath 1.0 Recommendation [XPath] is used to represent the input XML
   2. F irst parameter of input to the XML canonicalization method is either an XPath node-set or an octet stream containing a well-formed XML document. 
   3. The second parameter of input to the XML canonicalization method is a boolean flag indicating whether or not comments should be included in the canonical form output by the XML canonicalization method.
   4. If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document.
   5. The input octet stream MUST contain a well-formed XML document, but the input need not be validated. 
   6. All whitespace within the root document element MUST be preserved (except for any #xD characters deleted by line delimiter normalization). This includes all whitespace in external entities. Whitespace outside of the root document element MUST be discarded.

3.2.1 Test Cases for xml:lang attribute
3.2.2 Test Cases for xml:space attribute
3.2.3 Test Cases for xml:id attribute
3.2.4 Test Cases for xml:base attribute

1. Document order is defined to be the order in which the first character of the XML representation of each node occurs in the XML representation of the document after expansion of general entities, except for namespace and attribute nodes whose document order is application-dependent.

1. The XPath node-set is converted into an octet stream, the canonical form, by generating the representative UCS characters for each node in the node-set in ascending document order, then encoding the result in UTF-8 (without a leading byte order mark).
2. No node is processed more than once. 
3. The text generated for a node is dependent on the node type and given in the following list:
   • Root Node- 
   • Element Nodes- 
     • Namespace Axis
     • Attribute Axis
   • Namespace Nodes
   • Attribute Nodes
   • Text Nodes
   • Processing Instruction (PI) Nodes
   • Comment Nodes

Does this apply to all test? What about tests for all node types in the list in the recommendation?

 3.2.4.1 Test Cases for checking xml:base attribute propagation
      3.2.4.1.1 Test case c14n11/xmlbase-prop-1
      3.2.4.1.2 Test case c14n11/xmlbase-prop-2
       3.2.4.1.3 Test case c14n11/xmlbase-prop-3
       3.2.4.1.4 Test case c14n11/xmlbase-prop-4
       3.2.4.1.5 Test case c14n11/xmlbase-prop-5
       3.2.4.1.6 Test case c14n11/xmlbase-prop-6
       3.2.4.1.7 Test case c14n11/xmlbase-prop-7

3.2 Test Cases for Canonicalization 1.1
 The input for each of these test cases is an XML document and an XPath document subset expression.