- From: Frederick Hirsch <hirsch@zolera.com>
- Date: Tue, 4 Dec 2001 10:06:44 -0500
- To: <www-xkms-ws@w3c.org>
- Message-ID: <HNEILHLKDJAILJJBNELPGEKJCIAA.hirsch@zolera.com>
Does this correctly summarize the discussion on the list since the last requirements draft was released? Process 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 element. Server 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 role Need to convey role information in request, open as to how. Protocol 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 response 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