W3C Eyes New Security Protocols for B2B XML

The W3C has taken two steps forward on its proposal for two new protocols to ensure better security for XML data transfers. Developers have until Halloween to tell W3C if it's headed in the right direction with the latest plan. The proposals, XML Encryption Syntax and Processing and Decryption Transform for XML Signature, would enable data sharing and web services transactions to use smaller XML data elements rather than entire XML documents. See if the plans are a trick or treat in time for your comments.

Tags: XML, Encryption, Proposals, Decryption, Encryption Syntax, Transform, Security,



The W3C has taken two steps forward on its proposal for two new protocols to ensure better security for XML data transfers. Developers have until Halloween to tell W3C if it's headed in the right direction with the latest plan.


The proposals, 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 enable data sharing and web services transactions to use individual XML data elements. Existing and pending XML security standards focus on entire pre-formatted XML documents.


There are numerous examples where this more granular XML security technology could prove useful, 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.


The details of the plan would provide developers a common syntax (or coding template) for how 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?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
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 is aimed at ensuring data integrity and security for workflow or multi-party 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."
"For example," W3C proposes, "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."


"W3C's Decryption proposal is a resolution to the decryption/verification ordering issue within signed resources," the W3C said. The proposal is designed to leverage the earlier-proposed W3C standard for XML Encryption Syntax and XML-Signature Syntax. But it also defines its own proposal to break the implied association between the two, using the following prefixes:

    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dcrpt="http://www.w3.org/2002/07/decrypt#"
Both W3C proposals are formal Proposed Recommendations (PR). Comment is open until October 31. For both XML-Encryption and XML-Signature, comments should be made to the W3C editors (merlin@baltimore.ie, imamu@ip.ibm.com, and maruyama@ip.ibm.com), and cc'ed to the public mailing list: xml-encryption@w3c.org.


The W3C proposal comes even as another XML standards debate continues over whether the B2B sector needs a common "superXML schema" that all companies within a vertical market could/should use, or whether individual companies could 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."



back