hack of VOEvent to include W3C signature

[Steve Allen]

During the VOEvent II meeting in December I alerted Rob Seaman to the
following hack of the 1.0 VOEvent schema.  It validates against
existing VOEvent examples.

http://www.ucolick.org/~sla/VOEvent-Sig.xsd

The operational change here is the inclusion of the W3C Signature type
via the lines
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
and
  <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
    schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>

Including these lines makes it possible to add a W3C Signature element
within the VOEvent schema.  I believe that it is a good thing to add
the above lines to the next version of the VOEvent schema defintion.

The question that remains open is how should that element be added
within the VOEvent element itself.
The answer to that question depends on the model by which XML documents
which are VOEvent messages are going to be handled.

In this hack I have included the Signature element using the line
    <xs:element name="Signature" type="ds:SignatureType" minOccurs="0" />
as part of the "all" in the VOEvent element.  Along with that assertion
I have many lines of commentary which outline the nature of the question.

I will try to reiterate the question here.

The current location of the Signature element allows for zero or more
Signature elements in any order.  This would make sense if a VOEvent
might originate at one point and be successively modified as it
propagates through the VOEvent transmission chain.

The question boils down to how VOEvent packets will be handled.

If it is the case that a VOEvent packet is deemed to be a one-shot
entity which is created and never modified then it makes more sense to
admit only 0 or 1 signature elements.  This makes sense in the model
where any further use of a VOEvent is done by creating a new VOEvent
which refers to the original, inviolate, archival copy of a previous
VOEvent.

This is a very simple use of the W3C Signature element.  It can be
handled with the off-the-shelf toolkits that already exist with little
complexity.  There would be no need for the Signature to contain an
XPath statement which identified the portions of the VOEvent being
signed, for the Signature would apply to the entire content.

There is an alternative model which admits that, as it is created, a
VOEvent packet may be constructed by several different agencies, each
of which adds more information to the XML document prior to the point
where it is injected into the VOEvent distribution network and archive.
This might be the manner in which VOEvents from AAVSO members are
constructed -- portions of the VOEvent might be created by the
individual AAVSO member, and optionally signed by that member (as a
means of attributing credit to that observer), and the final VOEvent
might be completed and authenticated again by the main AAVSO authority.

In that case it would make sense for a VOEvent packet to admit an
arbitrary number of Signatures, and for each one to specify the XPath
which extracts the portion of the VOEvent signed at that point.  This
requires a more complex set of XML software to construct the VOEvent
packets.  Still, the likelihood is that there would be a very small
list of XPath statements which would describe all realistic cases of
usage.  Once those XPath statements were documented it would again
be a simple matter to use the existing off-the-shelf tooklits which
manipulate XML Signature elements.

The discussion at the VOEvent II meeting left it unclear to me whether
there was a consensus for either of these models for use of VOEvent
packets.  There is, as always, a tradeff between capability and
complexity.

Is there a consensus on how VOEvent messages are likely to be handled?

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99858
University of California    Voice: +1 831 459 3046           Lng -122.06014
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m