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

[Jon MacLaren]

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.