XML Signatures: Behind the Curtain - What They Don't Tell You in the Specification
(Page 4 of 9 )
There is also an implicit assumption here, and it's in-your-face obvious upon due examination. XML is Web- and server-based. It's a sort of thin-client approach, as opposed to the "damn the bandwidth, load the servlet" approach of Java. XML signatures will therefore use the Web (via URLs in the XML) to find out the method to encode or decode things. Exactly how it uses the Web can be syntactically specified (as demonstrated in the technical discussion that follows), but that kind of discussion ignores the meta-question of what URL to use. That is, if the signature needs 'Net resources to complete its action, then who will supply those resources? If this sort of signature becomes a widely-used "semaphore" for authentication of messages and transactions, whichever URLs are pointed to in the XML code can become a de facto standard for authentication services. But wait, there's more. The real use of authentication services will most likely be found in Web shopping; rather than, for example, secured e-mail. A merchant will want to know that he is receiving a valid order from a customer, and so will insist on some form of acceptable authentication. This is the sort of problem that was first solved by Electronic Data Interchange (EDI) systems that used secured networks to operate. Over the insecure Internet, the same previously-solved operational problems remain open. The XML signature process is meant to address this in a sweeping way, but that sweep is part of the problem. This little-known candidate carries in it the seeds of a method for some company to monopolize Internet authentication services.
Let me posit a scenario. Imagine that some Commercial Off The Shelf (COTS) software company decides it wants to be the authorization service that all must pass through to get things done. Also further posit that this COTS proprietary operating system is found on the majority of the deployed systems under consideration. The COTS vendor then brings out an Xtra Proprietary version of its OS, which contains a client that uses XML signatures (and only XML signatures) for security. All the XML code points to this vendor's servers to provide information, sort of like a non-public PKI infrastructure. This client becomes widely used for authentication simply because it's easy to set up as a default since the OS is widely used. Also, said manufacturer embeds it in its popular "free" browser as the default security mechanism.
To put the icing on the cake, say this vendor starts to charge someone (perhaps the merchant and, indirectly, the consumer) every time its servers are used for authentication by this client. Voila! Monopoly and revenue streams all in one.
Now, having used these security services in good faith, a merchant might find that these services don't actually address underlying problem -- that of "chargebacks" from the credit card companies. These chargeback issues -- where people acknowledge that they had an agreement or some contact with the merchant but claim that the merchant did not performed in some or all aspects as promised (like nothing delivered, or the order was cancelled, or some other reason) -- are part of the credit card issuer's business model and beyond the scope of an XML signature specification. Indeed, in the US the Fair Credit Billing Act (15 U.S.C. 1666-1666j) preserves the customer's right to make arguments with an issuing bank about the correctness of a bill (including amount, computation, timing, and delivery/receipt of goods/services). Those rights can't be waived by contract.
I'm coming to the windup here.
So, even if schemes like XML signatures are in place and being used, they may not address the real world problems they were supposed to solve. Given that, and the potential for abuse by greedy companies to establish a 'Net monopoly, use of this technology may end up unsatisfying. That doesn't mean that a developer may have to, in the long run, use this sort of scheme just to be compatible; but don't think that it's just a magic incantation, either. Companies other than the largest ones may develop unique authentication services, and using them may require small rewrites in the XML code. The true problem may be the unquestioning acceptance of manufacturer-supplied XML signature code. So let's take a look at the tech specification with an eye towards understanding where things may need to be changed as services evolve.
Next: The Geek Part >>
More XML Articles
More By Larry Loeb
