RE: Comments on XKMS Last Call Draft

This message is in reply to issue #311 [1] that you raised during the XKMS
WG Last Call request.

The changes you proposed to the specification have been acted on as below
and the revised version of the specification may be seen at [2]

At this point the work group believes all concerns raised in issue #308 have
been addressed except for the remaining item covered under issue 312 and
that the issue 312 is closed, unless we hear otherwise. (see [3] for
additional resolutions)

The XKMS WG would like to thank you for reviewing and commenting on the
draft XKMS specification.

Regards,
Phillip Hallam-Baker on behalf of the XKMS WG
VeriSign Inc.

[1] http://lists.w3.org/Archives/Public/www-xkms/2003Apr/0030.html
<http://lists.w3.org/Archives/Public/www-xkms/2003Apr/0030.html> 
[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html
<http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html> 
    http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html
<http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html> 
[3] http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0005.html
<http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0005.html> 


Main Document

 1  Section 2, paragraph 43, two codes "Sender" and "Receiver" may make more
sense if changed to "Requester" and "Responder". In any request/response
protocol, where you have two messages, Receiver and Sender do not indicate
the appropriate system entities. Requester and Responder make more sense.   
 
The terms sender and reciever are defined in the SOAP protocol and refer to
messages and not protocols.
No Action.
 
 2 Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending"
instead of "Asynchronous".  
 
Fixed
 
 3 Section 2.4.1, "RespondWith values Represent and/or Asynchronous MAY be
specified'. It should be ResponseMechanism and even then how can
ResponseMechanism be set to Asynchronous in synchronous processing?  
 
Fixed. 
The requestor may offer asynchronous processing, but the responder is not
obliged to honor this request.
 
 4 Section 2.5, PendingRequest is sent after the arrival of Notification.
But if the requester sends PendingRequest even if Notification has not
arrived, what should be the response?  
 
Fixed
If the service is not ready it simply returns pending again. This was
intentional to allow for polling as opposed to notification.
 
 5 Section 2.5.1, "RespondWith value Asynchronous MUST be specified" should
be changed to "ResponseMechanism value Pending MUST be specified". Same
should be reflected in Section 2.5.3.1 example.  
 
Fixed
 
 6     Section 2.5.3.5, 'RequestID' value should be
'#I4294d3993de300c1ef54d49bd0903b2d".  
 
Fixed
 
 7     Section 2.6, in the differences between asynchronous processing and
two phase request protocol, it is not pointed out clearly that while
asynchronous processing is mandatory (once it is specified by request
RespondWith) whereas two phase request protocol usage is the discretion of
responder.  
 
No, asynchronous processing is always an option. Fixed the text to make this
clearer
 
 8     Section 2.6.2, document specifies one method of nonce construction.
Is it mandatory to use this method? Paragraph 68 does not suggest that.  
 
It is open to implementors, the text has been fixed to make this clear.
 
 9     Section 2.8, paragraph 76, "Web Service" mention is unclear here.
Till now, all the services are XKMS services. Does it mean that only web
services can handle compound requests?  
 
 Fixed
 
 10     Section 3.2.4, for Mechanism attribute, "A URI that specifies the
protocol by which the notification is made". <PendingNotification> is a part
of <RequestAbstractType> so it is going to be used by requester. And
requester is not using Mechanism attribute, it is merely specifying it. In
my opinion, "A URI that specifies the protocol by which the notification CAN
BE made" seems more appropriate.  
 
Its a MAY, fixed
 
 11     OriginalRequestId (RequestAbstractType), RespondID (PendingRequest)
, RequestId (ResultType) should be of type "xsd:NCName" as they are
referring to "xsd:ID" type elements in other XML docs.  
 
This has been deferred to issue 312 for further action.
http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0023.html
<http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0023.html> 
 
 12     Section 3.3.2, paragraph 124, "The corresponding request was not
authenticated, or..." does it mean that ResultMajor.ResultMinor is
Sender.NoAuthentication? If yes, then this probably is more concrete
wording.  
 
No. The constraint is correctly on the request, if there is no signature on
the request then there is no way to link it in the response. This is not the
same as no authentication which indicates a violation of the service
authentication policy. The lack of the signature in this case is simply a
logic error since the requestor is asking the service to return a data item
that was not provided.
 
 13     Section 3.4.1, CompoundRequest can have multiple requests of the
same type. Although this is clear from the schema definition, it would be
better if some text can be provided to indicate that. Besides that there is
no clear reasoning given for that.  
 
Fixed
 
 14     Section 5.1.3, paragraph 178. UseKeyWith specifies subject
identifier and application identifier but the corresponding attributes
(Identifier and Application) do not seem consistent. Probably attributes
like Subject and Application; or SubjectIdentifier and ApplicationIdentifier
seem more appropriate. 
 
This would break existing applications without providing significant value.
No Change 
 
Bindings Document
 1     Section 3.1, can we have some other XML elements besides XKMS content
inside Body element? Document does not say anything about that. 
 
This is a SOAP issue
 
 2     In the SOAP Faults section, error codes are "env:Receiver" and
"env:Sender". In any request/response protocol, where you have two messages,
Receiver and Sender do not indicate the appropriate system entities.
Requester and Responder make more sense. So probably "env:Requester" and
"env:Responder" seem little bit better.  
 
This is the SOAP spec.
 
 3     Section 4, "This specification describes three principal security
bindings...". I can see two, Payload Authentication Binding and SSL/TLS
Security Binding. Where is the third one? 
 
Fixed