No, I don't think I've explained it properly. It's a lot simpler that your reply suggests. I didn't say the agreement is a message, which you stated in your reply. I said that it should be a document. There is nothing to stop me sending a signed document as part of an XML message irrespective of the message-level/transport-level security stuff. The user proposes an agreement ("offer" to use the terminology in the spec.), and sends this as a signed document. If the respondent agrees, they sign the agreement too, and send it back. You do not need to retain all the messages - just this document, signed by both parties. Of course proof of agreement is out of scope. But if you have the agreement in the form I suggest, at least you give a *basis* on which people can do this. The current WS-Agreement specification doesn't do that. Jon. On Mar 23, 2005, at 10:42 AM, Karl Czajkowski wrote:
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