RE: Irvine Minutes and ost-FTF syntax proposal

At 12:06 99/09/07 -0700, John Boyer wrote:
 >_
 >>Consensus. The reference from SignedInfo will just be a URI. This can then
 >>  point to a manifest or package which can use Xlink/Xptr/Xpath as
 >>appropriate.     This means you don't have to worry about Xptr in the core
 >>signature syntax.
 >Perhaps I misunderstood what that meant.  Did you just mean that we could
 >punt the problem of having to make up a syntax for exclusion?  Please
 >clarify.

For the core syntax yes.

 ><John>
 >Actually, this wasn't my interpretation of what was said at the FTF nor is
 >it reflected in the post-FTF Solo syntax.  The signedinfo contains a
 >signedobjectreference, which includes a transformations element, which
 >includes the exclusion functionality (which we are proposing would use some
 >form of Xptr).  Also, this is why I've been under the impression that this
 >would be part of core syntax.
 ></John>

This was not my understanding, but you are right the latest Solo reflects
your position. I was rather please we would be able to push XPtr into the
manifest spec (since I figure XPtr is part of the manifest reference) and it
would make the core syntax all the easier to implement quickly. Perhaps I
was mistaken.

 ><John>
 >I think that we need some way of indicating partial documents so we can
 >indicate, for example, the packaged chunk of XML in the same document, but
 >we seemed to get into muddy waters when we allowed fragmentID to be part of
 >the URI rather than using the Xptr transform (which can do inclusion as
well
 >as exclusion logic).

From my understanding, XPtr transformation IS a fragment identifier, but we
can discuss this since I haven't seen  your proposal of how to use XPtr in a
"extract" tag, nor since my memory of what happened is clear. <smile>
Regardless, I would like (and what I thought! <smile>) was that the
(objectreference:location := URI-sans-fragment |
fragment-to-elements-of-type-ID) and the manifest reference was a URI
including Xpath/XPtr.

 >As a quick reminder, if you go back to fragID, here are some problems to be
 >faced
 >1) every signed XML app will have to be a validating XML app since the DTD
 >must be processed to figure out the ID.

I believe some people disputed this.

 >4) Asymmetry between direct signature and indirect signature via manifest.
 >A manifest method would have powerful means of filtering the XML, but
 >requires the app to validate the document itself.  The direct signing
method
 >validates the actual object being signed, but if you removed XPtr, it would
 >not have very powerful means of filtering.

Agreed, I fear XPtr is too much at the core level, but I'm happy to be told
otherwise.

 ><John>
 >Actually, that's a great question!  I was all in favor of this approach
 >myself until Milt Anderson burst our bubble (and rightly so!) by pointing
 >out that it may be necessary to do transforms such as base64 decoding
before
 >we apply the Xptr.  Kudos Milt!
 ></John>

Well, we need to get the order of that stuff right regardless, should be
specified in the spec.
 >Peter Norman's actual suggestion was actually more sophisticated.  He
 >proposed having a special element to mark regions to be signed by each
 >signature.  The marker elements would be dropped out of the signature, but
 >they bracket the regions that should be signed.  However, since this is a
 >positive (inclusive) method, rather than an exclusive one, it still loses
 >the document closure battle. (In partial answer to the question of what do
 >the Xptrs do that the proposed idea doesn't do).

Understood.


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Tuesday, 7 September 1999 17:14:37 UTC