[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Discussion of Issue 72 - Expiration
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]