RE: An Xpath-based Solution

At 12:05 99/12/17 -0800, John Boyer wrote:
 >At this point, it became clear to me that the real problem here is that the
 >default should be to verify 'everything' that the signer signed, 

This is the default for core validation. 

 >BTW, some have said that we are venturing too far into application land.
 >Firstly, this argument seems to be whipped out only when it is convenient.
 >For example, IDREF is a mistake but was added so that certain applications
 >could function without using an XPath transform.

I don't believe there was much opposition at the time and I liked it because
I was more confused with the treatment of URIs, mimetypes, and
fragment-identifiers than with the need to use (or not) XPath. This is one
of the design features I expect to get feedback on from the wider
communities. I believe you now think it is a mistake (and I might've missed
a post if you posted your argument to the list) saying why you think so, but
the cases are different.

 >hesitation is being fairly applied to all scenarios.  Secondly, I think
that
 >some are thinking too heavily about core behavior being restricted to
 >signing a preconstructed bucket of bits, and this seems to be forgetting
 >that a very large part of our mandate is to robustly sign XML. 

I agree we have this bias (and I think it's been present from the start so
as to err on the side in terms of comprehension, security, and limiting our
dependencies on other specs.)

 >Finally, I also don't find it to be a satisfying argument that we shouldn't
 >make changes because vendors are already implementing this.  It is a
working
 >draft, and that is the risk one takes when implementing a working draft.

I agree, our TR states, "This is a draft document and may be updated,
replaced or obsoleted by other documents at any time." However, in August I
mentioned how if we were to complete in time, we had about 4-6 weeks of
conceptual design time left, then 4-6 weeks of implementation experience
time. The way I think of those two phases is

conceptual time: try to address the requirements as elegantly as possible on
paper.

implementation time: improve exposition and make design changes if it is
quite clear that implementation experience yields knowledge that a mistake
was made.

I should've done a better job of documenting this, and mini-milestones along
the way, but I do think it is safe to say that we are now in the later
phase. Consequently, for a change to be made, the WG has to do the best it
can with the design decisions in the past unless its clear things can be
easily remedied and agreed to by the WG.



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

Received on Monday, 20 December 1999 19:25:28 UTC