RE: Proposed issue; Visibility of Web services

[Thanks for moving this to www-ws, Mark; and sorry to copy you if you don't
wish to be on this, Noah.]

> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of
> Mark Baker
> Sent: Sunday, May 25, 2003 11:49 PM
> To: www-ws@w3.org
> Cc: noah_mendelsohn@us.ibm.com
> Subject: Re: Proposed issue; Visibility of Web services
> 

> Specifically, as it relates to my proposed TAG issue, visibility is
> poor, and firewalls will not, in general, permit those 
> messages to pass.

Mark, I spent an awful lot of time trying to understand "visibility" under
your tutelage :-) Once I grokked it, I decided that the principle is indeed
a very important one, but that XML's standard syntax and pattern-matching
tools provides a mechanism for intermediaries to look inside XML-based
messages just as the TCP/IP and HTTP headers provide visibility in a world
where message payloads are opaque.  For example, a "classic" firewall can
look at the IP address, the TCP port, and the HTTP verb (and perhaps other
HTTP headers, I don't know) to make a "let this through?" decision.  A
modern firewall can look at WS-security (or other SOAP-based) headers to
find/check authentication tokens, security assertions, digital signatures,
etc.  Neither type of firewall has to know anything about the
application-level semantics of the message body, hence both have the
"visibility" property.  

The "classic" firewalls are widely deployed, simple, and cheap -- but
require severe constraints on the architectural style of the underlying
application to enable it to work within their constraints.  As a practical
matter, the more or less laughable state of security on the Web today is a
strong indication that the app developers of the world are either not
willing or able to work within these constraints, IMHO. Still, I would agree
that anyone building an application today for wide deployment over the Web
(as opposed to over an intranet) SHOULD understand and work with these
constraints.

But what we're talking about here are fundamental principles, not
contemporary pragmatics.  The XML-powered firewalls are just coming into
production, and will require more standardization of things like WS-Security
to really hit their stride, but the *principle* of XML-based "visibility"
seems very strong to me.  Without XML, message payloads are essentially
opaque to intermediaries, and I fully appreciate how Fielding's analysis
applies. But with XML (and SOAP), intermediaries can logically and
practically understand XPath expressions that define patterns to look for to
make routing/filtering/cacheing decisions, they can understand the SOAP
processing model and look for headers they do understand or MUST-UNDERSTAND,
and they can exploit XML/SOAP-based standards for routing, encryption,
signatures, authentication, etc.

So what's the "error" in this argument that you want the TAG to set me (as a
WSA editor) straight about?

Received on Monday, 26 May 2003 09:39:22 UTC