Freeze the Core

XML

Obviously, the most basic standard is XML itself. First published in 1998, it has been revised twice, to mainly clear up errors and ambiguities in the prose. So we now have XML 1.0 (Third Edition), but we also have XML 1.1. Interestingly, both were published this February.

So, what are the differences, and do they matter to web services? The differences are actually pretty minor. It turns out, however, that they end up being incredibly important, such that web services should ignore XML 1.1 for the foreseeable future. Let's look at why.

XML 1.1 adds some new characters to the list of what can be in a name. It also requires that some characters that were legal within content--the control characters between 0x7F and 0x9F--now have to be escaped. One the surface, these seem like minor changes. But when you add in the required XML processing model--any error detected by the parser must be a fatal error--we find the following:

For an admittedly narrow range, XML 1.0 and XML 1.1 are incompatible.

Dave Orchard, a W3C TAG member, has written more about this, referred to other links, and in general given a great deal of thought about "versioning" in the XML world. See the December 16 and December 12 entries of his blog at http://www.pacificspirit.com for more than you probably care to know.

Since web services involves inter-machine communication, I think it's risky to just glide over this difference. While humans might be unlikely to type 0x80 into a textbox, it's not unreasonable to think machine-generated data--particularly something transcoded from a legacy system--might. As if that weren't enough, XML Schema needs to be modified to support XML 1.1. I've mercifully forgotten the details, but the two character changes interact to make the QName data type a bit more complicated. As a result, since the Schema is a normative (i.e., "official") part of the SOAP 1.2 specification, SOAP 1.2 is officially tied to XML 1.0. Given these three factors, it seems prudent for the web services community to ignore XML 1.1 for now.

SOAP

Let's look at SOAP. I've written before comparing SOAP 1.1 and 1.2. The major difference is really error handling; faults look a little different and come back as standard HTTP responses, not errors. Other than that, there's not a lot of practical difference, which means, for example, that we can use SOAP 1.1 with the SOAP 1.2 processing rules.

In the past few months, a second major difference has come up: attachments. In SOAP 1.1, a message with attachments is a multi-part MIME message, and the SOAP message is the first part. Elements that refer to the attachment content explicitly refer to it, and it is up to the application to fetch the data. In SOAP 1.2 for the HTTP binding, it's also a multi-part MIME message. The only real difference is that if the same part is referenced multiple times, then a SOAP representation header can be required. For internal processing, the attachment data is actually hoisted into the message Infoset (i.e., the DOM for all practical purposes).

We might now have to decided between SOAP 1.1 and SOAP 1.2. The difference in network representations is fairly small, so where can we look for guidance? It turns out there are two places.

The first is the installed base. While SOAP 1.2 products are available, it's clear that the deployed base is overwhelmingly SOAP 1.1. The second place is in security. As we might expect, when both security and standards organizations are involved, the path gets a little complicated.

Message Security

The OASIS Web Services Security Working Group, WSS, has defined a SOAP header that specifies how to use XML digital signatures and encryption to protect SOAP messages from being modified or viewed by the wrong parties. The standard was approved and published in March. WSS also defined a framework for carrying cryptographic keys and identity information (such as a SAML assertion, X509 Certificate, etc.). The framework nature it inherited from the lower-level signature specification also meant the users could define choose from a suite of existing crypto algorithms or even define their own.

In order to make secure SOAP messages interoperable, it was necessary to profile the WSS specification, narrowing down the list of choices. The WS-I created a Basic Security Profile (BSP) working group to do this. The group completed its work a few months ago and presented it to the WS-I Board. Surprisingly, the WS-I board rejected it, sending it back to the group with the instructions that attachments must be part of the profile. In particular, SOAP with Attachments, since the SOAP 1.2 approach was too early.

Since WS-I doesn't create standards but profiles existing ones, this meant that the BSP had to go to WSS and ask them to take on attachments as part of their work. They've done this, and the resultant attachments profile should soon be approved as an official standard. Once this is done, the WS-I folks will be able to update their expanded profile and get it approved this time.

The implication for all this on the web services community is pretty important:

If you want secure SOAP messages with attachments, use SOAP 1.1; if you want secure SOAP messages use SOAP 1.1 or 1.2

By the way, it turns out that securing 1.2 attachments might be difficult. In SOAP 1.2, attachments are hoisted into and out of the Infoset, and there is enough variation (such as whether or not a representation header is used) that two applications could serialize the same message in two different ways. That is, of course, anathema to digital signatures, which requires that there be a canonical form.

Another approach would be to revise the XML Digital Signature standard to be based on the Infoset. Don't hold your breath; security folks aren't common in the XML world, and most of them have moved on to other things. Further, the standard is decidedly, and very subtly, based on the XPath 1.0 data model. Changing the model without losing backward compatibility will be difficult. If only because of the sparse deployment, backward compatibility is very important to security folks.

Wrapping Up

It's possible to look at these issues and come to the depressing conclusion that the web services community is stuck in the past. I claim that's looking at things the wrong way. We now have a solid core of technologies:

• XML 1.0
• SOAP 1.1
• WSDL 1.0 and Schema
• WSS, Signature, Encryption

That's a pretty impressive achievement and reason enough for a year-end celebration. Now, if we can only get those folks working on "improvements" to the core to stop what they're doing and join the party, it'll be a truly great new year.