PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Protocol: ws-sp
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-securitypolicy-1.2-spec-cs.pdf
Artifact: spec
Type:
editorial
Title:
Use-Case for Timestamp Property.
Description:
The specification states that if [Timestamp] is false, then <wsu:Timestamp> should not be present inside <wsse:Security> header.
Related Issues:
None.
Proposed Resolution:
Does this mean, that if the
[Timestamp] property is set to false, or <includeTimestamp> is
absent, and yet if a request/response <wsse:Security> header
contains a <wsu:Timestamp>, then this should be treated as
violation entailing a
rejection of such a request/response?
My question is: Is this intended behaviour? Is there a practical use
case for this? I guess most implementors follow the following
algorithm/truth table:
Policy Actual Result
True True Accept
True False Reject
False False Accept
False True Accept
The highlighted values in the truth table are something we noticed
implementors (in WS-Policy interop event) doing, which means that if
[Timestamp] is set to false, ignore the <wsu:Timestamp> element
if found inside <wsse:Security> header, and thus accept the
message.
Should the spec be updated accordingly, or should vendors change their
implementation?
Thanks
Aditya