Re: Location=""

Hi,

From:  "Jim Schaad (Exchange)" <jimsch@EXCHANGE.MICROSOFT.com>
Resent-Date:  Thu, 28 Oct 1999 17:49:24 -0400 (EDT)
Resent-Message-Id:  <199910282149.RAA15688@www19.w3.org>
Message-ID:  <EAB5B8B61A04684198FF1D0C1B3ACD194A70E5@DINO>
To:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Date:  Thu, 28 Oct 1999 14:49:16 -0700

>The use of Location="" to refer to the entire document appears to me to be
>potentially troublesome in work flow applications.  When one starts
>including or moving forward signed documents, add other items (including
>other signatures) and so forth.  Using Location="" to refer to the
>containing document has now rather drastically changed its meaning and its
>not clear that the same set of items can be found again except potentially
>by explicit inclusion (rather than exclusion). 

Yes, I think that most workflow applications need to use inclusion...

In form applications, there would be some sort of transform to
determine what it was you were signing, perhaps by omitting some
stuff.  And in protocol/workflow applications, there would be some
sort of transform to determine what it was you were signing, probably
by specifying some specific elements.  While these could be based on
element names or the presence/absence of attributes or namespaces,
etc., I would think a common way would be via IDREFs.  As long as you
have non-ambiguous IDs, I don't see the problem.

IOTP, arguably sort of a workflow applications, has a fairly simple
scheme which generates IDs that are unique within all the potentially
large number of ID marked XML document/message elements of a
transaction.  Thus, when you copy signed or unsigned IOTP elements
(including signatures) forward into later IOTP messages, you just keep
their ID the same and an ID based ObjectReference still works.

(IOTP also has globally unique transaction identifiers such that a
transaction identifier and an ID together identify an element in a
globally unique fashion from among all IOTP transactions.  It would
have been simpler to include this transaction identifier as part of
the ID also, because you might want to point to something in another
transaction, but they just get too damn long.  That is the reason that
in the IOTP DSIG Manifest, there is an LocatorHrefBase attribute at
the top level which is prefixed to all the locations specified and a
scheme which takes a transaction identifier and an ID.)

>I assume that when this statement is made that the omission of the Location
>element is absent that it is equivalent to <Location HREF="">.

As you or Barbara originally requested, the non-specification of the
Location means that its up to the application to know from the context
what is signed.

>While I agree that it would be nice to be able to refernce the containing
>document by some simple and identifiable expression I don't believe that
>Location="" should potentially be that expression.  I would like to reserve
>this for a different reference, specifcally the object contained within the
>Signature element.  I believe that a large number of protocal messages will
>be built with the data being signed (a single item) being included in the
>Object of the Signature.  These are the message that I am most worried about
>size for, and would therefore like to be able to omit the Location reference
>and still have it well understood what the location of the object is suppose
>to be.

I have no problem with changing the spec to say that if the specification
of Location is omitted, the signature is over the first Object in Signature,
instead of being application dependent, if the WG wants that.  This seems much
better than varying from the URI spec for the null URI.

>It seems to me that we potentially need a couple of different types of
>"labels" that are distinct within the location.  Specifically would be "this
>is a URI of one type" and "You (the application) know what this is really
>suppose to be, find it for me" are two that spring to mind.  Potentially the
>root of the document could be represented as <Location DOC/>.

Humm...  I think there is only one type of URI.  There are values for
Location which are syntactically illegal as both URIs or IDREFs, such
as Location=":", which could mean application determined, but that's
pretty odd...

>jim

Donald

Received on Thursday, 28 October 1999 23:29:14 UTC