W3C home > Mailing lists > Public > www-xkms-ws@w3.org > December 2001

Discussion Summary

From: Frederick Hirsch <hirsch@zolera.com>
Date: Tue, 4 Dec 2001 10:06:44 -0500
To: <www-xkms-ws@w3c.org>
Does this correctly summarize the discussion on the list since the last
requirements draft was released?
1. No service negotiation - simplify client

2. No optional fields, so client can depend on server features.
XML namespaces allow extensibility.

3. Avoid external dependencies, including WS-Security
 Track security issues and make available to web services group

4. Clarify draft
a.  what is mandatory and what is example,  e.g.. revoking key on recovery
is example policy and not mandated
b. Is AuthServerInfo necessary
c. Define/add security context

5. Clarify caching and asynchronous processing
Robustness issues, degree of definition in spec.

6. Make consistent with SAML
Allow request to include string to obtain RequestReference in Respond
1. Trust model/policy associated with URL
General agreement on list to associate a single trust model/policy with a
URI and to include this URI as context in all requests and responses
No need for dynamic management of trust model, configure applications and
keep it simple

WSDL complexity is not onerous since bindings separate from definitions

2. Need for server to support multiple PKI roots for client, client aware of
PKI root values?

3. Server should be able to adjust processing based on requestor origin or
Need to convey role information in request, open as to how.
1. Degree of SOAP linkage
If XKMS supports different transports, then XKMS should define self
contained protocol, including error responses and integrity.
This implies not relying on Faults, and allowing signatures within XKMS
itself, rather than relying on secured SOAP. Is this an open issue?

2. Support "Deferred Authentication" - request digest returned in signed
a. avoid redirect attacks, and simple server errors.
b. digest only XKMS itself (not SOAP wrapper)
c. only responses need be signed, requests may be, but don't need to be

3. Address replay attacks using nonce, incorporated in TransactionId

Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security
Received on Tuesday, 4 December 2001 10:03:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:48:00 UTC