W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

RE: verifying order of resources in a document

From: Mark Bartel <mbartel@thistle.ca>
Date: Tue, 3 Aug 1999 16:37:52 -0400
Message-ID: <91F20911A6C0D2118DF80040056D77A20328F3@arren.cpu1634.adsl.bellglobal.com>
To: "'tog '" <todd.glassey@www.meridianus.com>, "'w3c-ietf-xmldsig@w3.org '" <w3c-ietf-xmldsig@w3.org>
Todd,

Let me try and rephrase/summarize the basic issue here...

When a "chunk" of xml is in a legal social context (for example, a
contract), the technical context must be verifiable.  In my example with
style sheets you point out (I think - I'm paraphrasing) that both the
document and style sheet would have to be signed.  You are concerned with
applications where the legal context and scope issues are much more complex.
I think we agree that the necessary functionality does not need to be in the
basic xml digital signature standard, but can be built on another layer.

Note that digital signatures are useful in contexts where legality isn't an
issue.  Digital signatures provide authentication, integrity, and
non-repudiation; as they come into more common use and pki infrastructure
becomes ubiquitous, people will use them for tasks that don't require all of
those.  A digital signature might be used for something as simple as
detecting whether the data has changed, without any "judgement" as to
whether this is good or bad.  Perhaps using a digital signature is overkill
for this, but if you have digital signatures easily available, why not use
them?

-Mark Bartel
JetForm Corporation


-----Original Message-----
From: tog
To: Mark Bartel; w3c-ietf-xmldsig@w3.org
Sent: 7/31/99 3:20 PM
Subject: Re: verifying order of resources in a document

Mark - let me clarify
----- Original Message -----
From: Mark Bartel <mbartel@thistle.ca>
To: 'tog ' <todd.glassey@www.meridianus.com>; <w3c-ietf-xmldsig@w3.org>
Sent: Friday, July 30, 1999 11:47 AM
Subject: RE: verifying order of resources in a document


> Todd,
>
> I'm not sure I understand.  If you feed a browser an arbitrary chunk
of
XML,
> it is unlikely to be able to display it meaningfully.  It could be a
> workflow process definition or it could be a recipe for fudge
brownies.

Exactly!

> If
> you attached a style sheet defining how to display the recipe format
or a
> workflow definition, the browser could then meaningfully display it.

Making the style sheet a mandatory part of the document or instrument...

> You
> might have another style sheet that displays the recipe in shopping
list
> format, in which case it would discard all the cooking instructions
and
just
> give the ingredients, perhaps grouped by type.

Which changes the legal context of the instrument or signature
represented
by the XML Stream - this is no good either... The signatures need to be
maintained in exactly the same context that they were issued in if they
are
relevent to the bigger picture of what the XML stream represents.

> Would the last be non-linear
> processing?  Technically speaking, the browser would still have to go
from
> the top through the tag structure to figure it out, so one might still
call
> it top-down.

Except that here the browser becomes the presentation interpreter for
the
"XML Stream" and as such part of the envelope of the XML process.
Because of
this dependency it has to be part of the spec too if there is commercial
processes or legal ones happening over this transport.

> having an implicit
> knowledge of what the xml data means.  Feed it into the workflow
engine
and
> it will allow initiation of that process.

yes !!! and  my concern is that in commercial uses of this particular
model,
that the workflow engine will also need a compliance standard, and from
a
commercial standpoint be of audited code to be of use in the Industry,
per
say.

While this is not directly about the technology use of XML it clearly is
something that as product people that we have to deal with. So if we can
address this in the overall process of defining XML based auth models,
we
win bigger I think.

>
> So, it seems to me that the application needs to understand the data,
> whether it does so implicitly (the workflow designer/engine) or it is
told
> how (the browser with style sheets).

Yes!

>The order of the data may or may not
> matter; one can rearrange the order of the ingredients of the recipe
(a
> set), but it would be undesirable to reorder the instruction steps (a
> sequence).

Yes and along the same axiom, what happens to stage 'a' of a contract if
stage 'b' negates it accidentally. This is the end effect of one such
model
where the flow of the construct is not managed. Here is the detail. Step
one
of the "contract" says that IF A then NOT B and do execute step C. So if
B
is executed first what does this do to the totality of the contract
intent
model, in many cases its is flushed essentially. The idea is that there
must
be some way to inextricably interpret the object relations irrelevant of
what GOTO features the language supports or its use models are going to
be
really hard to get into legislative cover, I think.

I am not saying that this has to be done as part of the pure XML spec,
it
can be easily accomplished as a preprocessing operation that flattens a
hierarchical file into what I refer to as a 'resolved XML stream'.

This means that the Digital Signature Aspects of the Language and their
core
objects are only specific to single use models and that as they are
defined
now they work fine. But I want to reiterate that the refer to the
"resolved
version" of the file.

I am actually hacking up a preprocessor that follows the DAO (Digitally
Authenticated Object) XML TAG Processing proposal I made some time ago
(http://www.gmtsw.com/ietf). Personally I think this will work fine and
will
allow for multi-dimensional documents like contracts and other legal
instruments to be handled in XML more fully.

By the way, I want to again suggest that a Base64 Encoded BERT Token
(http://www.gmtsw.com/ietf/bert) is one good way to do the timestamping
requirements. It addresses the event, the source of time, its
reliability
and chain of custody, and the geographic positioning of the event for
jurisdictional placement. Its free. GNU style license against the Token
and
anyone could easily roll an API to produce or verify it.

>
> Could you clarify?
>
> -Mark Bartel
> JetForm Corporation
>
> -----Original Message-----
[rest of thread deleted]
Received on Tuesday, 3 August 1999 16:38:06 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT