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

[Jon MacLaren]

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