Comments on requirements draft

I finally got around to reviewing the requirements draft.  My thanks to
Frederick and Mike for their efforts.  Looks pretty good but I have a
few issues/questions.  I'll try not to repeat editorial issues already
posted 

2.1.3 - This should be changed to indicate we'll provide a binding to
SOAP 1.1 and will migrate to XML Protocol once defined.  This is
consistent with language latter on in the spec.

2.1 - I'd like to add another item to this list stating the design will
be transport protocol agnostic.

2.2.4 - Add a statement that we should describe how to roam key
information as well as recover it.

2.4.1.1 - can we change first sentence to read "The specification must
define a request for retrieving a public key, given a <ds:KeyInfo>
element containing one or more key attributes."

2.5 - add a statement to the effect we are not defining generic
mechanisms for securing SOAP/XML-Protocol consistent with our telecon
discussion and Stephen's earlier comments.

3.2.1 - reword to make SOAP/XML-P relationship clear.  Something like -
"Define payload and header XML formats, providing SOAP 1.1 bindings (or
XML Protocol if specified  in time).  SOAP need not be the only binding
defined, but it is required."

3.2.6.a.4 - Is the statement about "response values" is specifically
targeted at the 'respond' parameter used to communicate which KeyInfo
child elements should be returned?  If so, perhaps more explicit wording
should be added.  If not, I don't know what this refers to.

3.3.4 I agree with Sebastien's comments in regards to X509Cert and
X509Chain being required.  These should be recommended or optional.
XKMS services should not be required to implement X509 support.

3.4.a.4 Why is "Exclusive Canonicalization" a parsing requirement?  It's
a serialization technique, not what we generally mean by XML parsing.
Also, the use is rather vague - "assertions".  Shouldn't we say
something along the lines of we require its use when applying XML
Signatures to insure robustness given the possibility of intermediate
processors altering the SOAP envelope context.

3.4.b.1 - Can't we say something like "The specification should be
compatible with use of authentication mechanisms carried in a
SOAP/XML-Protocol message and/or the transport protocol".  XKMS doesn't
actually define an authentication mechanism beyond the key POP.

Also, a couple of things already in XKMS 1.1 should be added to 3.4.b
	- The specification should allow use of user-generated pass
phrases as a means of proving ownership of a key(s) previously
registered.
	- The specification should provide a means of employing a
secret, arranged out-of-band, between the  registration service and
end-user as a means of authorization a registration action.

Blair

Received on Wednesday, 14 November 2001 13:30:47 UTC