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.
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.
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)
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)
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.
cheers & Happy New Year
| -----Original Message-----
| From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
| Behalf Of Rich Salz
| Sent: Friday, January 04, 2002 9:31 AM
| To: Mark Baker
| Cc: xml-dist-app@w3.org
| Subject: Re: Draft registration of application/soap+xml
|
|
| I don't think it's necessary to get into the whole tunneled thing here.
| It is simpler (and less controversial) to say that the message may avail
| itself of underlying transport-level security, and/or that XML features
| such as DSIG and XMLENC may be used to provide soap-level
| security features.
|
|
| > The SOAP processing model itself is entirely innocuous from
| a security
| > perspective.
|
|
| I don't think so, since it doesn't seem feasible to encrypt the actor
| and mustUnderstand values. If a message is intended to go A->B->C->D
| but encrypted so only B knows the C-uri, then an adversary could
| redirect the message from B directly to D.
| /r$
| --
| Zolera Systems, Your Key to Online Integrity
| Securing Web services: XML, SOAP, Dig-sig, Encryption
| http://www.zolera.com
|
|