Discussion of Issue 72 - Expiration

["Hal Lockhart" <hlockhar@bea.com>]

We believe the Expiration feature is ill considered and should be removed.
We do not understand how to determine what values to set it to when sending
it, what its semantics have to do with security or how to process it on
receipt.

General observation: in distributed systems security, it is the receipient
that must insure that security policy is being followed. The sender can
perform various steps to try to provide the information the receipient
needs, but the decision belongs to the receipient. This becomes especially
clear when the sender and receipient are in different security domains whose
trust realationship is quite narrow and specific.

At first glance, the Creation and Expiration elements would appear to be
opposite sides of the same coin. However, this is not the case.

When a sender sends a Creation, it is merely recording an observed fact. The
receipient can ignore this information or use it in any way it choses. It
can decide based on any criteria it likes whether the Creation is a reason
the message should not be processed or be processed in a different fashion.

Expiration is different. It is a command or request from the sender to the
receipient that if the indicated date/time has passed, the message should
not be processed for some reason. It is not clear if this is a security
reason, e.g. fear of a replay atttack, a real world contraint, e.g. the
auction is over so there is no need to process the bid, or some other
reason. Note that the specification defines other adequate means to prevent
replay. If it is not a security mechanism, it does not need to be in this
specification.

Second, the sender has to decide what to send the Expiration to. It has to
estimate the effects of processing and network delays as well as queuing for
performance smoothing as well as system outages. As a sender, it will be
hard to estimate actual delays, since they are often not symmetic along both
directions of a given path.

Third, how is the receipient to interpret Expiration? Is it the time the
message is received, the time the application sees it or the time a response
is sent? Is it necessary to estimate how long processing will take in order
not to start on work that may have to be discarded? Or is it ok to send a
response to an expired message that was first received before expiring? What
if there is no response?

For all these reasons we would prefer to see Expiration dropped from the WSS
core. Alternatively we would like to see its use depricated until such time
as a protocol that defines specific semantics and processing steps for its
use has been defined.

Hal