Re: Comments on Aug 1 Spec

On Wednesday 28 August 2002 10:55 am, Hallam-Baker, Phillip wrote:
> > 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.

Right, it requires manual intervention.

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

Ok, I think this requires further motivation/explaination.

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

Good then, we'll reflect that in the text and examples.

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

And the degree to which something is trusted is determined by some policy. 
If you are saying that the semantic of "validate" includes SAS70  and 
FIPS140 level 3 hardware, then the specification should say that. Or, its 
service determined and that should be represented by some identifier (and 
the two types of request aren't needed...?)

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

I'd style like the query to appear as a prototype as well (otherwise I find 
the query ambiguous as discussed earlier [1]). For example:
>       <Respond>
>          <string>KeyName</string>
>          <string>KeyValue</string>
>       </Respond>

If we want to specify the Respond/sql:Select, then we should give a proper 
prototype. If one wants a ds:KeyInfo with the a KeyName and RSAKey Value, 
then one should ask for:

<Respond>
  <ds:KeyInfo>
   <ds:KeyName/>
   <ds:KeyValue/>
      <ds:RSAKeyValue/>
  <ds:KeyInfo>
</Respond>


[1] http://lists.w3.org/Archives/Public/www-xkms/2002Mar/0086.html


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

There's lots of requirements, my concern is this one we MUST accommodate 
when considering the advancement of the a stable/complete/implemented 
specification? I'm not completely sure what "Transitive Authentication" 
means in this context, (I think I understand, but I may be confused absent 
the specification) so I can't speak to that -- the requirements doesn't 
mention it either nor give me any guidance. However, this is yet another 
feature were going to have to have interoperable implemetantions of.

Also, I continue to prefer that we speak of an "XKMS service" instead of a  
"trust service" since folks argue that a Locate is not really to be 
trusted!

Received on Wednesday, 28 August 2002 11:55:26 UTC