Re: [wss] Discussion of Issue 72 - Expiration

[Jerry Schwarz <jerry.schwarz@oracle.com>]

I agree with Hal.  While having a request expire might be useful in many 
situations it seems more related to the underlying application level than 
to the Security header. In a situation where I'm setting expiry times on 
requests I am also likely to want to be able to do cancels as well and 
inquire about the status of a request.

For example, if I'm making a limited time offer to buy or sell something 
then I expect to have the message processed by the application even if 
delays have the unfortunate consequence that the message arrives after the 
offer has expired.





>Hal,
>
>It seems that the issues you bring up here are clarification (and maybe not
>even that) issues and not issues to remove the Expiration feature. Its
>clear that receives may not want to process and messages that the requester
>has indicated that may not be valid and this could be for many reasons. Its
>clearly pointed out that the exact meaning and processing rules for
>expiration depend on the context in which the element is used. So as you
>point out that this element could be used for security reasons, or a real
>world security constraint.
>
>Its very reasonable to say that the message I as a requestor send expires
>in 60 min. The receiver should as per specification Upon determining that
>the message has expired, the requestor asserts that the message is no
>longer valid and will not process the message. How the requestor asserts
>that the message is no longer is a policy decision, very much like
>signature validation.
>
>.Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
>
>
>|---------+---------------------------->
>|         |           "Hal Lockhart"   |
>|         |           <hlockhar@bea.com|
>|         |           >                |
>|         |                            |
>|         |           06/02/2003 03:29 |
>|         |           PM               |
>|---------+---------------------------->
> 
>  >----------------------------------------------------------------------------------------------------------------------------------------------|
>   | 
>                                                                         |
>   |       To:       <wss@lists.oasis-open.org> 
>                                                                         |
>   |       cc: 
>                                                                         |
>   |       Subject:  [wss] Discussion of Issue 72 - 
> Expiration 
> |
> 
>  >----------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>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
>
>
>
>You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
>
>
>
>
>
>You may leave a Technical Committee at any time by visiting 
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php