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.