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