Requirements & issue list updated

All,

Thanks to Frederick and Mike, a new version of the XKMS requirements document 
(editor's copy) [1] + a table of last call issues [2] are up on the site.

From: Frederick Hirsch <hirsch@fjhirsch.com>

Changes:

1) Changed requirements 2.1.4 and 2.1.5 as discussed on list:

2.1.4 The specification MUST provide a binding to XML Protocol (SOAP 
1.2), provided that the SOAP 1.2 specification has reached Candidate 
Recommendation (CR) status prior to the XKMS WG completing its work. In 
this case the specification SHOULD also provide a binding to SOAP 1.1 
(for interoperability purposes). If SOAP 1.2 has not reached CR status 
then the specification MUST provide a binding to SOAP 1.1. The XKMS 
specification SOAP binding is required to profile SOAP for 
interoperability, including use of document literal encoding. [ SOAP ] 
[XMLProtocol] [List( Blair Dillaway)].

2.1.5 XKMS services MUST implement SOAP 1.2 once that specification has 
achieved Candidate Recommendation status.

2) Updated 2.5.4 to reflect Yassir's comment (also minor modification to 
Sebastian's spelling, lowercase e)

2.5.4 The following KeyInfo formats MUST be supported: KeyName, 
KeyValue, RetrievalMethod and MgmtData. The X509Certificate KeyInfo 
format MUST be supported by a trust server if the service claims 
interoperability with PKIX X.509. Additional KeyInfo formats such as 
X509Chain, OCSP, and X509CRL MAY be supported. X509Chain and OCSP MUST 
be defined in the XKMS specifications. X509CRL is defined in the XML 
Signature recommendation. The XKMS registration Private format MUST be 
supported if the service supports either service generated key pairs or 
key recovery.[List( Sebastien Pouliot)]

3) Added paragraph to introduction to address anonymous concerns 
regarding relationship to traditional PKI technologies:

XML key management services will primarily be of interest to clients 
that intend to communicate using XML-based protocols bound to SOAP. It 
may be that such clients will not have sufficient ASN.1 capabilities in 
which case the benefits of offloading the parsing of certificates and 
other traditional PKI structures (e.g. CRLs or OCSP responses) is clear. 
Clients which possess such capabilities and have no preference to work 
with XML-based protocols may opt to use non-XML-based protocols defined 
by PKIX, for example.

4) Fixed registration symbol on W3C in copyright statement

5) Fixed broken links.

I have updated the issues list for the XKMS Requirements updating the 
wording to reflect the resolution of issues, including the discussion on 
the list.

I've added hyperlinks to the minutes and the resolution emails.

[1]  http://www.w3.org/2001/XKMS/Drafts/xkms-req.html
[2]  http://www.w3.org/2001/XKMS/Drafts/xkms-rqmts-issues.html


Please send comments to the list.

Thanks

/Shivaram
_______________________________________________________________________________
Shivaram H. Mysore <shivaram.mysore@sun.com>

Software Engineer 				Co-Chair, W3C's XKMS WG			
Java Card Engineering				http://www.w3.org/2001/XKMS			
JavaSoft, Sun Microsystems Inc.	

Direct: (408)276-7524
Fax:    (408)276-7608

http://java.sun.com/people/shivaram  (Internal: http://mysore.sfbay/)		
_______________________________________________________________________________

Received on Thursday, 23 May 2002 15:11:25 UTC