elements. It contains the basic information shared by subclasses and remaining persistent during the process from input document retrieval until digest calculation for the relevant document. It contains the following elements and attributes:
ID [Optional]
This identifier gives the input document a unique label within a particular request message. Through this identifier, an optional input (see sections 2.7, 3.5.6 and 3.5.8) can refer to a particular input document.
RefURI [Optional]
This specifies the value for a element’s URI attribute when referring to this input document. The RefURI attribute SHOULD be specified; no more than one RefURI attribute may be omitted in a single signing request.
RefType [Optional]
This specifies the value for a element’s Type attribute when referring to this input document.
SchemaRefs [Optional]:
The identified schemas are to be used to identify ID attributes during parsing in sections 2.5.2, 3.3.1 1.a and 4.3 and for XPath evaluation in sections 2.6, 3.5.7, 4.3.1. If anything else but are referred to, the server MUST report an error. If a referred to is not used by the XML document instance this MAY be ignored or reported to the client in the / (for the definition of see 2.8.5 or 2.9.1 on ).
The Document is assumed to be valid against the first referred to by SchemaRefs.
If a element is referred to first by SchemaRefs the document is assumed to be valid against the first inside . In both cases, the remaining schemas may occur in any order and are used either directly or indirectly by the first schema.
If present, the server MUST use the schemas to identify the ID attributes and MAY also perform complete validation against the schemas.
Note: It is recommended to use xml:id as defined in [xml:id] as id in the payload being referenced by a , because the schema then does not have to be supplied for identifying the ID attributes.
2.4.2Element
The element may contain the following elements (in addition to the common ones listed in section 2.4.1):
If the content inside one of the following mutually exclusive elements , or is not parseable XML data, after appropriate decoding, then the server MUST return a (section 2.6) issuing a RequesterError qualified by a NotParseableXMLDocument.
The server MUST use the referred by for validation if specified.
[Optional] [Default]
This contains a base64 string obtained after base64 encoding of a XML data. The server MUST decode it to obtain the XML data.
[Optional]
The InlineXMLType clearly expresses the fact, that content of is inline XML that should be equivalent to a complete XML Document. I.e. having only one DocumentElement (see section 2.1 Well-Formed XML Documents [XML]) and not allowing anything but PI's and Comments before and after this one element.
It may contain the ignorePIs and ignoreComments attributes. These attributes apply to the complete document and indicate respectively, if processing instructions or comments MAY be ignored.
If one or both of these attributes are not present, their values MUST be considered to be "true".
InlineXML will work with PIs and/or Comments if ignorePIs and ignoreComments are false respectively and if the server supports such behavior.
[Optional]
This contains an escaped string. The server MUST unescape (escape sequences are processed to produce original XML sequence) it for obtaining XML data.
[Optional]
This contains a base64 encoding of data that are not XML. The type of data is specified by its MimeType attribute, that may be required when using DSS with other signature types.
[Optional]
This contains a reference to an attachment like SOAP attachments or similar data containers that may be passed along with the request. For details see section 6.2.1
use="optional">
use="optional" default="true"/>
use="optional" default="true"/>
2.4.3Element
The element contains the following elements (in addition to the common ones listed in section 2.4.1):
[Required on a SignRequest] [Optional on VerifyRequest]
This is the sequence of transforms applied by the client and specifies the value for a element’s child element. In other words, this specifies transforms that the client has already applied to the input document before the server will hash it.
[Required]
This gives the binary output of a sequence of transforms to be hashed at the server side.
WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest]
As there may be multiple TransformedData / DocumentHash elements of the same document having the same URI [RFC 2396] and RefType on a SignRequest or VerifyRequest - their correspondance to an already existing however needs to be established on a VerifyRequest only.
There is a need to disambiguate such cases. This Attribute hence offers a way to clearly identify the when URI and RefType match multiple ds:References / TransformedData / DocumentHash. The corresponding ds:Reference is indicated by this zero-based WhichReference attribute (0 means the first in the signature, 1 means the second, and so on).
Note: It may be possible to establish the ds:References / TransformedData / DocumentHash correspondence by comparing the optionally supplied chain of transforms to those of the ds:References having the same URI and RefType in the supplied ds:Signature if this chain of transform has been supplied. This can be quite expensive and even out the advantages of TransformedData / DocumentHash.
use="optional"/>
2.4.4Element
The element contains the following elements (in addition to the common ones listed in section 2.4.1):
[Required on a SignRequest] [Optional on VerifyRequest]
This specifies the value for a element’s child element when referring to this document hash. In other words, this specifies transforms that the client has already applied to the input document before hashing it.
[Required on a SignRequest] [Optional on VerifyRequest]
This identifies the digest algorithm used to hash the document at the client side. This specifies the value for a element’s child element when referring to this input document.
[Required]
This gives the document’s hash value. This specifies the value for a element’s child element when referring to this input document.
WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest]
As there may be multiple TransformedData / DocumentHash elements of the same document having the same URI and RefType on a SignRequest or VerifyRequest - their correspondance to an already existing however needs to be established on a VerifyRequest only.
There is a need to disambiguate such cases. This Attribute hence offers a way to clearly identify the when URI and RefType match multiple ds:References / TransformedData / DocumentHash. The corresponding ds:Reference is indicated by this zero-based WhichReference attribute (0 means the first in the signature, 1 means the second, and so on).
use="optional"/>