VOEvent v2.0, some thoughts

[Steve Allen]

On Fri 2008-01-18T16:54:49 -0700, Rob Seaman hath writ:
>       1) XML signatures

One step for this wants for two or more parties to consider exchanging
VOEvent packets with a schema that includes the W3C xmldsig.

This involves getting X.509 certificates.  Initial testing does not
need anything more than a self-created certificate.  The IVOA docs
that I've seen indicate that they prefer only to issue short term
certificates suitable for sessions.  It's not clear to me that
is adequate for the sort of archival permanence expected of a VOEvent.

Another step is for the parties playing with the new schema to analyze
the use cases and see if the schema that I've outlined serves the
intended purposes of VOEvent.  In particular:

Are there any cases where it is interesting for a signature to apply
to only part of a VOEvent; i.e., is there any situation where a
VOEvent gets modified after the first signature is applied?
My impression is that the answer is no because the design of VOEvent
expects that rather than editing a VOEvent, the original will simply
be referenced by an entirely new followup VOEvent.

Are there any cases where it is interesting for a signature to sign
pre-existing signatures?
Again, my impression is that the answer is no.  It is probably enough
for any agent handling a VOEvent to sign only its content as an
indication of what it saw when the event arrived.

Another step is to ascertain whether the overhead of signing is too
time consuming for certain very-rapid applications.  In that case it
might make sense for the VOEvent to go out raw, and for the signatures
to be applied after broadcast so that they can be looked up in the
archival version.

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