RE: Draft registration of application/soap+xml

Mark,

	Thanks for your comments. Here are some of my initial thoughts. If we find
them valuable we can wordsmith and incorporate them. I am not sure how we
handle these - as recommendations or as things a service can expect. The
intent is to provide as much shared and common understanding as possible.

	This is kind of related to the "simplicity" thread floating around.
Protocols/mediatypes and other definitions should make things explicit &
clear so that implementors would have less to interpret and more to
implement. (I better stop rambling on this topic before it gets muddy ....
:o()

	1.	Visibility Rules:

		My thinking was to expand section 5 as follows:

		The root element ..... <same as now>

		Add "Under the root element, if the optional Header element is present, it
would be visible as an element. In addition, some of the sub elements (to
the Header) would be visible as well.

		Note : If a new protocol uses the "application/soap+xml" type, it should
indicate which elements would be visible and which elements need not be
visible.

		The mandatory Body element would be visible as an element, but all the
sub-elements could be encrypted."

		The visibility rules are required especially for intermediaries. Like Rich
pointed out in an earlier mail, (the A->B->C->D case) a common understanding
of visibility when one deals with the "application/soap+xml" is essential -
What *could* be encrypted, what wouldn't, what could be trusted,...

	2.	Trust Models:

		I would like to see a section on trust model and even if it says that the
trust model is implicit and the SOAP processor trusts the previous
processors to an extent, that is fine. Most probably we would expand a
little bit. I agree that these might not be traditionally be part of media
type, but I think with the way things are moving, especially with security,
it is better to have some guidance.

		Again, at this point these are place holders with some initial ideas. We
can quickly wordsmith them and make the sections "specification" ready. I am
not sure a soap processor can trust the previous processor unless there are
some secure measures applied - like SSL or signature. How we can

	3.	Port Number : My ideas are in an answer to Jacek's e-mail.

	4.	I was referring to expanding Mark N's idea of section 3.1 which could be
as follows :

		3. Security Considerations

		3.1 SOAP-Specific Security Considerations

		3.1.1 Confidentiality

		3.1.2	Integrity

		3.1.3 Availability

		3.1.4	Authentication

		3.1.5	Authorization

		3.2 Use of SOAP with Substrate Protocols

		3.2.1 Tunneled

		3.2.2 Non-Tunneled

		Then in the 3.1 sections, we could state what one could expect from the
"application/soap+xml" type. Later, any protocol (like WS-routing or others)
can override this section and add stuff specific to their domain. May be the
WS-Routing would say "use secure channels and do not encrypt the routing
elements" or something similar plus propose a modified trust model.

	Re the question of whether these belong to the media type document, I have
mixed thoughts. One part says we need to have a catch-all document and this
is it. Some of the above definitely belong to the media type document. May
be others belong in the SOAP document. We are not still addressing security
in a holistic way and have no idea where it would be tackled.

cheers


 | -----Original Message-----
 | From: Mark Baker [mailto:distobj@acm.org]
 | Sent: Saturday, January 05, 2002 5:11 AM
 | To: Krishna Sankar
 | Cc: xml-dist-app@w3.org
 | Subject: 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 Monday, 7 January 2002 02:50:57 UTC