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