RE: what does a signature mean ?

In light off the discussion about the legalities of signatures, RDF
and onscreen data presentation, I'd like to draw attention to a very
large area of appications where the signature binding an assertion to
an object is not like signing a legal agreement (e.g., a mortgage)
where the rules and meanings attached to signing are reasonably
well-defined in advance.

In last week's workshop, I believe the presentation closest to this
area was by AND Communications, although an operator of a PICS Label
Bureau would be in a similar situation.  In government and military
applications, these applications are most closely related to
"intelligence" operations;  but as we all know, every business makes
extensive use of intelligence, and services like AltaVista, Yahoo!
Lexis/Nexus and others are essentially commercial intelligence
agencies.

In "intelligence" applications, it is always assumed that the signer
of an assertion (RDF, PICS label, ...) is aware of what's being signed
and the semantics of the signature are contained in the assertion
itself.  There will also be external rules and legalities defining the
implicit semantics of the act of signing, but the signature itself is
being applied to a unique (set of) statement(s) that make the
semantics of the signature explicit.  The signature and the statements
necessarily go together.

Because government/military intelligence agencies support a
well-defined and widely understood model for "intelligence" gathering
and handling, I'll use that in my example, with the understanding that
their model translates easily to the sort of intelligence work that,
for example, corporate marketing departments or prospective stock
investors (should) do.

Military intelligence data, particularly so-called "open source"
information, comes in many forms:  images, audio recordings, text,
video, etc.  Very little of this information is delivered to
intelligence analysts as HTML or XML, although it may be packaged or
"wrapped" in HTML or XML by the intelligence-gathering machinery.
As a result, an analyst wishing to make assertions about these
resources will have to do so in one or more seperate (and probably
signed) documents.  For example:

    SPOOKS.GOV says "http://spooks.gov/pix/satellite_img_45.jpg is
    classified as TOP SECRET."

    JOHN Q. ANALYST says "http://spooks.gov/pix/satellite_img_45.jpg
    is a picture of an Iraqi SCUD missile site 3 miles North of
    Baghdad.  The picture was taken on April 1, 1991 by the SKYSPY
    VFX-1 satellite . . . blah, blah"

As shown in the first document, some intelligence information and the
resource to which it refers has a classification (e.g., "TOP SECRET").
A classification label is a simple assertion about the original
resource and, sometimes, about some assertions made about it (e.g.,
the fact that the "SKYSPY VFX-1" satellite flew over Iraq on April 1,
1991 might be classified).  The meaning of a security classification
label is static and well-defined by external rules, so the semantics
of SPOOKS.GOV's signature on the label probably don't need to be
explained.

In contrast, the semantics of the analyst's signature on the second
document example are found only in the assertion itself.  In
particular, with the exception of the simple "By signing, I assert
that 'X' is true" (where 'X' is the statement "http://spooks...") the
signature binds the assertion 'X' to a resource, and 'X' defines the
semantics of this binding.

Any implicit semantics of the signature(s) on the second assertion
are the result of agency rules being applied to JOHN Q. ANALYST's act
of signing, but not to the assertion 'X' he personally made by signing.
For example, the SPOOKS.GOV agency might require that, in order to make
assertions about any "TOP SECRET" resource, an analyst must possess a
"TOP SECRET" security clearance, and from this plus the fact that the
document containing the statement came from the SPOOKS.GOV server, we
might conclude that JOHN Q. has this clearance.

Hence, there is a large class of applications for "intelligence" where
it will be required that assertions (presumably in RDF) be embedded in
the signature block itself rather than reside in an external resource,
because the semantics of the signature will be otherwise undefined.

Clearly, this doesn't imply that every signature block will need to
include RDF statements to explain semantics --- only that there are
broad circumstances where such statements will in fact be required by
the application.

On the other hand, I suspect it may always be necessary to refer to
the set of semantic definitions that apply to a particular signature
via a pointer, 'P'.  This amounts to something similar to the
boilerplate "By signing this document I, the undersigned, state that I
understand and agree to all the terms and definitions described in 'P'
and ...".


-- 
  Bede McCall   <bede@mitre.org>
  MITRE Corporation                        Tel: (781) 271-2839
  202 Burlington Road                      FAX: (781) 271-2423
  Bedford, Massachusetts  01730-1420

Received on Monday, 19 April 1999 21:16:56 UTC