Summary of some security and robustness issues

WRT the ongoing discussion, attached is an attempt to set out the arguments
on security, deadlock etc. in a broader fashion.
 
In response to Mike Just's point on the TransactionID, yes we should add in
a <Respond> tag, actually if we are to align with SAML that would become the
<RespondWith> element (people thought the name confussing there it is
probably less so if the protocols agree on a common useage).
 
Clearly it should not be necessary to add in <transactionID> unless the
requestor absolutely does not want a cached response
 
See also the discussion in the paper on the use of deferred authentication
in the paper, If I sign the request with an SHA-1 then I could check for the
same value in the response (assuming I am not using cached data).
 
Basically what the paper comes down to is that you have to be quite carefull
about the decision to support caching, the costs of implementation rise
significantly. It may well be that many XKMS client applications will not
benefit from non-repudiation on responses because they don't have the
archival store, consequently such applications should probably be using an
XKASS key agreement and HMAC authentication approach and thus the need for
caching the response tokens pretty much goes away.
 
That is not to say that FORWARDING of XKMS tokens will not be really useful
in applications like payement schemes where there is the support for
non-repudiation etc.
 
        Phill