[no subject]

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

Hope its ok to take initiative ;)

When requesting asynchronous processing of Sign or Verify requests, it
may in some situations be useful to, instead of polling the service for
completion of processing, be notified of the termination of a Request.

To this end, and continuing to borrow from XKMS, I am proposing the
inclusion
of an optional input in the asynchronous processing profile that would carr=
y
the required information. The element should be advisory only; the service
decides whether or not it will honor the request for notification.

xmlns:async=3D"urn:oasis:names:tc:dss:1.0:profiles:asynchronousprocessing:1=
.0"

<!-- NotificationMethod -->
<element name=3D"NotificationMethod" type=3D"async:NotificationMethodType"/=
>
<complexType name=3D"NotificationMethodType">
<attribute name=3D"Protocol" type=3D"anyURI" use=3D"required"/>
<attribute name=3D"Identifier" type=3D"anyURI" use=3D"required"/>
</complexType>
<!-- /NotificationMethod -->

The Asynchronous profile can initially support a number of predefined
notification
protocol's. The syntax of the Identifier is determined by the Protocol.

Examples of Protocol/Identifier pairs.

Notification by email: Protocol =3D "urn:ietf:rfc:822" Identifier =3D valid
e-mail address, starting with mailto:.
Notification by http: Protocol =3D "urn:ietf:rfc:2616" Identifier =3D valid=
 URL,
starting with http:.

An associated optional output could potentially be defined and would carry
an indication
as to whether or not the service will honor the request for notifcation -
this would be part
of the Response to the initial request.

Regards,
Tommy

------=_Part_5417_6366696.1128016443384
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline