Proposed new schema

All, 

	Attached is a somewhat revised schema, the major changes are:

1) Use of Qnames for all enumerated items
	I am somewhat uncertain of the application of the Qnames mechanism,
for example should we link to the qnames defined in other specs, should we
use our own enumeration, how does the extension mechanism work? In general
the case we have is that we want to define a set of basic codes but allow
for extensibility.

2) Message abstract type introduced
	This is the point where we define the transaction ID, signature
semantics etc. It is also the place where we should have a description of
the abstract processing semantics when using payload security.

3) Reason code moved to Keybinding
	where is bellonged (see earlier message)


Some open issues

1) The Pending Response.
	The client should have a mechanism for stating that it will accept a
pending response. [NB this will absorb even more of Bulk into XKMS]. I
suggest a RespondWith Qname Pending.

	If the client proposes Pending then IMHO there should be an optional
mechanism to specify a notification mechanism on completion (c.f. the AST
mechanism of VMS which was the main reason the VMS systems consistently beat
UNIX systems on transaction processing benchmarks even with slower
hardware). This needs to be essentially open as we don't really want to have
to specify the notification protocol, and in many cases this will be
something like an email message is sent. I suggest something like a
method/port pair of URIs similar to what we do in UseKeyWith.

	Introducing this section would allow closure of many of the
questions pending on pending.

2) Precise signing profile
	I believe that what we want to specify is that the signature is
enveloped and that the scope is the entire message node with the exception
of the signature itself.

3) Denial of Service Protection / Replay attack
	Do we need to consider these?

	If we do I think we need to introduce an optional 2 phase protocol
as follows (looking at the Client FSM):

State Initial
	Transition !Request Waiting 
		// Send out initial request to service
		// Go to state Waiting

State Waiting
	Transition ?Response.Complete Completed
		// Service is not in DoS state and does not care
		// about replay attack
	Transition ?Response.Represent Represent
		// Service requires the request to be represented
		// together with an authentication nonce
	Transition ?ANY Fail

State Represent
	Transition !Request Waiting 
		// Represent request to service together with nonce

State Waiting2
	Transition ?Response.Complete Completed
	Transition ?ANY Fail

State Completed
	Terminal
		// We Won 8=)

State Fail
	Terminal
		// We Lost :-(

The nonce is cryptographically bound to the request so that the service can
quickly determine if the nonce presented is valid and corresponds to the
given request (cf JFK).


Ideally the nonce would be bound into the represented request.

Looking to the future this is exactly the type of facility that we would
want to see bound into the Web Services security layer and into WSDL.

I would like the WSDL to tell me the following facts about the service
1) The public key of the service
2) The encapsulation formats the service supports
	[e.g. ws-security, TLS, IPSEC, payload etc.)
3) If a key agreement service is available / must be used
4) If 2 phase DoS protection is available / must be used
	the level of authentication required on the 1st, second message

If I know in advance that the service is definitely going to do DoS
protection then I probably don't want to send a signature on the first
request, in fact I might only want to send a hash of the request.


Clearly this level of protection is something that we might say should be
pushed down into the XP/SOAP layer and can be defered. It would certainly be
simpler to deal at that level since it would be easier to do this type of
processing with a detached signature in a SOAP header. That way the
signature can consist of a pretty simple manifest with clean semantics and
not need to worry about the complexity of enveloped processing.

On the other hand folk might reasonably expect XKMS to provide for DoS and
Replay attack protection.


		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227