RE: Proposed spec changes

Looks excellent Phill.  A couple of comments from my notes of the Dec '01
F2F.

- I think we did decide to remove <xkms:KeyID>.

- We were going to include some way of dealing with a Pending response (only
makes sense to consider for <Register> or <ReIssue>).

- I believe we were going to allow the client to set a limit on the number
of "Multiple" responses that might be returned. The server would have to
indicate whether there were more responses that weren't sent because the
limit would have been exceeded.

Mike

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Wednesday, March 06, 2002 3:33 PM
To: 'www-xkms@w3.org'
Subject: Proposed spec changes


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
Model'

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

	[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

[I-PayloadAuth]
	Require decision on how payload authentication is to be handled, in
particular whether by a SOAP header or a signature within the Request
packet.

[I-PayloadHash]
	For establishing correspondence of response to a specific request.

[I-RespondWith]
	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.

[I-FaultHandling]
	We need to address this, how is XP getting on here?

[I-KeyID]
	I forget can we delete this now?

[I-Passphrase]
	Needs to become Base64 data at the very least.

[I-SOAP]
	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.
pbaker@verisign.com
781 245 6996 x227