- From: Hallam-Baker, Phillip <pbaker@verisign.com>
- Date: Wed, 6 Mar 2002 12:32:31 -0800
- To: "'www-xkms@w3.org'" <www-xkms@w3.org>
- Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058699C9@vhqpostal.verisign.com>
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
Attachments
- application/octet-stream attachment: Phillip_Hallam-Baker__E-mail_.vcf
Received on Wednesday, 6 March 2002 15:31:43 UTC