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

[Karl Czajkowski]

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 at univa.com