I wonder how much technical innovation is simply change so that the developers don't have to talk with the admin/security type folks. There seems to be this regular tension between the devs changing the playing field and the admin folks catching up. I've lately been working on the TAG on the EPR issue and related discussions around State. One of the themes that has come up is the "niceness" of putting identifying information in http cookies and into EPR Reference parameters, rather than in the HTTP URI. This discussion harkens back to the discussions about SOAP tunneling through HTTP POST.
The Dev vs Admin cycle
I think there's a cycle that goes roughly:
1. Developers want easier deployment of applications than they currently have
2. Some solution emerges that vendors/devs/etc. tout as being simpler
3. Technology gains partial adoption in large part because "it's the new thing" but it's not "enterprise ready"
4. Vendors develop and sell technology to admin/secure "the new thing"
5. It gets more complicated to deploy "the new thing"
6. Repeat
Cookies
One of the reasons for using cookies is that it's so easy for a developer to stuff some value, like a session id, into a cookie associated with a web page. In comparison, it's harder to rewrite all the URLs in the web page. It's certainly possible to do URL rewriting, and lots of sites do that. But the alternative is so much easier from a tool and governance pov. There's no need for the developer to ask the admin for a portion of the URI to be available for any of the cookie information, like customer ids or back accounts or …
SOAP
SOAP over HTTP is another great example. By stuffing SOAP requests through port 80, the envelope has mostly been invisible to the firewall folks. They setup "myService:80", messages flow, and subsequent revisions can be deployed without bringing in the URL/port police. 90% of the time, if you go to somebody and say "Can you deploy this service or callback to port 8080 or add a new URL" you will get an "Ack! No, the firewall folks won't let me". So SOAP over port 80 conveniently gets inside the firewall.
After marketing to the devs how much easier it is to build SOAP apps, we can now build SOAP security related products. WS-Security and related specifications provide a wealth of security related technology for SOAP. Ironically, we're now almost back to the point where a network administrator can secure a discrete application for particular users. Tongue firmly in cheek, I guess it's somehow magically easier to say "secure the StockQuote Service defined by this WSDL Endpoint QName" than "secure port 8080 which is running the StockQuote service". And people are saying that it's too hard to deploy WS-* apps because there's all this "extra stuff" - which brings us fully back to step 1.
Ajax
Ajax is being deployed and one of the reasons is it allows the developer to tunnel an application through an existing "simple" web/html application. Because the client-side firewall isn't easy to open up, Ajax allows full programs to be downloaded and run on client machines. Instead of saying "allow the google maps App to run" or "open port 8081 for the IANA registered Google App", we say "go to google maps uri". Tim Berners-Lee has wisely been talking about the problem that this is completely mixing all sorts of content models together, and soon admin types are going to start questioning even allowing so-called Vanilla HTML through firewalls. Starting from "pop-up blockers", we're sure to see "Ajax blockers" sometime soon.
WS-Addressing EPRs
WS-Addressing EPRs are another example of tunneling information, as the EPR minter that's creating an EPR with a Ref Parameter doesn't have to ask the firewall admin for access to the SOAP header block space.
I boldly predict a new security product, the "EPR Security product" which makes sure that an EPR minter isn't putting "illegal" Ref Params into the EPR. All Ref Params will have to be vetted by an administrator. And there will be a client-side product too, that checks to make sure that an EPR Ref Params that are going to be echoed aren't too long, don't conflict with existing soap headers, etc.
Binary XML
One of the major pushbacks against any kind of "binary XML" has been the tunneling aspect. The argument is that if we allowed binary xml, then some big vendor could stuff a bunch of proprietary and non-readable protocol or data elements in a set of XML documents and call it "a standards based xml language". Because XML is textual, it is viewable and more prone to public commentary. Though I note with considerable dismay the efforts that Apple has gone to with ITMS to hide their catalog and data store via encryption, etc., even though they use XML.
It will be interesting to see whether the W3C's binary xml - sorry Efficient XML Interchange - will lead to this kind of tunneling, and what further tunneling is possible.
URIs and XRIs
The folks on the XRI committee have created a format that looks like URIs but allows for "location independent identifiers". I wrote about why http: uris are better than urns and id: uris. As part of the TAG, we pushed back on this technology pretty strongly with little response. The XRI solution is yet another example of where the developer wants to create something without having the admin person be able to approve/disapprove of their choice. Considering that http: uris can do all the things that xris can do IF the http admin allows for persistent identifiers, redirects, etc., it seems the only advantage to xri: is that they allow the developer to create the identifiers without talking to the admin. The XRI folks don't really talk about who's going to approve or populate the mapping of xri: identifiers to locations as this is at the wave the magic wand and don't see that admin over there stage (stage #2).
Types of Tunneling
It's interesting to look at the different types of tunneling. Ajax is about adding more and more functionality into an existing app - the browser - to the point that apps can be run inside the app. We can call this "application tunneling". The container format is HTML in this case. SOAP is about tunneling using a container format, but it is primarily about allowing dispatch to a "hidden" application. This seems to be at a lower level, perhaps we can call this "protocol tunneling". Tunneling a protocol through XML could be considered "format tunneling". And finally, EPRs are about tunneling data that is often location or identifying information. Depending upon the Ref Param type, this could be "address" or "data" tunneling.
Next cycle
After tunneling through port 80 security hole has been closed by WS-Security products, and WS-A EPRs have been closed off by the "EPR Security product", I wonder what's next. Let's see, we need to tunnel through some existing service's "hole". Looking for the same qualities that made HTTP tunnelable (tm), where's a widely deployed app that's nicely extensible and admins are allowing in and out of firewalls and has a lot of buzz so the admins couldn't conceivably lock it out. Let me think… I know, how about blogging?
Blogging, perhaps via standardization of Atom or RSS, has a good chance of being the next app to be tunneled through. It's got all the same things that HTTP had: widely deployed, extensible, lots of hype. No need to register with the security police, just put up a new blog feed. I'm off to start my "blog security" company.
