RE: ACTION-434: Propose final disposition of Referencing syntax

Pratik Datta wrote on 2010-01-19:
> DSig 1.1  has
> --------------
> * a Reference@URI attribute, which is mandatory, but it can be omitted for
> one reference.
> * a Reference@Type attribute, which is optional and it indicates whether
it
> is "Object", SignatureProperty" or "Manifest"

FWIW, I think we have an open issue on what we need to do to handle that
part of the spec, and I'm not as familiar with it, so I haven't looked yet.
If the new 2.0 referencing model can "handle" those various things, then
maybe Type still gets used up in the Reference, I'm not sure yet.

> * The Selection@Type attribute, which has a different purpose than the
> Reference@Type. The Selection@Type specifies whether the data is XML or
> binary. This will let the verifier easily determine if the intent was
> sign binary or XML data. Currently it is not easy to determine that. For
> example if you have an external URI to an XML file, but no transforms,
> then the implicit canonicalization will not be used, and it will be
> treated as binary.

See below, but my proposal was to use Type to signal the syntax of the
selection mechanism, meaning "it's XPath with this syntax" or "it's binary",
that kind of thing. We might rename the attribute or not, but that's what I
had in mind.

> * The Selection@SubType attribute, which can further qualify the
> Selection@Type attribute, e.g. binary from external URI, vs binary from a
> base64 text node.

In my proposal, Subtype qualifies the selection mechanism in whatever
fashion is desired or needed.

> In Scott's comments
> -------------------
> 
> * I see that you made Selection@URI mandatory. Why is that?  Suppose you
> want to do a same document reference using XPath, what would you set the
> URI to?  In my proposal I had mentioned that missing URI implies same
> document reference.

I believe same document references should be done with URI="" just like now.
Either works, but requiring it is clearer to me than implying things by
omission.
 
> * You said that "A ds2:Selection algorithm has two explicit input
> parameters, a required URI and an optional Subtype."  Did you deliberately
> remove the Type parameter? But I still see Type in your schema definition.

Type is the thing that tells you what the algorithm is. You can think of
that as telling you the function/method, while the other two items are the
parameters to it. Does that makes sense?

The names Type and Subtype are entirely up to us, of course, I just reused
them so it would be simpler to understand my suggestions in concert with
your proposal.

> * You made two sections "6.2.8.1 XPath Subset" and "6.2.8.2 Binary". Do
> these correspond to the value of the Type parameter?

Yes.

> I would put in two
> sections as XML and Binary. Because XPath is a special case of XML. An XML
> chunk can be either located by URI alone e.g. "#foo" or by a XPath alone,
or
> a combination of them.

I assumed that would be handled with one Type and an empty or degenerate
XPath expression of some kind.

Another option is three Types, one for XML with no further qualification,
one for the XPath subset (or more than one for different dialects), and one
for binary.

I did NOT want Type to mean "the kind of data being signed", but rather "the
type of selection being done".

> * Where would this "http://www.w3.org/2010/xmlsec/xmldsig2#xpath-subset"
URI
> be used?

The Type.

> I was planning to define different URIs to identify the different subsets
of
> XPath - "qname only", "streaming xpath subset", "full xpath" etc.

Those would then be separate Type values in my proposal. I preferred to
limit the extension points to the minimum needed, rather than have multiple
layers of pluggability, even if there's some duplication in the spec as a
result.

-- Scott

Received on Wednesday, 20 January 2010 00:44:25 UTC