Re: [dss-x] Usage of ETSI Electronic Signatures Portal for DSS protocol interop event

[Andreas Kuehne <kuehne@trustable.de>]

Hi Juan Carlos,

> As agreed in our last call, I have sketched some few slides that may
> serve us for discussing how to use the ETSI portal for
> interoperability events on DSS protocol...
thanks for outlining the two major approaches!

Keeping with the XAdES-proven repository model would take advantage of
the infrastructure already in place and the participants can work
asynchronously. But the downside of this model is that the repository
would contain the two halves of the DSS call, a request and a response.
This would require a client taking part in the InterOp to be able to
process a response that he did _not_ initiated. And the server would
create a response to probably the same request any times.

So the problems with the repository approach are:
- In contrast to XAdES we deal with two distinct groups of participants:
clients and servers.
- In contrast to XAdES we deal with two distinct data objects: requests
and responses.
- The responses are expected to be processed (and thereby validated) by
a client that did NOT initiated the request.
- The dynamic aspects of the DSS protocol will get lost (e.g. uniqueness
of the request id). That would especially affect the tests of the
asynchronous protocol.

In the 'router' scenario you outlined that one client request will be
routed to a set of servers. I see the same problems here like the ones
mentioned above: A client is expecting a single response for a single
request. It is usually not capable of handling of bunch of responses.
And again the test of asynchronous protocol would be impossible.

So I would change the flow here to have a one-to-one relationship
between request and response. The clients must make a call for each and
every available server. This is a bit tricky, as the clients may not be
aware of the current set of servers. Moreover the 'router' is not aware
of the final outcome of the call.

Approach 'Repository of servers and outcomes'
A possible solution could be a additional interface for the client to
retrieve the list of servers and to feed back the outcome of the call to
the InterOp infrastructure. So the central part boils down to a
repository of servers and outcomes. Routing through a central instance
could be an option, but is not required. The direct connection between
client and server without the router could enable the testing of the DSS
protocol while using transport layer security or special transports like
Message Queues. This way the overall solution is like the the XAdES
scenario and not too much change is required on the portal side.

See an outline of this solution in the slides attached ...

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

Attachment: ETSIPortalForInterOp.ppt
Description: MS-Powerpoint presentation