REST binding for DSS

["Andreas Kuehne" <kuehne@trustable.de>]

Hi all, 

as promised in tha last call here are some thoughts on the pros and cons regarding a REST binding for DSS :
Motivation 
Many users are longing for an easymethod to access remote functionality. This demand is driven e.g. byAJAX web sites that correspond with server side services. The clientside implementation is expected to be light-weighted becauseJavascript Code embedded in a html page cannot use on a big softwarestack and refer to many libraries. So despite the 'S' ins SOAP thisprotocol isn't very simple to use here.


As a result many applications rely onthe REST protocol. It's principles are closely related to theorganization of the web itself :
There is a world of resources that canbe addressed by an URL and read by a GET request. Every resource hasits unique identification. For modification of the resources themethods POST, PUT and DELETE are available. Resources may berepresented in different formats. The different formats can beselected by the 'accept' request parameter.


REST on DSS
Applying the REST protocol to the DSStarget space there is a significant 'impedance' mismatch :


The signing operation is what it says,a stateless 'operation'. Delivered input data will be processed and asignature will be returned. No long-living resources are involved inthis use case. Moreover a second signing operation with the sameinput data will usually produce a different signature result(depending on signing time, used certificates, included timestamps,...). Signature operations are usually requested once only for giveninput data.
This arguments is even more obviouslytrue for timestamping!


In the domain of verification thesituation is different. The result of a verification is constant(within some limitations) and in some use cases (like code signatureverifications) the outcomes are requested multiple times. In thespecial case of W3C widget signatures the verification process can bevery complex (different XML signatures, different certificates), so acentralized verification service shows major advantages.


But still there is a problem of theresource identification. With all types of embedded signatures aunique id of the verification outcome can be derived from e.g. thehash value of the document. So a verification of a W3C widget couldbe as easy as deriving a hash and performing a simple GET call. Thiswould be offer a significant advantage over evaluating severalXMLDSig signatures, calling OCSPs and (very nasty) maintainingtrusted roots on the client. This is much more easier on a centralserver in both terms of caching and administration. For detachedsignatures the process of defining a resource id may be morecomplicated.


Another interesting advantage of RESTis the support for multiple representations of data. Using the'accept' header different clients may access HTML pages,DSS-conforming XML structures and PDF documents at the same URI.Additionally a JSON representation of the result would make life easyfor AJAX clients.


In the initial state there is noresource available for a GET request. A call will return the state'404'. The resource needs to be created using a POST request. Therequired data could be offered as a XML payload using the DSS schema.But the users of REST services usually are a bit XML-phobic and tendto call for an 'easy' protocol. So the interface could be strippeddown to simple name-value pairs for specific usage scenarios.


Conclusion
I would like to summarize that a RESTbinding for DSS could be useful in at least a subset of use cases. Onthe other hand there are some topics that need more investigation. 


So what's the opinion of group ? Start bulding a special profile ? Mention it in an informal document ? Forget about it ?

 
Greetings

Andreas

--
Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868

Directors Andreas Kühne Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales