RE: Irvine Minutes and ost-FTF syntax proposal

John, thanks for your comments. To others: this is how we improve the notes
and come to closure on the list on some fuzzy issues and give others who
weren't there a sense of what happened. So get your comments in by the 10th.

At 12:59 99/09/02 -0700, John Boyer wrote:
 >1) I believe the WG decided that objectlocation would be a URI *without*
 >fragment

It states that in one point, perhaps you are referring to something earlier?
(People should feel free to annotate the notes so I know excactly which text
they are referring to.)

_
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.
_

I added "without fragID" to be clear. However, I think we need it to be a
URI or fragmentID (to a packaged chunk of XML in the same document.) Right?

 >2) I believe the WG decided that the 'exclusion' element would be changed
to
 >something like 'extract'.

I honestly don't recall. I'll note that in the notes as reference as we
tweak names of our elements as we move forward.

 >3) I believe the WG decided that XPointer or some subset of it would
 >comprise the content of 'extract' (as long as it does not change radically
 >in the future).  If this is true, then its DTD entry should be changed from
 >ANY to PCDATA.

Why do we need an "extract" element anway? If we are using XPtr, it would
just be part of the manifest reference, no?

 >4) I do not believe that the WG decided to punt the notion of exclusion
from
 >the core syntax as suggested by the minutes, nor do I believe any decision
 >has been made as to what if anything should be made optional.

Since the core syntax only uses a URI, any other references would be part of
the manifest/package and should be defined there, right?

 >5) There is a point in the minutes which says "Boyer raises unrelated point
 >that if the canonicalizer strips out the DTDs, you won't know which
 >attributes are IDs anymore."  I do not tend to bring up 'unrelated' points,
 >so I hope we can refrain from terms like this going forward.

Its orthogonal to the point directly above though its highlighted because
its a good point we need to investigate. I hope people are willing to give
me the benefit of the doubt and assume incompetence instead of malice in
meeting minutes that haven't yet been reviewed by anyone. <smile>

 >6) The minutes show a suggestion by Peter Norman to put a dsig:exclude
 >attribute in those objects that should be excluded from a signature.  The
 >group countered that this would not work for multiple signatures.  It is
not
 >in the minutes, but Joseph reiterated this point the next day because it
 >seems clear that multiple exclude attributes could be used to declare which
 >signatures the element should be excluded from. 

Again, I'm not sure what text you are referring to, but it does say:

Norman: can we do this in a simpler way, with a dsig:exclude attribute?
Which 	requirements does Xptr meet that can not be met through an easier
method? 	Group: The insertion of dsig:exclude is problematic when you have
multiple 	signatures, how does which signature know which dsig:exclude
belongs to it.

I added 

        Boyer also asserts this adds security problems in that it requires
modifications 
        to the signed document. (see Boyer 1990902 for more.)


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

Received on Tuesday, 7 September 1999 12:38:47 UTC