Re: [dss] Notification method for asynchronous processing profile

[Tommy Lindberg <tommy.lindberg@gmail.com>]

Hi Andreas -

Thanks for your answer.

>E.g. it would be easy to misuse a Async server as an DDOS relay or to
>use it for some kind of spam mailing. We decided to come back to this
>functionality once there is more light in the area of authorization /
>authentication .

There are several options; <dss:ClaimedIdentity>,
wss:UsernameToken w SSL when used with a Soap binding (other WSS
mechanisms would require technology that a typical DSS does not have
access to),  Basic Auth tunneled through SSL, SSL client auth,
perhaps even network address.

What a deployment uses, is probably covered by the service policy and
should not not be specified by the DSS Asynch profile.  However,
profiles derived from the Asynch profile could provide specifics
concerning authentication but that is another matter and was not what I
intended to address.

>Are there some comments on authorization / authentication in XKMS we can
>borrow, too ?

Similar to the above.

Regards,
Tommy

On 9/30/05, Andreas Kuehne <kuehne@klup.de> wrote:

Hi Tommy !


> > A notification mechanism isn't defined yet, but may be subject to
> following
> > versions of this profile.
>
> Hope its ok to take initiative ;)

Never mind, anyone elses effort is always welcome ;-)

> 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.
>
We discussed the request of notification in the early days of DSS and
deferred this issue until the core is finished.  The main  concern was
that the server is forced to do external invocation that may be harmful.
E.g. it would be easy to misuse a Async server as an DDOS relay or to
use it for some kind of spam mailing. We decided to come back to this
functionality once there is more light in the area of authorization /
authentication .

> 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
> carry
> the required information.  The element should be advisory only; the
> service
> decides whether or not it will honor the request for notification.
>
> xmlns:async="urn:oasis:names:tc:dss:1.0:profiles:asynchronousprocessing:1.0"
>
> <!-- NotificationMethod -->
> <element name="NotificationMethod" type="async:NotificationMethodType"/>
> <complexType name="NotificationMethodType">
>   <attribute name="Protocol" type="anyURI" use="required"/>
>   <attribute name="Identifier" type="anyURI" use="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 = "urn:ietf:rfc:822"  Identifier =
> valid e-mail address, starting with mailto:.
> Notification by http:  Protocol = "urn:ietf:rfc:2616" Identifier =
> 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.
>
Yes, sounds good. I especially like the procedure if borrowing from XKMS !
Are there some comments on authorization / authentication in XKMS we can
borrow, too ?

Greetings
Andreas