hack of VOEvent to include W3C signature

[Matthew Graham]

Steve Allen wrote:

>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
>
>  
>
Hi,

Another alternate use case is that the data of the packet remains 
inviolate but subsequent signature elements are added by VOEvent packet 
relays when they pass the packet on: this would be the case when you are 
concerned about the whole transport history of a packet.

    Cheers,

    Matthew