Jon, I do think I understand what you are asking for. The difficulty lies, I think, in the fact that the "WS architecture" way of doing things is to treat security-related things like signature as orthogonal aspects that get folded into a service deployment. The underlying audit/proof problem you are concerned with requires the persistent naming and retention of protocol messages, e.g. "at time T0, party 1 initiated agreement with offer O" and "at time T1, party 2 accepted offer O" in some way that the eventual arbiter can believe them to be accurate historical data. I do not think WSRF makes it harder to think about this. The WS-Agreement resource is not a message, but an addressable representation of the online process within which these messages are correlated. The WSRF modeling approach we are using is about making this process or "session" manageable, in the sense of being able to incorporate these agreement processes into a larger worldview of discovery and monitoring systems, etc. So, the Agreement resource gives us a dynamic view of the "current" status, while I think contract resolution requires an archived view of different key messages/interactions in the process like "agreement happened" and "agreement was violated (or satisfied) during time interval I". I think the question here is whether this "proof of agreement" problem is in or out of scope for the WS-Agreement standard. We have already declared "proof of satisfaction/violation" to be out of scope, so I had assumed proof of agreement would be treated the same way. I think you are asking for "proof of agreement" to be made in scope. I do not know how to do this in a way that is not biased towards one security/trust model, so that makes me afraid to approach it. Can you provide a more concrete proposal, or at least argue for why proof of agreement is different than the larger proof of satisfaction/violation such that we should keep banging our heads on this for the first version of the standard? I'm not discounting the value of these proofs, but merely questioning whether they are tractable enough to put in scope... karl -- Karl Czajkowski karlcz@univa.com