OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dss] Notification method for asynchronous processing profile


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]