REST binding ?

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

Hi all,

we're facing some client demand on REST binding for DSS-like interfaces. Did anyone in the group already worked in this topic ?

Most of the reasons for REST don't sound valid to me ' .. SOAP is bad ... REST is good .. and got more performance ..' But if the client asks for it ...

Designing a REST interface for signing doesn't make real sense to me, as the document to be represented by REST doesn't really exist on a signature server. It's a pure procedure call, no 'State' (the 'S' in REST) involved.

With verification things turned out to be more useful. A signature or the signed document could be seen as the 'State' and the service could return verification information on it. A URL may look like this :

POST http://{server}/dss/rest/verificationStatus/SHA-256:{unique_hash}?signature={sig-value} 

The document could be identified by its hash value, the signature and other information will be passed as parameters to a POST request.

This call could create the stateful object by performing the verification. Subsequent calls of the type 'GET'

GET http://{server}/dss/rest/verificationStatus/SHA-256:{unique_hash}

will return the verification outcome. This may especially be handy for verifications that will be done several times on he same document, like code signing or dkim messages. And in fact a REST call may use up little less network and may require a smaller software stack ...

So to me I does make sense to start thinking about standardizing a REST binding for DSS. What's the groups opinions / experiences  ?

Greetings

Andreas