Good point on the possibility of tampering
... I'll add a sentence in section 9 of draft 04 to point this out.
The reason the field exists in both
places is that some events will always require secure distribution and
some will only require it when sensitive information is being carried in
the payload (i.e. dynamic payload contents).
We deliberately named the equivalent
fields in v1 as simply requiring security. This allows evolving security
standards to be used as they become supported.
Thanks for catching the .xsd overlook
of the default value. Has been updated relative to the next version.
Rich
Andre Kramer <>
12/10/2004 05:15 AM
To
cc
Subject
[wsrp] EventDescription.requiresSecureDistribution
We should note that basing
security decisions
on EventDescription.requiresSecureDistribution
only makes sense if the EventDescription
was itself was
retrieved securely.
The threat
here being
Tampering.
I do not see
why we would want to duplicate
the flag in the Event
type itself, even if we include it in
the event
metadata. IMHO
A consumer should either use (securely
determined) metadata to
determine the
security level for
event transmission or
use the same security level at
which an event was received to re-distribute the event (Event.RequiresSecureRedistribution?).
Would it be simpler to use the same rule as
for getMarkup to distribute all events? i.e. If
a producer publishes
a secure binding (i.e. SSL)
then the consumer should make use of it? Or, better,
provide and
encourage means for
the event data to be signed/encrypted by sending portlets?
Regards,
Andre
PS. In
any case, the
Event.requiresSecure(Re)Distribution declaration
XML schema
could do with a default="false"
to match the EventDescription
convention.
