W3C home > Mailing lists > Public > www-xkms@w3.org > March 2002

Proposed spec changes

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 6 Mar 2002 12:32:31 -0800
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699C9@vhqpostal.verisign.com>
To: "'www-xkms@w3.org'" <www-xkms@w3.org>
I propose making the following changes to the spec

1. Removal of unnecessary design justification & explanatory material
	In particular the sections 'Design Philosophy' and 'Tiered Service

	Remove all reference to Tier 0
	Change references to Tier 1 and Tier 2 to XKISS Locate and XKISS

	[These were useful in the early stages of the draft but really refer
to the overarching TAXI design and are not really required here]

2. Reorganization of USER/SERVER Auth nonsense.
	This needs to be greatly streamlined.

	Introduce an attribute of <RegisterRequest GenerateKeyPair="True">
		Although presence of PoP can be used to decide this being
explicit has value.

3. Add in UseKeyWith Element

4. Add in Service URI

5. Add in bounds exceeded fault

6. Add in explanation of the version identifiers [Copy from SAML so we can
knife the whole package in one go if necessary.

7. Some additional explanation of the interpretation of Validity Interval,
wrt what it means if an 'invalid' response is returned. Here I am anxious to
avoid making the text too X.509 centric.

	We do need to do some additional explanation as to what to do with
specific requests and responses.

8. Use XML Encrypt for encrypting the private key

Outstanding Issues

	Require decision on how payload authentication is to be handled, in
particular whether by a SOAP header or a signature within the Request

	For establishing correspondence of response to a specific request.

	Need to decide on the format of the identifiers here, I am still
unsure as to what QNames do. In particular note that there are three types
of query that return <X509Data>; X509Cert, X509Chain and OCSP.

	We need to address this, how is XP getting on here?

	I forget can we delete this now?

	Needs to become Base64 data at the very least.

	Introduce section in the request/respons section that discusses the
SOAP binding issues, in particular SOAP faults.

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
781 245 6996 x227

Received on Wednesday, 6 March 2002 15:31:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:38 UTC