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