RE: [ws-sx] Summary of ER006 discussion on [Timestamp]

This message is an attempt at unwinding a discussion Aditya and I had over a pretty long time period about ER006. I haven’t run this by him, so hopefully he’ll reply on the list if he thinks I’ve represented this correctly or not.

Issue ER006 is concerned with the statement in SP that if [Timestamp] is false, then <wsu:Timestamp> must not be present inside <wsse:Security> header.

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826548

It has been observed in interop testing that there are implementations whose clients will transmit [Timestamp] when it is set to false by the service. There doesn’t seem to be any disagreement that clients that do this are not correct with respect to the current spec.

It has also been observed that many implementations services will accept <wsu:Timestamp> in the <wsse:Timestamp> header when they have set [Timestamp] to be false. The spec has wording that permits this behavior. There is some disagreement on the interpretation of the wording that permits this depending on the interpretation of the [Timestamp] rule itself (see closing points in lists below).

The question on the table is should a) the spec be changed to loosen the rule from <wsu:Timestamp> must not appear to <wsu:Timestamp> may be ignored or b) the spec is correct and the issue should be closed with no action? Aditya and I have not been able to agree on this.

This is difficult to unwind, I’m attempting to represent the arguments made for each position a and b above. They can also be read as point/counterpoint, but I felt keeping them clearly separated was the best way to present this.

Arguments for a) – loosen rules on [Timestamp] set to false

· If the initiator sends more than what the service policy requires the service provider should treat it as redundant information and ignore it.

· Service providers should only check the appearance of <wsu:Timestamp> against Layout rules when [Timestamp] is false.

· Almost all participants in interop ignored an unwanted <wsu:Tiemstamp>.

· Saying when [Timestamp] set to false that <wsu:Timestamp> must not appear could be interpreted as messages that include it must not be accepted. The statement that a service can accept messages that do not conform to its policy seems contradictory to that interpretation. As an implementer which viewpoint should take precedence?

Arguments for b) – close with no action

· There are rules in the Layout assertions for where <wsu:Tiemstamp> appears, this is not always extra information that can be safely ignored when it appears unexpectedly.

· Changing the guidance as requested for [Timestamp] would introduce inconsistencies into the SP model. The SP model is that the initiator MUST send exactly what the service provider asks for; no less, no more.

· SP already permits a service to accept extra information such as a unrequested Timestamp in the header if present. See section 2.3

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826506

“Note also that a service may choose to accept messages that do not conform to its policy.”

· From an implementation perspective being strict on what you send and liberal on what you accept is often beneficial for wider interop. One reason for accepting messages that don’t conform to policy may be for wider interop with incorrect clients and is the best explanation for what was seen in interop testing.

ws-sx message