Re: AW: AW: RE: [dss-x] Fwd: Presentation client and server signature

[kuehne@trustable.de]

Hi Detlef,

on top of the already discussed topics I would like to add another :
For a more general use case we need some way of declaration of the certificates / keys available at the PAOS server side. There may be different users logging into a central instance looking for signable requests. These different PAOS server shouldn't recieve randomly choosen requests. So we should define the message containing a key info set when declaring the availability of a POAS server. 

Oscar may get away without such a mechnism as the card holder itself issues the request. But for the 'supervisor/notary' scenario we need a way to metch pending requests with the avialbale keys.

Find my other remarks intermixed :

> > thanks for pointing out the POAS spec. It's adressing the problem Oscar
> > outlined in his presentation.
> 
> It's true that PAOS introduces some overhead due to 
> 1) the fact that one needs n+1 HTTP request/response pairs
>      to transport n SOAP-request/response pairs from the server to the
> client
> 2) some additional header information.
> 
> While 1) means that one needs two request/response pairs to send one
> message,
> the overhead induced by 2) seems to be negligible (with respect to the
> verbosity of SOAP). 
Verbosity of SOAP shouldn't be a reason for messy designs ;-)
A colleague once said 'if you once die, you'll die from latency !' Or in other words : You may fight volume and complexity by higher bandwith and more processing power. But you cannot easy the pain of the turn-around time. You'll hve to pay a toll of a hundred milliseconds ..
Moreover we just transport one request, not a bunch of requests at a time ...

> > Nevertheless I'm a bit astound about the burden this spec puts on a
> client
> > willing to use. The user agent has to state his support for POAS. Maybe
> the
> > agent hasn't got any idea about it, but some lines of javascript are
> enough to
> > do the job perfectly. So the binding cannot be used for formal reasons.
> 
> What do you mean with "formal reasons"? 
I'm unsure about this topix, now. Last week I thought it's the responsibility of the user agent ( e.g. firefox ) to declare the support for PAOS. But in the meantime I came across the possibility to set arbitrary headers of the XHR. But I didn't succeed to check whether the corresponding header can be set / overwritten by a XHR.
So hopefully this topic just fades away ,,,

> > In favour not to reinvent the wheel again dtmo there is no need to do on
> the
> > DSS side.I guess we don't need to enumrate all possible binding ...
> 
> For interoperability reasons, we certainly need to enumerate the bindings,
> which
> MAY, SHOULD or MUST be supported in a certain situation. Furthermore I
> would
> strongly
> recommend that the PAOS-binding should be among the set of bindings
> mentioned
> in a "DSS Client Profile", but we certainly can discuss this in the meeting
> today.
Interesting, looking forward to hear your reasons ..

Greetings

Andreas