I think the best solution to this termination/expiration mess is to separate completely the notions of "lifetime of obligations" and "lifetime of Agreement interface". A. The lifetime of obligations should be captured solely in term-level meta-data and/or domain-specific lifecycle models. Individual service or guaranatee terms MAY have expiration times on them that are set statically or renegotiated by a mechanism outside the scope of our first specification. Additionally, some obligations MAY last indefinitely or until some domain-specific events occur. B. The lifetime of the service interface SHOULD be greater than the effective lifetime of any obligations, but I guess I can accept that this may not be possible with limited Agreement implementation QoS. It is hard to be normative about such failure modes. C. I suggest that we drop (for now) any notion of terminating the obligations using WS-Agreement mechanisms. If we can find a clear proposal for handling such ammendment of obligations before the spec is done, I am not personally against reincorporating it in some form. D. I suggest that we defer to WS-ResourceLifetime for handling the termination of the Agreement resource itself, with the specification advocating the above "SHOULD" about Agreements outlasting their embedded obligations (B). E. We should introduce an agreement-wide state, complementing the proposed Pending/Rejected/Observed states, to represent the Complete or PostObserved condition where all terms have passed "out of scope" and into history. What is the best state name for this? F. Should we introduce any kind of "linger" time to indicate an interaction with WS-ResourceLifetime to commence an automatic countdown to Agreement destruction once it has reached the Complete or PostObserved state? karl -- Karl Czajkowski karlcz@univa.com
Good to see a thorough consideration of the lifetime issue. Other than agreeing entirely with dropping the terminate stuff for now, I just wanted to comment on one of the points you made: On Mar 22, 2005, at 1:53 AM, Karl Czajkowski wrote:
... F. Should we introduce any kind of "linger" time to indicate an interaction with WS-ResourceLifetime to commence an automatic countdown to Agreement destruction once it has reached the Complete or PostObserved state?
It may be OK to "garbage collect" the agreement after all the terms have successfully completed. But where one or more terms have been violated, the initiator will want to be able to point at the agreement for an arbitrary length of time afterwards. They may wish to seek compensation through some out-of-bands methods. Let me give a motivating use-case. Lets say that something goes wrong with the execution of my job. Perhaps we'd agreed that it would execute at 4pm, but it didn't start until 4.30pm. I am offered a partial refund, but want to argue for more. I'll do this by email, but will want to refer to the agreement in some way... Lifetime management for this sort of thing is hard.
karl
Jon.
I agree the lifetime management is hard. :-) I wonder if this sort of scenario is not a good point in time for the client/initiator to: 1) Use the Agreement interface to capture the status and/or other identifying information. 2) "Retire" the Agreement by allowing it to be destroyed. 3) Have offline compensation using the captured status and identifying information. As I have said before, I think there is a practical limit to what can be done in the online, automatic system view of WS-Agreement. Shutting down/destroying those interfaces should not necessarily destroy records but just shift the information out of the online message processing system and into audit/accounting. Trying to negotiate compensation between humans is definitely out of scope (and too hard) for WS-Agreement, I would say. I guess I would frame the question as what sort of support is needed to allow such conversations to continue after the Agreement is terminated, e.g. access to "final state" and/or naming information that can be passed around offline? karl On Mar 22, Jon MacLaren loaded a tape reading: ...
It may be OK to "garbage collect" the agreement after all the terms have successfully completed. But where one or more terms have been violated, the initiator will want to be able to point at the agreement for an arbitrary length of time afterwards. They may wish to seek compensation through some out-of-bands methods.
Let me give a motivating use-case.
Lets say that something goes wrong with the execution of my job. Perhaps we'd agreed that it would execute at 4pm, but it didn't start until 4.30pm. I am offered a partial refund, but want to argue for more. I'll do this by email, but will want to refer to the agreement in some way...
Lifetime management for this sort of thing is hard.
karl
Jon.
-- Karl Czajkowski karlcz@univa.com
If I can make my point clearer, I'm not saying that human negotiation should be part of WS-Agreement. But, the Agreement information has to remain available as long as it is needed by either party. This is hard to do when the Agreement is a WS-RF style resource (or a service). You proposed that you could allow some way for the initiator to "capture the status" from the Agreement interface. That'd be alright, provided that it was in some form which was signed by the other party. Otherwise, it's not much use - too easy to fake up. (Of course, the user still has to trust the agreement provider to give them this after things have gone wrong.) Just saying that shutting down the interface only moves the data to an audit/accounting system is all very well, but it gives me no idea of how I might retrieve that information, let alone in a standard way. However, if the definitive form of the Agreement were an XML document, signed by both parties, you wouldn't have these problems. People would just keep the agreement document until they felt they no longer needed it. You could still use something like the current Agreement interface for doing all the monitoring stuff. (The lifetime issues for that resource would be simpler.) I also believe, and always have, that having an agreement represented primarily as a document is a far more intuitive approach. I think that the advantages of this representation should be fully considered now. Jon. On Mar 22, 2005, at 8:16 PM, Karl Czajkowski wrote:
I agree the lifetime management is hard. :-) I wonder if this sort of scenario is not a good point in time for the client/initiator to:
1) Use the Agreement interface to capture the status and/or other identifying information.
2) "Retire" the Agreement by allowing it to be destroyed.
3) Have offline compensation using the captured status and identifying information.
As I have said before, I think there is a practical limit to what can be done in the online, automatic system view of WS-Agreement. Shutting down/destroying those interfaces should not necessarily destroy records but just shift the information out of the online message processing system and into audit/accounting.
Trying to negotiate compensation between humans is definitely out of scope (and too hard) for WS-Agreement, I would say. I guess I would frame the question as what sort of support is needed to allow such conversations to continue after the Agreement is terminated, e.g. access to "final state" and/or naming information that can be passed around offline?
karl
On Mar 22, Jon MacLaren loaded a tape reading: ...
It may be OK to "garbage collect" the agreement after all the terms have successfully completed. But where one or more terms have been violated, the initiator will want to be able to point at the agreement for an arbitrary length of time afterwards. They may wish to seek compensation through some out-of-bands methods.
Let me give a motivating use-case.
Lets say that something goes wrong with the execution of my job. Perhaps we'd agreed that it would execute at 4pm, but it didn't start until 4.30pm. I am offered a partial refund, but want to argue for more. I'll do this by email, but will want to refer to the agreement in some way...
Lifetime management for this sort of thing is hard.
karl
Jon.
-- Karl Czajkowski karlcz@univa.com
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
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
On Mar 23, Jon MacLaren loaded a tape reading:
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.
Nothing except for the same WS-A guidelines that we would now be violating in making a particular signature algorithm part of the standard. Which method would you suggest? I don't even know what identification standard we can assume for the agreement parties... PKI? Kerberos? <Username, password>? Which community do we decide is _the_ community for WS-Agreement? I need PKI for Globus Toolkit deployment, but I am sure others need something else. So, if we factor out signature itself as something that must come from a profile of WS-Agreement and security specs, then all we have left is the initiator sending the document once (where it could possibly be signed) and the responder sending it once (where it could possibly be signed). We do not currently have the responder sending the agreement document, since it seemed "redundant" to the people who do not care about this signature dance. I see this as a justifiable reason to put it back in spite of its "redundancy". We could put it in the output of the createAgreement and the input of the acceptAgreement [if we go w/ the proposal I summarized again recently]. Or, we could say that the initiator MAY fetch it anytime after acceptance by fetching an RP containing the document, e.g. AcceptedAgreement, which would be nil until the acceptance decision is made. I don't know how to allow arbitrary signature content to appear within the WS-Agreement messages (where we currently have the agreement doc element). I do, however, think it is trivial to have the sending party sign the _entire_ message and use that rather than trying to embed signature at the application level. However, it seems impossible to mandate that "both" parties have signed the responder-generated document, since we do not have any way of specifying what it means to have signed it. I think that, too, would have to be in a secure-agreement profile. I am not sure it is even strictly necessary, when one can retain the two unilaterally signed messages and present them together to show agreement. karl -- Karl Czajkowski karlcz@univa.com
On Mar 23, 2005, at 8:44 PM, Karl Czajkowski wrote:
On Mar 23, Jon MacLaren loaded a tape reading:
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.
Nothing except for the same WS-A guidelines that we would now be violating in making a particular signature algorithm part of the standard. Which method would you suggest? I don't even know what identification standard we can assume for the agreement parties... PKI? Kerberos? <Username, password>? Which community do we decide is _the_ community for WS-Agreement? I need PKI for Globus Toolkit deployment, but I am sure others need something else.
I'd imagined using XML Signature for doing this stuff. That allows a number of different methods for signing to be plugged in, and is certainly not specific to any signature algorithm, and I believe it does not fall foul of the WS-A guidelines you mention. If you feel it does, please send a precise reference to some text. For information on XML Signature, see: http://www.w3.org/TR/xmldsig-core/ I don't know a lot about Kerberos, and so I don't know how well that maps onto this idea. Of course, the point of signing something in this context is that you can later show that such-and-such an entity signed something. This must be valid outside of whatever exchange (session) is taking place at the time. Are Kerberos tokens appropriate for this purpose?
So, if we factor out signature itself as something that must come from a profile of WS-Agreement and security specs, then all we have left is the initiator sending the document once (where it could possibly be signed) and the responder sending it once (where it could possibly be signed). We do not currently have the responder sending the agreement document, since it seemed "redundant" to the people who do not care about this signature dance. I see this as a justifiable reason to put it back in spite of its "redundancy".
That would be a good step forward, assuming that you are not suddenly persuaded by what I've written above...
We could put it in the output of the createAgreement and the input of the acceptAgreement [if we go w/ the proposal I summarized again recently]. Or, we could say that the initiator MAY fetch it anytime after acceptance by fetching an RP containing the document, e.g. AcceptedAgreement, which would be nil until the acceptance decision is made.
I'd want the first suggestion. (I don't object to the second as an *additional* method.)
I don't know how to allow arbitrary signature content to appear within the WS-Agreement messages (where we currently have the agreement doc element). I do, however, think it is trivial to have the sending party sign the _entire_ message and use that rather than trying to embed signature at the application level.
Again, see what I've written above.
However, it seems impossible to mandate that "both" parties have signed the responder-generated document, since we do not have any way of specifying what it means to have signed it. I think that, too, would have to be in a secure-agreement profile. I am not sure it is even strictly necessary, when one can retain the two unilaterally signed messages and present them together to show agreement.
karl
The semantics of what it means, in this context, to have signed the agreement are ours to define. Given that we all understand what it means when we sign a contract or Paper-Agreement, I think that this part is quite simple. Jon.
On Mar 24, Jon MacLaren loaded a tape reading: ...
I'd imagined using XML Signature for doing this stuff. That allows a number of different methods for signing to be plugged in, and is certainly not specific to any signature algorithm, and I believe it does not fall foul of the WS-A guidelines you mention. If you feel it does, please send a precise reference to some text.
For information on XML Signature, see: http://www.w3.org/TR/xmldsig-core/
I have to admit that I am not an expert at the use of XML security standards, so I am largely echoing what I have been told by security and WS experts...
I don't know a lot about Kerberos, and so I don't know how well that maps onto this idea. Of course, the point of signing something in this context is that you can later show that such-and-such an entity signed something. This must be valid outside of whatever exchange (session) is taking place at the time. Are Kerberos tokens appropriate for this purpose?
I don't know, but that is the thrust of my point. I am extremely uncomfortable stating that WS-Agreement should try to normatively define/choose a sessionless identification and signing model for agreement parties. I don't think we want to close it off from the communities who do not use such security models. I personally like PKI, but have learned that not everyone does. ;-) I really think this bottomless pit of options needs to be addressed in profiles outside WS-Agreement. But, the advice I have received is that it would be sensible to use XML-Signature "detached" signatures and put them in extended content as a sibling to the agreement document. So, at minimum WS-Agreement should make sure to have appropriate extension points to be able to trigger and exchange extra signature info. To me, this means having an extension model where something like a "request for signature" can be marked MANDATORY in an offer, meaning the responder MUST sign his acceptance message or reject the offer if he is unable/unwilling. In our zeal for extensibility of agreement terms, I am not sure whether we have kept extensibility for these sorts of signaling options. Can we agree on this as a compromise approach? I'd really like to focus on the generic WS-Agreement plumbing and enable experimentation and community-specific profiles to address these sorts of problems on top of the base specification.
We could put it in the output of the createAgreement and the input of the acceptAgreement [if we go w/ the proposal I summarized again recently]. Or, we could say that the initiator MAY fetch it anytime after acceptance by fetching an RP containing the document, e.g. AcceptedAgreement, which would be nil until the acceptance decision is made.
I'd want the first suggestion. (I don't object to the second as an *additional* method.)
One minor variant, after having bounced this off some people outside GRAAP-WG, is that if we did the first we should retain an ability to do it with or without the verbose response message. I don't know if this should be multiple operations w/ different message typing, or one generic message with some optional control bits in the input to modify the required response?
The semantics of what it means, in this context, to have signed the agreement are ours to define. Given that we all understand what it means when we sign a contract or Paper-Agreement, I think that this part is quite simple.
Jon.
I didn't mean the semantics of signature, but rather how we could specify the syntax of signature without delving into mechanism-specific stuff. In other words, I didn't know how to make a normative statement about presence or absence of signatures. It's a moot point, if we can agree on the more specific discussions above. karl -- Karl Czajkowski karlcz@univa.com
On Mar 24, 2005, at 8:53 PM, Karl Czajkowski wrote:
On Mar 24, Jon MacLaren loaded a tape reading: ...
I'd imagined using XML Signature for doing this stuff. That allows a number of different methods for signing to be plugged in, and is certainly not specific to any signature algorithm, and I believe it does not fall foul of the WS-A guidelines you mention. If you feel it does, please send a precise reference to some text.
For information on XML Signature, see: http://www.w3.org/TR/xmldsig-core/
I have to admit that I am not an expert at the use of XML security standards, so I am largely echoing what I have been told by security and WS experts...
I don't know a lot about Kerberos, and so I don't know how well that maps onto this idea. Of course, the point of signing something in this context is that you can later show that such-and-such an entity signed something. This must be valid outside of whatever exchange (session) is taking place at the time. Are Kerberos tokens appropriate for this purpose?
I don't know, but that is the thrust of my point. I am extremely uncomfortable stating that WS-Agreement should try to normatively define/choose a sessionless identification and signing model for agreement parties. I don't think we want to close it off from the communities who do not use such security models. I personally like PKI, but have learned that not everyone does. ;-) I really think this bottomless pit of options needs to be addressed in profiles outside WS-Agreement.
But, the advice I have received is that it would be sensible to use XML-Signature "detached" signatures and put them in extended content as a sibling to the agreement document. So, at minimum WS-Agreement should make sure to have appropriate extension points to be able to trigger and exchange extra signature info. To me, this means having an extension model where something like a "request for signature" can be marked MANDATORY in an offer, meaning the responder MUST sign his acceptance message or reject the offer if he is unable/unwilling. In our zeal for extensibility of agreement terms, I am not sure whether we have kept extensibility for these sorts of signaling options.
That sounds like a good way to support the behaviour I was looking for.
Can we agree on this as a compromise approach? I'd really like to focus on the generic WS-Agreement plumbing and enable experimentation and community-specific profiles to address these sorts of problems on top of the base specification.
Yes, the approach you mention above sounds fine.
We could put it in the output of the createAgreement and the input of the acceptAgreement [if we go w/ the proposal I summarized again recently]. Or, we could say that the initiator MAY fetch it anytime after acceptance by fetching an RP containing the document, e.g. AcceptedAgreement, which would be nil until the acceptance decision is made.
I'd want the first suggestion. (I don't object to the second as an *additional* method.)
One minor variant, after having bounced this off some people outside GRAAP-WG, is that if we did the first we should retain an ability to do it with or without the verbose response message. I don't know if this should be multiple operations w/ different message typing, or one generic message with some optional control bits in the input to modify the required response?
Again, no objection. I'd probably go for same operation, with an extra flag. Makes it easier to switch from using one to the other in code. And to all intents and purposes, you're doing the same thing...
The semantics of what it means, in this context, to have signed the agreement are ours to define. Given that we all understand what it means when we sign a contract or Paper-Agreement, I think that this part is quite simple.
Jon.
I didn't mean the semantics of signature, but rather how we could specify the syntax of signature without delving into mechanism-specific stuff. In other words, I didn't know how to make a normative statement about presence or absence of signatures. It's a moot point, if we can agree on the more specific discussions above.
Done! Jon.
karl
participants (2)
-
Jon MacLaren -
Karl Czajkowski