RE: 2.0 Draft 8

Philip/Joe,

	Exactly. I support the layering principles and the ever famous
orthogonal extensibility. May be a simple diagram could be :

	-----------------------------------
	XKMS App
	-----------------------------------
	XKMS Security Primitives
	-----------------------------------
	XKRSS
	-----------------------------------
	<Transport Protocol> (Eg. SOAP/BEEP)
	-----------------------------------
	Transport (HTTP,SMTP,...
	-----------------------------------

	The "binding" should crisply and clearly specify how the XKMS
security (i.e. security native to the XKMS domain) is achieved over any
transport. It also should clearly have specifications for the common
transports (as you have mentioned) SOAP/https, SOAP/HTTP,... I agree
with you that there could be some forward references
to-yet-to-be-developed-standards :o) Of course, that is not possible. We
have an opportunity here to provide some thought leadership and
cohesiveness.

	Your outline looks good with normative SOAP/HTTP as the reqd and
(optional) XKMS/HTTP, WS-Security/SOAP/HTTP. I assume #6, SOAP SSL is
also a required binding and a #3 variation could be SOAP/https. Please
do circulate a first draft - I would like to see if we could get some
f2f time on this somewhere down the line. 

	Because of the moving parts, we might have to have a good XKMS
security layer independent of the transport. In that regard, do we plan
to have some mini-choreography like req/resp with ack ? What do you
think on fault propagation ?

	I, myself, would be in and out of Europe for the next 3 weeks on
some EU security work - but can work with you if needed. XKMS would be a
good thing to read during those long trans-Atlantic flights and train
rides :o)

cheers

|  -----Original Message-----
|  From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] 
|  Sent: Friday, June 14, 2002 9:06 AM
|  To: 'reagle@w3.org'; Hallam-Baker, Phillip; 'Krishna 
|  Sankar'; 'Www-Xkms (E-mail)'
|  Subject: RE: 2.0 Draft 8
|  
|  
|  I think that the advantage in this case is that we can 
|  explicitly state the
|  security assumptions that XKMS depends upon and how to apply 
|  each choice of
|  underlying technology.
|  
|  However, Regardless of how the message security is organized 
|  XKMS will be
|  using its own security on top in XKRSS, e.g. we never send 
|  private keys
|  en-clair at the XKMS level even if we know the transport is secure.
|  
|  		Phill
|  
|  > -----Original Message-----
|  > From: Joseph Reagle [mailto:reagle@w3.org]
|  > Sent: Friday, June 14, 2002 11:38 AM
|  > To: Hallam-Baker, Phillip; 'Krishna Sankar'; 'Www-Xkms (E-mail)'
|  > Subject: Re: 2.0 Draft 8
|  > 
|  > 
|  > On Friday 14 June 2002 11:30 am, Hallam-Baker, Phillip wrote:
|  > > 	What I propose that we do is to move most of section 2, 
|  > except for
|  > > the schema discussion out of the XKMS document and make it 
|  > a standalone
|  > > 'message binding' document. This would have the 
|  following outline.
|  > 
|  > I'm a big fan of seperating specification to provide clarity 
|  > with respect 
|  > to dependencies and layering. In the end if parts are similar 
|  > mature and 
|  > such, they can be recombined, but during the development it 
|  > proves to be 
|  > useful to me.
|  > 
|

Received on Saturday, 15 June 2002 14:48:05 UTC