[
https://issues.apache.org/jira/browse/RAMPART-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573854#action_12573854
]
George Stanchev commented on RAMPART-144:
-----------------------------------------
It does not. It means that the message is valid this millisecond only. If
Expires < Created, then would've meant the timestamp has expired right away.
Both of those are legitimate use cases, permitted by the standards. I,
personally, have encountered legitimate use case for created<expires. If you
want to be flexible, you need to allow all permitted values.
> Timestamp with just create time element
> ---------------------------------------
>
> Key: RAMPART-144
> URL: https://issues.apache.org/jira/browse/RAMPART-144
> Project: Rampart
> Issue Type: Bug
> Components: rampart-core
> Affects Versions: 1.3
> Reporter: Narayan Singh Dhillon
> Assignee: Ruchith Udayanga Fernando
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> If we want to just have "wsu:Created" element inside "wsu:Timestamp" then
> Rampart doesn't allow it.
> WS-Security policy doesn't seem to define any policy semantics for above, but
> this element is optional and often not used in practical scenarios because of
> clock differences, but it is considered best practice to have time stamp
> included in XMLdSig.
> I think as Created and Expires elements are not controlled by WS-Policy, we
> could adopt for the flexible solutions as below:
> (1) In client side, if timestampTTL element in rampart-config is set to 0,
> then wsu:expires element must not be created.
> (2) On Server side, Timestamp should be validated for full, that is if
> Created and Expires element are present then they should be validated
> otherwise just created time be validated. I think this is current behaviour.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
