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



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

2.1Type AnyType


The AnyType complex type allows arbitrary XML element content within an element of this type (see section 3.2.1 Element Content [XML]).





minOccurs="0"

maxOccurs="unbounded"/>




2.2Type InternationalStringType


The InternationalStringType complex type attaches an xml:lang attribute to a human-readable string to specify the string’s language.














2.3Type saml:NameIdentifierType


The saml:NameIdentifierType complex type is used where different types of names are needed (such as email addresses, Distinguished Names, etc.). This type is borrowed from [SAMLCore1.1] section 2.4.2.2. It consists of a string with the following attributes:

NameQualifier [Optional]

The security or administrative domain that qualifies the name of the subject. This attribute provides a means to federate names from disparate user stores without collision.

Format [Optional]

A URI [RFC 2396] reference representing the format in which the string is provided. See section 7.3 of [SAMLCore1.1] for some URI references that may be used as the value of the Format attribute.

2.4Element


The element is used to send input documents to a DSS server, whether for signing or verifying. An input document can be any piece of data that can be used as input to a signature or timestamp calculation. An input document can even be a signature or timestamp (for example, a pre-existing signature can be counter-signed or timestamped). An input document could also be a , allowing the client to handle manifest creation while using the server to create the rest of the signature. Manifest validation is supported by an optional input / output.

The element consists of any number of the following elements:



[Any Number]

It contains a document as specified in section 2.4.2 of this document.



[Any Number]

This contains the binary output of a chain of transforms applied by a client as specified in section 2.4.3 of this document.



[Any Number]

This contains the hash value of an XML document or some other data after a client has applied a sequence of transforms and also computed a hash value as specified in section 2.4.4 of this document.



Other may contain arbitrary content that may be specified in a profile and can also be used to extend the Protocol for details see section 2.1.





When using DSS to create or verify XML signatures, each input document will usually correspond to a single element. Thus, in the descriptions below of the , and elements, it is explained how certain elements and attributes of a , and correspond to components of a .


2.4.1Type DocumentBaseType


The DocumentBaseType complex type is subclassed by , and 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"/>




Спампаваць 0.54 Mb.

Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10   11



База данных защищена авторским правом ©shkola.of.by 2022
звярнуцца да адміністрацыі
    Галоўная старонка
Guide
Instructions
Report
Request
Review