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




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

2.7Elements and


All request messages can contain an element, and all response messages can contain an element. Several optional inputs and outputs are defined in this document, and profiles can define additional ones.

The contains additional inputs associated with the processing of the request. Profiles will specify the allowed optional inputs and their default values. The definition of an optional input MAY include a default value, so that a client may omit the yet still get service from any profile-compliant DSS server.

If a server doesn’t recognize or can’t handle any optional input, it MUST reject the request with a code of RequesterError and a code of NotSupported (see section 2.6).

The element contains additional protocol outputs. The client MAY request the server to respond with certain optional outputs by sending certain optional inputs. The server MAY also respond with outputs the client didn’t request, depending on the server’s profile and policy.

The and elements contain unordered inputs and outputs. Applications MUST be able to handle optional inputs or outputs appearing in any order within these elements. Normally, there will only be at most one occurrence of any particular optional input or output within a protocol message. Where multiple occurrences of an optional input (e.g. in section 3.5.6) or optional output are allowed, it will be explicitly specified (see section 4.5.9 for an example).

The following schema fragment defines the and elements:





2.8Common Optional Inputs


These optional inputs can be used with both the signing protocol and the verifying protocol.

2.8.1Optional Input


The element indicates a particular policy associated with the DSS service. The policy may include information on the characteristics of the server that are not covered by the Profile attribute (see sections 3.1 and 4.1). The element may be used to select a specific policy if a service supports multiple policies for a specific profile, or as a sanity-check to make sure the server implements the policy the client expects.


2.8.2Optional Input


The element indicates the identity of the client who is making a request. The server may use this to parameterize any aspect of its processing. Profiles that make use of this element MUST define its semantics.

The child element can be used by profiles to carry information related to the claimed identity. One possible use of is to carry authentication data that authenticates the request as originating from the claimed identity (examples of authentication data include a password or SAML Assertion [SAMLCore1.1], or a signature or MAC calculated over the request using a client key).

The claimed identity may be authenticated using the security binding, according to section 6, or using authentication data provided in the element. The server MUST check that the asserted is authenticated before relying upon the .









minOccurs=”0”/>








2.8.3Optional Input


The element indicates which language the client would like to receive InternationalStringType values in. The server should return appropriately localized strings, if possible.


2.8.4Optional Input


The element can appear multiple times in a request. It indicates additional profiles which modify the main profile specified by the Profile attribute (thus the Profile attribute MUST be present; see sections 3.1 and 4.1 for details of this attribute). The interpretation of additional profiles is determined by the main profile.


2.8.5Optional Input


The element provides an in band mechanism for communicating XML schemas required for validating an XML document.












An XML schema is itself an XML document, however, only the following attributes, defined in dss:DocumentType, are meaningful for the element:

ID

Used by relying XML document to identify a schema.



RefURI

The target namespace of the schema (i.e. the value of the targetNamespace attribute).

RefType

MUST NOT be used.



SchemaRefs

MUST NOT be used.

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.9Common Optional Outputs


These optional outputs can be used with both the signing protocol and the verifying protocol.

2.9.1Optional Output


The element is typically used as an optional input in a . However, there are situations where it may be used as an optional output. For example, a service that makes use of the mechanism may, after verifying a signature over an input document, generate a signature over a document of a different schema than the input document. In this case the element MAY be used to communicate the XML schemas required for validating the returned XML document.

For a description of the element see section 2.8.5.


1   2   3   4   5   6   7   8   9   10   11


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

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