Re: Draft registration of application/soap+xml

Hi Krishna,

> Hi all,
> 
> 	Finally a topic dear and near to my heart - SOAP (and by definition web
> services) Security. Where shall I begin ..........:o) Let me start randomly
> :
> 
> 	1.	Visibility Rules:
> 
> 		We need visibility rules i.e. what part would be visible and what part
> *could* potentially be not visible. For example (I am just thinking aloud -
> which itself is a dangerous preoccupation) the header, Actor and SOAPAction
> would be visible while the body need to be assumed as opaque.

Is this not implicit in the processing model, or are you suggesting
that we need to extend the processing model to say what should happen
when those visible things you mentioned are not visible?  And by
"visible", I assume you mean that the presence of the thing is visible,
just the value is not?

> 		I also think we should mandate for other potential protocol specifications
> which would ride on the "application/soap+xml" should also clarify this. For
> example the ws-routing protocol would say that the routing information would
> be visible and most probably would be outside the signature. This also has
> implications on trust model.
> 
> 	2.	Trust Models : We need to clearly articulate what trust model
> assumptions we make. Then protocols and other specifications which come
> later and which use the "application/soap+xml" can fill-in their trust
> model. A placeholder with some guidance would be excellent.

Do you have an example?  I would have thought the trust model (based on
my understanding of what one is) was implicit in the processing model.
For example, a SOAP processor trusts that previous processors in the
chain have followed the header re-writing rules.

> 
> 	3.	A new port number ! Can we ask for a new well known port number for the
> "application/soap+xml" messages ? It is high time somebody championed this
> issue - why not us ? :o)

What did you have in mind?

> 	4.	I think we need both the functionality (CIAA) as well as the transport
> security. (This will be more pronounced for things like assertions where we
> will have to deal with Signature Inheritance et al. Not an issue here, but
> would be for app builders - especially web services security)

I'm not sure what you mean here.

> 	Am sure would think of more. But this is a good start. I am not sure
> whether this is the place for these, but IMHO, we need a placeholder so that
> other specifications which come after us in the "application/soap+xml" have
> some guidance, precedence and opportunity.

Actually, I'd say that all of your suggestions above (except for perhaps
the visibility stuff, in part) relate to the SOAP specification itself,
not the media type registration document.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Saturday, 5 January 2002 08:10:51 UTC