RE: XKMS

That sounds like a good idea. One might argue that XKMS already has the
<Respond> element for returning elements sent as part of the request but
<Respond> doesn't cover items such as the Transaction ID and the service
URL.  Phill's <SigningContext> element (from
http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0065.html) would add
these items. However, <Respond> doesn't return additional elements such as
<KeyId> that might be sent as part of a <Query>. It seems safest to allow
the return of the hash of the entire request (or else someone will likely
break/attack any partial solution).

As for how the client requests this, maybe it could be another <Respond>
option; something like 
<Respond>
	RequestReference
</Respond>
which would return an XMLDSig reference element computed over the entire
client request.
Phill's <SigningContext> would still be required I believe; at least for the
service URL (unless we decide to include this as part of the request schema
as well).

(I might have thought that it would be mandatory to include the
RequestReference for the most secure operation, but if the session were
protected by TLS, for example, then some correspondence between the request
and response would already be provided. The spec would have to indicate
these security issues/options of course.)

Mike


> -----Original Message-----
> From: Rich Salz [mailto:rsalz@zolera.com]
> Sent: Tuesday, November 27, 2001 11:53 AM
> To: Mike Just
> Cc: 'www-xkms-ws@w3c.org'
> Subject: Re: XKMS
> 
> 
> That makes sense -- the server can return an element XMLDSIG Reference
> element for the client request -- but how can the client indicate it
> wants that? Or is that left as a quality of implementation issue?
> 	/r$
> 
> -- 
> Zolera Systems, Your Key to Online Integrity
> Securing Web services: XML, SOAP, Dig-sig, Encryption
> http://www.zolera.com
>