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

Scott,

I had intended "Type/Subtype" to be the type of data being signed, not the type of the selection, but I like your idea.

I see where are you going with this "Type".  It is like how <CanonicalizationMethod> has an Algorithm which says how to process the canonilicalization. Similarly you want <dsig2:Selection> to have a "Type". Maybe we can rename it to "Algorithm" too.

For example if Type/Algorithm="xml" the Selection processing is as follows .
  * dereference the URI to get a whole XML document or subtree (if the URI has a fragment ID)
  * evaluate the IncludedXPath on this document/subtree. Throw away whatever was not selected by the IncludedXPath
  * evaluate the ExcludedXPath on this document/subtree. Throw away whatever is selected by the ExcludedXPath
  * In EnvelopedSignature is true, exclude this Signature

So in a sense the "Type/Algorithm" is a set of selection processing steps, i.e. an algorithm.


The list of acceptable parameters will be dependent on the value of "Type/Algorithm".

For Type/Algorithm="xml",  acceptable parameters are  URI, Enveloped, IncludedXPath, ExcludedXPath.
For Type/Algorithm="binary/fromURI"  acceptable parameters are URI, ByteRange
For Type/Algorithm="binary/fromTextNode"  acceptable parameters are URI, IncludedPath, ByteRange

Extensibility wise, if people want to add a new parameter for new behavior they have to add a new Type/Algorithm, i.e. each variant of Selection Type will have a fixed set of parameters. This would fit in very nice for Dsig API libraries, they would have a definite schema and processing for each Selection Type.



However I don't want to use the XPath profile name in the Type. Simple Dsig implementations will not really care of the particular XPath profile being used, they will just throw the whole XPath to the regular XPath library and evaluate it. And complex ones can use a grammar to determine which profile the XPath expression belongs. I.e. if grammar for profile A recognizes this XPath, then use the implementation A, if grammar for profile B recognizes this XPAth the use implementation B and so on.

For the respec conversion that I am doing now, I will just keep the current meaning of type/subtype i.e. the one that is in the current draft, and we can discuss this in the meeting.

Pratik
-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, January 19, 2010 4:44 PM
To: Pratik Datta; XMLSec WG Public List
Subject: 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 Thursday, 21 January 2010 23:32:16 UTC