RE: 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".

I'll tell the vendor of the auto numberer but I doubt that any new
release is planned for some time.


>    [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?

The issue is whether you want to get an interim response or not.

If your transaction is going to take 5 hours you probably want to 
know when you request the transaction that it has been accepted
for processing and possibly have the option of status updates.

This could be reworded I guess.

>   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?

Steve, Merlin, your turn...

We discussed this at some length on the con-call. Basically
this typoe of mechanism is essential if you are going to do
async processing so that you can provide information in the 
eventual response to have it route through to the requestor
correctly.

In sync processing the argument appears to be that this 
would be required in certain routing scenarios.

>    [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 

Well the schema says QName... 

> 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.

This would make the document clearer. 

>    [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.

The difference is that Validate is a trusted service, Locate 
is not. So Validate needs to take additional measures to ensure
that information returned is trustworthy. Locate does not.

This difference makes a huge difference to us as a service
provider. The locate service is not trusted and is not covered
by the SAS70 audit. The validate service is covered by the
audit and requires FIPS 140 level 3 hardware etc. etc.


>    [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?

The query is a template used to search for a keybinding, the 
prototype is a template used to request a keybinding.

I don't see that additional wording would help much.

>    [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? 

OK lets add an issue to check for the word assertion and
eliminate it. This is pretty necessary now that we have SAML
arround. The keybinding element is not indexical so it is not
an assertion in the XTASS/SAML/XTAML sense.


> 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.

At the XKRSS level is is just encryption...

This needs rewording

>    [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.)

The point here is that in most cases we do not require this ability.

However auditability is always a potential requirement for XKMS.


> 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

OK whatever.

I thought you folk liked URNs...

		Phill

Received on Wednesday, 28 August 2002 10:54:24 UTC