Re: Application Specific Semantics in Signatures

     The primary use of SignatureProperty, IMHO, is in the case where
multiple signatures are affixed to the same document and one of the signers
wishes to add qualifications to his or her signature without affecting the
document signed by the others.  Examples in which there is only one signer
will probably be simpler with the field in SignatureProperty moved into the
body of the document.  I realize that a SignatureProperty can usually be
moved into the body of the document as in this example, but doing so will
probably look less attractive when multiple signers move such fields there
and have to, for example, avoid ID conflicts.  For example, multiple
signers are likely to use a "Signing Time" property with different values
for each of them.

          Tom Gindin


"Winchel 'Todd' Vincent, III" <winchel@mindspring.com>@w3.org on 04/11/2000
05:52:39 PM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
cc:
Subject:  Re: Application Specific Semantics in Signatures



Joseph:

Thank you very much for this post.  This reflects what the group agreed
early on and was one of my primary concerns.  You have stated the
proposition extremely well.  I support something in the spec that would
discourage people from using <SignatureProperties>.

Your example is reflective of the real-world distinction between documents
and signatures.  Documents (and surrounding circumstances) convey meaning.
A signature is merely evidence of an act that signifies one of many flavors
of intent (acceptance, acknowledgment, authorship, etc., etc.) with respect
to what is in the document (and surrounding circumstances).  Trying to
capture "intent" is not something that can be done in a standard (at least
not with current technology :-)

Thanks,

Todd



> Presently, the specification speaks of using SignatureProperties as a
> potential way for one to introduce semantics beyond the simple signature
> semantic. (When people speak of "I signed this," they often imply an
> additional semantic of vouch, believe, assert, assure, authored, etc. Our
> design avoids this and sticks to the meaning of the signature: message
and
> signer authentication.)
>
> Use of SignatureProperty is useful, but a bit awkward. In discussions
with
> Taka on using XML Signature with CC/PP he formulated an example (that was
> integrated with RDF fairly well) that I very much liked. To place the
idea
> into a closer application domain:
>
> <checkbook>
>   <check Id="check101">
>     <account>xyz</account>
>     <name>reagle</reagle>
>     <amount currency="USD">50</amount>
>     <authorized by="#Signature101"/>
>   </check>
>   <Signature Id="Signature101" xmlns="http://www.w3...">
>     ...
>     <Reference URI="check101"/>
>     ...
>   </Signature>
> </checkbook>
>
> Clearly, the signature still keeps its simple meaning. It's the
application
> that defined and verifies what "authorized by" means, as it should be.
The
> only difference between this and SignatureProperty is the placement of
the
> syntax (in the application data instead of in the Signature).
>
> The short of this though, is that since I that I think we should
encourage
> people to use the approach captured in the example above, I'd like to
> include a few sentences and an example similar to the above such that we
> aren't unduly encouraging people to use SignatureProperty.
>
> BTW: I'm not speaking to the standardization of the syntax and semantics
of
> things like assuredby. For the time being, I think applications will do
it
> on their own. It'd be good to standardize on, but presently, whatever is
> done can be used directly in the application XML or the SignatureProperty
as
> appropriate. (The desire for standardizing signature semantics is
orthogonal
> to the design of the facility, which we've been focusing on.)
>
> _________________________________________________________
> Joseph Reagle Jr.
> W3C Policy Analyst                mailto:reagle@w3.org
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Tuesday, 11 April 2000 20:27:05 UTC