[wss] awkward status of message timestamps in WSS Core

[Peter Dapkus <pdapkus@bea.com>]

I'm fairly new to the committee -- my exposure to this spec has been primarily through the doc.  I don't see that this has been discussed anywhere, but if it's old territory, please let me know.  Apologies for the length.

The spec's use of Message Timestamps (chapter 10) seems a bit awkward:

*  We imply a dependency on elements from an external schema -- WSU.   This schema is undocumented, and presumably exists to allow these elements to be shared across specifications.  I say "imply a dependency"  because the section isn't clear about whether support is optional, recommended, or required.   Nowhere in the Core spec is use of Timestamp required, so I'm assuming its purely optional.

* Our use of those elements is completely unscoped -- Based on the examples, Timestamp and TimestampTrace are freestanding SOAP Headers -- whatever processing/semantics other standards impose on these headers have to be reconciled against our use -- this seems problematic.

* Our use of those elements is very loosely defined -- in fact, the strongest thing WSSE says about them is to imply they ought to be used as part of signatures and encrypted block to ensure freshness and promote uniqueness.  Timestamps are only a partial solutions to both those problems (because of clock skew and the limited resolution of timestamps in general).  

So, it seems weird to create a dependency on this external, undocumented schema (and, likewise, encumber it with our processing requirements) without documenting a specific usage of those Headers.   We hurt this spec and we limit the true re-usability of WSU.


Several alternatives suggest themselves (I'm sure there are others): 

1) Move Timestamp to our namespace

2) Include the timestamp as an element of the Security element

3) Use the children of timestamp (i.e. created) as children of the Security element (the way the UsernameToken does). 

Each of these has their own problems, but all seem to be improvements over the current situation.  

Drilling down, Expires is especially problematic -- it is unique in this spec in that it allows the sender to specify a restriction on the use of the SOAP Message.   The receiver does not *need* Expires to evaluate the request under any circumstance (freshness policies can/should be enforced using the Created element).   

So, this is a sender-side constraint, but we don't adequately describe the processing/semantics to give the sender any guarantees.   Specifically, under what circumstances can a sender safely regenerate a request for a message with an Expiry?   The spec offers very little help.  But this is an important question -- slop here can be exploited by malicious parties.  

Perhaps Expires should be left to a later spec -- we may be doing more harm than good if we can't make the sender any guarantees.  By eliminating it, we reduce the entanglement of WSSE and WSU.   

The TimestampTrace is similarly problematic, in my opinion -- we claim we don't do clock sync, then we require that you attempt to account for clock skew given an optional mechanism which gives you neither a trustworthy upper or lower bounds to clock skew.   Why are we encumbering future specs with this partial mechansim?   I think we may be better off without it -- again, less entanglement with WSU.


cheers,

-Pete
--  
Peter Dapkus <pdapkus@bea.com>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>