Re: Discussion Summary

Frederick,

Good summary, thanks. I think we'll probably visit these topics
at the F2F sunday,

Regards,
Stephen.

> Frederick Hirsch wrote:
> 
> 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
> 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Received on Wednesday, 5 December 2001 11:29:19 UTC