Comments on Aug 1 Spec

http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-1.html

It'd be the nice if the IDs for sections and defined words were human 
grokkable instead of: id="Auto631643354419997500Z442".

   [34] XKMS services MUST support synchronous processing. In synchronous
   processing the service returns the final response to the requestor
   using the same communication channel used to issue the request.

What is a channel? Also, this synchronous and asynchronous... For example, 
HTTP typically doesn't have the concept of a channel, so is the question 
here whether I send back the response with 5 minutes, or 5 hours?

  2.3.3 Element <OpaqueClientData>

   [45] The <OpaqueClientData> contains data specified by the client that
   is opaque to the service. An XKMS service SHOULD return the value of
   an <OpaqueClientData> element specified in a request unmodified in a
   response with status code Success.

I must've missed this bit, what's the motivation for this?

   [49] The <RespondWith> element in the request specifies one or more
   strings included in the request that specify data elements to be
   provided in the <ds:Keyinfo> element of the response. 
   [53] The following schema defines the <RespondWith> element::
   <!-- RespondWith -->
   <element name="RespondWith" type="QName"/>
   <!-- /RespondWith -->

Is it a string, or a QName? I think they should be QNames (or URIs). To that 
end, I'm still concerned with the design of the query. We now are not only 
including identifiers of element types from other namespaces, we are adding 
are own qualifiers to the query semantic such as and Multiple, PrivateKey, 
Pending, Represent. At the very least, these should be xkms:Multiple, 
xkms:PrivateKey, etc.


   [90] The Locate and Validate operations are both used to obtain
   information about a public key from a Trust Service. Locate and
   Validate services are both expected to attempt to provide correct
   information to the requestor. The Locate and Validate services differ
   in the extent to which the Trust Service verifies the information
   returned. A Location service SHOULD attempt to provide only
   information which is trustworthy to the best of its knowledge. A
   Validation service undertakes to only return information which has
   been positively validated by the Trust Service as meeting its
   validation criteria.

"Under a specified policy." (Note, I continue to hold a minority opinion (of 
one I presume <smile/>) that there's not much of a difference between 
locate and validate. There's an implicit query (validate requests more 
elements) and policy, and I prefer such things to be explicit.

   [101] XKMS specifies three elements that specify key bindings, all of
   which are derived from the KeyBindingAbstractType. These elements are:

   KeyBinding
          Specifies the parameters of a particular instance of a key
          binding

   QueryKeyBinding
          A template used to specify one or more key bindings using query
          by example.

   PrototypeKeyBinding
          A template used to specify the key binding parameters requested
          in a registration request.

I don't understand the distinction between these types...? Perhaps links to 
their motivation/example?

   [117] The NotBefore and NotOnOrAfter attributes are optional. If the
   NotBefore attribute is omitted the assertion is valid on any date up
   to but excluding the date specified in the NotOnOrAfter attribute . If
   the NotOnOrAfter attribute is omitted the assertion is valid from the
   NotBefore attribute with no expiry. If both elements are omitted the
   assertion is valid at any time.

The document begins using "assertion" quite a lot, which is not defined. We 
mean the response, right? 




http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html

   [21] In addition an XKMS service that supports server generated keys
   MUST support the use of super-encryption as specified in the XKRSS
   protocol.

Super-encrypted should link to the xenc doc for documentation and I don't 
see any discussion of super-encryption in XKRSS.

   [31] In some circumstances requests or responses or to both may
   require transitive authentication. That is a message sent by A and
   authenticated by B may be subject to forwarding and authentication by
   C. In addition some applications may require further measures to
   ensure that messages meet certain legal standards to prevent
   repudiation.

I thought for simplicity's sake, there was only one relationship, between 
the client and service. If the client trusted the service, then it's up to 
the service to determine who/how it deals with under the specified policy? 
(This is something I've remained confused on.)

4.1 Payload Authentication Binding

   Identifier: URN:blahblahblah:w3.org:xkms:payload-I
          No mechanism is used to authenticate the client

These should be URIs, e.g.,:

  http://www.w3.org/2002/03/xkms#:payload-II

Received on Friday, 23 August 2002 17:20:17 UTC