Re: importing terminology in "XML-Signature Requirements"

"Todd S. Glassey" wrote:
> 
> ----- Original Message -----
> From: Dan Connolly (by way of "Joseph M. Reagle Jr." <reagle@w3.org>)
> <connolly@w3.org>
> To: IETF/W3C XML-DSig WG <w3c-ietf-xmldsig@w3.org>
> Sent: Friday, July 16, 1999 11:23 AM
> Subject: importing terminology in "XML-Signature Requirements"
> 
> > Some review comments on
> > XML-Signature Requirements
> > W3C Working Draft 1999-June-23
> > http://www.w3.org/TR/1999/xmldsig-requirements-990623.html
> >
> > It seems to use/import terminology liberally from other documents,
> > but not altogether consistently.
> >
> > In section 1. "Introduction" the phrase "XML compliant syntax"
> > seems to borrow from the XML spec, but the XML spec
> > defines no such term. The two related terms that the XML 1.0
> > spec does define are
> >
> > XML document
> > http://www.w3.org/TR/1998/REC-xml-19980210#dt-xml-doc
> > aka well-formed XML document
> > aka conforming XML document
> 
> Thiws might want to be also rewritten to include XML datastreams that are
> not considered documents in the classical sense, since reall an XML file is
> not a "document" without the presentation engine that turns it into some
> readable format.

Huh? I don't know what an "XML file" is, but I know what the
defintion of an XML document is. It's
	http://www.w3.org/TR/1998/REC-xml-19980210#dt-xml-doc
and it has nothing to do with presentation engines.


> > XML processor
> > http://www.w3.org/TR/1998/REC-xml-19980210#dt-xml-proc
> > aka conforming XML processor
> > aka non-validating XML processor
> >
> > I suggest "XML based" in place of "XML compliant" since
> > "compliant" suggests an imported definition, but that's not
> > what's going on.
> 
> Well sort of, except that XML Compliant means something like "processed as
> though it were an XML Document"

It does? According to whom?

> and this actually does have specific use in
> non document applications.

I don't follow you at all.


> > The terminology for the thing that gets signed is odd too:
> > "signatures on Web resources and portions of protocol
> > messages (anything that can be referenced by a URI)"
> >
> > The terms "Web resource" and "URI" seem to be imported from
> > somewhere, but it's not clear where.
> 
> Here again the language of the drafts is specific to use models that mandate
> a web or browser style interface, i.e. a presentation engine as the XML
> interpreter.

Where? "Web resource" in no way implies a browser or presentation
engine. When I do
	% wget ftp://ftp.jclark.com/pub/xml/xt.zip
I am accessing a Web resource at that URI, and there's no
browser/presentation engine involved.


> This is an important consideration and is clearly driven from
> the evolution of HTML based documents and is not generic to non browser
> based XML processing.

Clearly? I don't see this clearly at all.

> XML will get farther if it is not dependent on a
> browser to be valid.

Absolutely.


> > The term "Web resource" is used fairly consistently with
> > the usage in the URI syntax Draft Standard:
> >
> > "A resource can be anything that has identity."
> > -- http://www.ics.uci.edu/pub/ietf/uri/rfc2396.txt
> 
> Perhaps a better term is "an addressable object context" or somesuch?

I don't think that's an improvement.


> > but I don't think that identity is an essential property
> > of a thing that you want to sign. The essential property
> > of a thing that you want to digitally sign is that it's
> > (expressible as) a sequence of bytes.
> >
> > So I'd suggest replacing that "signatures on Web resources"
> > with "signatures on digital content." So:
> >
> > ... signatures on digital content: content of Web resources,
> > portions of protocol messages, etc.
> 
> I would use the term "Media Content" instead of Web Content, myself.

Is there some precedent for "Media Content"?
The term "content" is used in HTTP 1.1 and the MIME specs.
"digital" doesn't really add much, I suppose.

> > This impacts section 2. "Design Principles and Scope" too:
> >
> > The XML-Signature specification will describe how to
> > /-a-/ digitally sign /+the content of+/ a Web resource ...
> 
> Should it be any object that can be digitally signed as a part of an XML
> data stream. This would include any CONTENT-RICH CDATA structures as well.

I don't follow this at all.


> > (editorial: "signature value"? why not just "signature"?)
> 
> Becuase the term Signature as you have used it

you mean as it's used in the draft?

> probably also encapsulates
> the policy and control infrastructure of the blob itself, and that is not
> really what they were talking about. What was specifically being referred to
> is the data stream that represents the output of the signing alg itself, not
> the composite of the signature token services.

I got the impression from the design principle "The meaning of
the signature is very simple: ..." that the term "XML signature"
referred to exactly that "output of the signing alg itself"
and not anything else.


> > This terminology I find just baffling:
> >
> > "More than one signature may exist over any resource."
> 
> Of course, what is meant is that the idea is that you can recursively
> modify, track, and resign objects to support reiteritive and repetitive
> process models where XML is used as the containment protocol for the
> transaction envelope.

Hmm... I'm starting to get an impression of what this means,
but it's still not clear to me.

[...]

> > Another misleading reference:
> > In conjunction with XML facilities (including packaging)
> > That seems to imply that packaging facilities are part
> > of the XML 1.0 spec that was cited above.
> >Not so. If you mean
> > to refer to xml packaging facilities-to-be, please be more clear,
> > as that represents a dependency, which is very important to
> > call out in a requirements document. The requirement
> > 5.XML-Signatures must be able to apply to the original
> > version of an included/encoded resource.
> > implies that you _do_ depend on an XML packaging mechanism
> > (or at least an XML datatyping mechanism for labelling
> > base64-encoded stuff as such).
> 
> This is a very important comment since what it implies is that the
> presentation engines themselves need to be qual'd and this would mean
> creating a branding spec for XML maybe like X/Open's for Unix. Not that this
> is a bad idea, just that it is more work.

Huh? I don't see how use of packaging requires QA of presentation
engines.

[...]

> > Under 3. "Requirements"
> >
> > There's only one RDF data model, so
> >
> > The XML-Signature data structures will be predicated
> > on /-an-//+the+/ RDF data model [RDF]
> >
> > Hmm... "predicated on" seems wordy, but I don't have a more
> > plain-english suggestion.
> 
> I would have used "based on" myself.

ah... good.


> > Here again the bit about what you're signing:
> >
> > 2. XML-Signatures can be applied to any Web resource
> >
> > I'm having trouble coming up with a suggested replacement.
> 
> This like the above should refer to an addressable object entity not a Web
> Resource. The Web Resource says that there *must* be Web Enablement in the
> XML processing infrastructure and that sends the way-wrong messege in my
> book.

I don't think you want to require that stuff be addressable.
I expect to be able to sign content from stdin, for example.

But if you're going to to as far as "addressable object"
you might as well say "Web resource." It means the same thing,
unles you've got some other addressing mechanism (besides URIs)
in mind.

[...]



-- 
Dan Connolly, W3C
http://www.w3.org/People/Connolly/

Received on Wednesday, 21 July 1999 11:25:17 UTC