This document defines protocol profiles and
processing profiles for the purpose of creating and verifying German Signature
Law signatures.

Status:

This document was last revised or approved
by the OASIS Digital Signature Services TC on the above date. The level of
approval is also listed above. Check the current location noted above for
possible later revisions of this document. This document is updated
periodically on no particular schedule.

Technical Committee members should send
comments on this specification to the Technical Committee’s email list. Others
should send comments to the Technical Committee by using the “Send A Comment”
button on the Technical Committee’s web page at http://www.oasis-open.org/committees/dss.

For information on whether any patents have
been disclosed that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the Intellectual Property
Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/dss/ipr.php.

The non-normative errata page for this
specification is located at http://www.oasis-open.org/committees/dss.

Notices

OASIS takes no position regarding the
validity or scope of any intellectual property or other rights that might be
claimed to pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any effort
to identify any such rights. Information on OASIS's procedures with respect to
rights in OASIS specifications can be found at the OASIS website. Copies of
claims of rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by implementors or
users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring
to its attention any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required to implement
this specification. Please address the information to the OASIS Executive
Director.

This document and translations of it may be
copied and furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or references
to OASIS, except as needed for the purpose of developing OASIS specifications,
in which case the procedures for copyrights defined in the OASIS Intellectual
Property Rights document must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are
perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained
herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The names "OASIS" are trademarks of
OASIS, the owner and developer of this specification, and should be used only
to refer to the organization and its official outputs. OASIS welcomes reference
to, and implementation and use of, specifications, while reserving the right to
enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php
for above guidance.

This is an abstract profile.
Further profiles will build on this one to provide a basis for implementation
and interoperability.

This draft profiles the OASIS DSS core
protocol for asynchronous processing. Although most applications of the OASIS
Digital Signature Service supply the results immediately there is a demand for
deferred delivering of results. E.g. the German Signature Law explicitly
requires the commitment of the certificate holder or at least a time slot for
the certificate holder to deny the signing request [SigG].

Another use case for a asynchronous
protocol may arise in a verification request if a minimum latency between
creation and verification has to be respected.

This profile is intended to be generic, so
it may be combined with other profiles freely.

A protocol for asynchronous processing is
already defined in the XML Key Management Specification [XKMS]. This
profile borrows ideas from the XKMS protocol for the OASIS Digital Signature
Service.

The following sections describe how to
understand the rest of this document.

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this specification are to be interpreted as described in IETF RFC
2119 [RFC 2119]. These keywords are capitalized
when used to unambiguously specify requirements over protocol features and
behavior that affect the interoperability and security of implementations.
When these words are not capitalized, they are meant in their natural-language
sense.

This specification uses the following
typographical conventions in text: <ns:Element>, Attribute, Datatype, OtherCode.

The structures described in this
specification are contained in the schema file [XYZ-XSD]. All schema
listings in the current document are excerpts from the schema file. In the
case of a disagreement between the schema file and this document, the schema
file takes precedence.

This schema is associated with the
following XML namespace:

urn:oasis:names:tc:dss:1.0:profiles:asynchronousprocessing:1.0

If a future version of this specification
is needed, it will use a different namespace.

Applications MAY use different namespace
prefixes, and MAY use whatever namespace defaulting/scoping conventions they
desire, as long as they are compliant with the Namespaces in XML specification [XML-ns].

This profile defines a simple mechanism for
asynchronous signing and verification requests. This profile is similar to
the asynchronous processing protocol defined in the XKMS spec [XKMS].

In the first call the client supplies its
input values as defined in the core and the applied profiles. The
server may reply synchronously with the appropriate result.

On the other hand the server may reply with an ‘empty’ result, giving
the <ResultMajor> code ‘Pending’ and a <async:ResponseID> element as an <OptionalOutput>. The server generates
the value of the <async:ResponseID>
on
its own.

The client may initiate a <PendingRequest> call from time to time
with the <async:ResponseID> of the initial
response included in the <async:ResponseID> element within the <dss:OptionalInputs>.

When the server finally succeeds with its processing the results will be
delivered to the client with its next polling call. In this case the <ResultMajor> must not be ‘Pending’ but the <ResultMajor> resulting from the request
processing.

A notification mechanism isn’t defined yet, but may be subject to
following versions of this profile.

The polling protocol extends the core
protocol using the <PendingRequest> element for initiating a polling request. This is different from
the initial request because the request specific data was already transmitted.

The <PendingRequest> element is sent by the client to request the result from a pending
signature or verification initiated earlier. It contains the following attributes
and elements inherited from <RequestBaseType>:

RequestID[Optional]

This attribute is used to
correlate requests with responses. When present in a request, the server MUST
return it in the response.

Profile[Optional]

This attribute indicates a
particular DSS profile. It may be used to select a profile if a server supports
multiple profiles, or as a sanity-check to make sure the server implements the
profile the client expects. In this special case of a <PendingRequest> the required profile information is already defined within the
initial call to the server. So ProfileMUST be omitted
in a <PendingRequest>. Consequently there MUST NOT be any <AdditionalProfile> optional
input elements in a <PendingRequest>.

<OptionalInputs>[Optional]

Any additional inputs to the
request. This element may be used e.g. for authentication data.

In addition to <RequestBaseType> the <PendingRequest> element defines the following <ResponseID>
element:

To correlate subsequent<PendingRequest> calls
to the initial request the <async:ResponseID> element is
introduced by this profile. The client MUST take care of the value returned by the initial <SignRequest> in <async:ResponseID>.

This result value means that the operation
did not finish yet. Subsequent requests may return this result code again.
After the server has finished the operation the call will return the signing
result indicated by the urn:oasis:names:tc:dss:1.0:resultmajor:Success
value or an error code.

In case an asynchronous service is unable
to reply in a synchronous manner and a requests to this service is made without
profiling the call as asynchronous ( using the given profile identifier within
the Profile attribute or the <AdditionalProfiles> element ), the service returns a <ResultMajor> of RequesterError
and a <ResultMinor> of:

This profile defines the new optional
output element of <async:ResponseID>.

<async:ResponseID>

To correlate subsequent<PendingRequest> calls
to the initial request the <async:ResponseID> element is
introduced by this profile. The service will generate a suitable value on its own behalf. So
the client MUST take care of the value returned in <async:ResponseID>
for subsequent <PendingRequest>.

This result value means that the operation
did not finish yet. Subsequent requests may return this result code again.
After the server has finished the operation the call will return the
verification result indicated by the urn:oasis:names:tc:dss:1.0:resultmajor:Success value
or an error code.

In case an asynchronous service is unable
to reply in a synchronous manner and a requests to this service is made without
profiling the call as asynchronous ( using the given profile identifier within
the Profile attribute or the <AdditionalProfiles> element ), the service returns a <ResultMajor> of RequesterError
and a <ResultMinor> of:

This profile defines the new optional
output element of <async:ResponseID>.

<async:ResponseID>

To correlate subsequent<PendingRequest> calls
to the initial request the <async:ResponseID> element is
introduced by this profile. The service will generate a suitable value on its own behalf. So
the client MUST take care of the value returned in <async:ResponseID>
for subsequent <PendingRequest>.

The server return a <dss :ResultMajor> value
‘Pending’ with no Signature returned. So the client will send a PendingRequest
using the value of <async:ResponseID> from this response. A
PendingRequest may look like this :