W3C Approves New Security, Validation for XML
The W3C has taken two steps forward to ensure better security for XML data transfers, setting the stage for secure web services within a company's enterprise or even with B2B transmissions. At issue is the adoption this week of standards for two new secure protocols.
New standards for the XML Encryption Syntax and Processing (update to a proposal first made in August 2002) and Decryption Transform for XML Signature (extension to an XML Signature proposal first made in February 2002) would combine to enable developers working with data sharing and web services transactions to use individual XML data elements. Prior to these standards, XML security standards focused on entire preformatted XML documents -- not on giving developers the ability to parse the elements of a document into individually secured messages.
This more granular XML security technology could prove useful for numerous tasks, especially to developers and users of online commerce and web services. For example, parsing such individual XML data elements would enable more secure two-party transactions, letting a buyer purchase an item by credit card, for instance, without disclosing that number directly to the seller's website operators. The credit card number could be encrypted and sent "in-the-blind" to a credit card authorization service for approval.
"XML Signature and Encryption are like a stack at the bottom of XML. Now, down there you'll always have some [security token, such as] an X.509 certificate and above that you have SOAP. So the real question is how to send XML from Point A to Point B when you're putting a security token into a SOAP message, and then signing it, said Mark O'Neill, the author of the upcoming "Web Services Security" book from McGraw-Hill (coming January 2003). He is also CTO of Vordel Inc. a Boston-based provider of Web services security software. Pulling all that together is what WS-Security will do." While WS-Security is still a "bit of a moving target," O'Neill said these latest W3C standards will pin it down a bit more.
The details of the plan would provide developers a common syntax (or coding template) for ways to build such encryption capability into their XML datasets.
XML Encryption Syntax - A Developer's View
In the XML Encryption Syntax and Processing proposal, for instance, the EncryptedData element has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences; and the empty element tag means the element must be empty):
<EncryptedData Id? Type? MimeType? Encoding?>
In the above example, the W3C proposes that the "CipherData" element envelopes or references the raw encrypted data. If enveloping, the raw encrypted data is the CipherValue element's content; if referencing, the CipherReference element's URI attribute points to the location of the raw encrypted data. The proposal also specifies other elements of the encryption syntax, processing rules for encryption and decryption, and a discussion of various algorithms needed to do the processing of such encrypted or decrypted data.
Decrypting XML Signatures -- A Developer's View
The Decryption Transform for XML Signature aims to ensure data integrity and security for workflow or multiparty transactions. The W3C puts forth the following scenario:
Both [XML-Signature] and [XML-Encryption] operations may be performed on an XML document at any time and in any order, especially in scenarios such as workflow. But sometimes, this "any order" feature of encryption can cause problems.
As an example, W3C offers the following:
Alice wishes to order and pay for a book from Bob using the mutually trusted payment system, ZipPay. Bob creates an order form including the book title, price and his account info. He wants to sign all of this information, but will subsequently encrypt his account info for ZipPay only. He sends this to Alice, who affirms the book title and price, signs the form and presents the twice-signed order with her own payment information to ZipPay. To validate both signatures ZipPay will have to know that the cipher data version of the encrypted information is necessary for validating Alice's signature, but the plain data form is necessary for validating Bob's signature.
In proposing its decryption standard, the W3C claimed that it is a resolution to the decryption/verification ordering issue within signed resources. The standard is designed to leverage the earlier-proposed W3C standard for XML Encryption Syntax and XML-Signature Syntax. But it also breaks the implied association between the two, using the following prefixes:
Developers can also take some relief from the fact that public disputes of the standards appear unlikely, at least for now. The XML encryption technology was developed and forged into standards by many of the key companies comprising W3C's encryption working group, who are involved in other web services initiatives -- firms such as Microsoft, IBM, Sun, VeriSign and BEA Systems.
The W3C approvals come even as another XML standards debate continues: Does the B2B sector need a common "superXML schema" to be used by all companies within a vertical market, or should individual companies continue to use their own proprietary XML schema and simply conduct XML transformations when such data need to be passed outside to a partner (supplier, service provider, authentication firm, etc.) company? Stay tuned for the answer.