[graap-wg] proposal: agreement lifecycle end-games

[Jon MacLaren]

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 at univa.com
>