[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: AW: RE: [dss-x] Fwd: Presentation client and server signature
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]