As the article points out, it's not really fair to criticize SAML for not using JSON, given that JSON barely existed at the time.
If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.
(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)
I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.
I don't understand this definition of "fair". Things are either good or they're not. Signed XML is not good. That's a fair claim, even if the designers of XMLDSIG didn't know as much as we do.
The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.
My comment was aimed at the particular critique I was replying to, namely, that using XML for ordinary structured data is bad because XML is a markup language. I am not defending SAML more broadly or claiming that none of its mistakes were foreseeable, and particularly am not defending the idea of signing a DOM tree instead of a sequence of bytes. (Though the latter mistake is in principle orthogonal to XML vs. JSON; I confess to not really understanding why they're so correlated.)
XML is as complex as DER, and since there is a way to use XML in ASN.1 -called XER, or XML Encoding Rules-, XML is also as complex as ASN.1, and when you add FastInfoSet, even more still.
XML is deceptively simple-seeming, but it's not simple at all. JSON isn't actually trivial, mind you, but by comparison to XML, ASN.1/DER, etc, JSON is trivial.
The only reason to prefer ASN.1/DER here is that the likelihood of very badly broken libraries that fail to validate signatures becomes comparable to the same for x.509/PKIX certificates: fairly low due to the need for a whole ASN.1/DER ecosystem. It's the must-be-this-tall-to-ride effect.
To be fair to OASIS, in 2002 XML was textual and simple-seeming. It was the obvious choice. It must have seemed brilliant. They didn't know it would turn out badly.
Even with JSON you need solid decoders, excellent libraries, and you'll still want a JSON Schema and tooling.
XML did not become more complex following 2002. DTD, Namespaces, Comments, processing instructions, CData, attribute vs. child dichotomy - all of these things exited from day 0.
XML Schema (just like JSON schema) did not. When we're talking about a "simple format" in terms of security we are talking about parsing footguns like these features, not about complexities that may exist with any wire format such as schema and data validation.
Were there any better formats for simple messages back in 2002?
I would argue that yes.
1. ASN.1 is horribly complex, but PKCS #7 (Cryptographic Message Syntax, a.k.a. CMS) was already established, and it was better than XML Signatures in one regard: it did not try to fuse the signed content with its envelope. But this probably wasn't he best choice.
2. If all you needed is a bag of keys and values, you could easily go with an RFC 822 style header + values format (which worked well for both email protocols and HTML). As a bonus S/MIME was already well established at this point, so you had an obvious way to sign this data.
3. Simple binary formats like XDR (used by NFS) or simple textual formats like LDIF or the RFC 822 header format mentioned above could be freely combined with any existing signature protocol that did not mandate structured data (i.e. every signature protocol in existence before XML Signature came in).
4. An even better approach of course, would have been to say no to fine-grained cryptographic agility[1]. That was a terrible mistake, but it was the default design choice back in 2002, and it's hard to single out OASIS. The JOSE/JWT authors should have known better though. You could have define a couple of ciphersuites/version, and a simple, fixed signature protocol for each version.
5. The best approach would have been to just avoid signatures completely and require TLS, but this wasn't viable back in 2002. Even OAuth 1.0 and OpenID 1.0, which came out several years later, included their own cryptographic signatures, but their schemes were still far simpler than SAML.
I think the key takeaway today is that SAML is no longer necessary today. TLS is not an option for secure web resources. There are no features of SAML that cannot be supported by OAuth or OIDC (only security misfeatures). All IdPs and most products support OIDC. In fact, OIDC is probably more well-supported than SAML.
SAML is only used because of enterprise inertia and self-inflicted FUD. As a professional, we should treat SAML with the the same disdain we've directed
we've directed towards Internet Explorer 6. This is an insecure legacy technology that presents a drag on the entire industry.
1. Disagree. I think ASN.1 is not horribly complex, but I think BER/DER (which, yes, are in the ASN.1 family) and XML are.
2. Yes, unless you need much more structure, then you have to think about ASN.1, XDR, PB, JSON, etc.
3. XDR is a perfectly reasonable basis for an ASN.1 encoding rules family. In fact, PER/OER resemble XDR in many ways. XDR is only simple because a) it's way simpler than the supposedly-simple tag-length-value encodings that ASN.1 came with originally, and b) Sun actually built a solid codegen tool (rpcgen(1)) for it. Never underestimate the value of having excellent tooling as a way of simplifying things :)
4. Alg. agility needs to be tied to the signing keys, not allowed to vary in the headers. Apart from that, you do need alg. agility, so its complexity can be minimized, but not made to disappear.
5. No, because TLS only establishes a channel between two entities, but here we have three or more entities: the two end-points of a TLS connection + all the trusted third parties. The trusted third parties need to communicate to entities they have no direct connection/channel to, and having those pairs of peers initiate connections to get those items is actually quite complex for reasons.
5. It really is the case that signed tokens are extremely handy and simpler than not having them -- it's just that getting signed tokens right has proved tricky in part due to advances in cryptanalysis exposing design mistakes no one knew they were making decades ago.
I’d point out that it’s possible for SAML to be acknowledged as okay or “good for its time,” even, and also be acknowledged as today amounting to a steaming pile of crap that ought to be avoided and phased out wherever possible. Even if all its flaws were just the bad luck of existing before other things were invented.
We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.
Saml serializing to XML is not a problem at all, the problem is then including the signature within the XML, which Saml idiotically does. They could just as well have appended it to the xml with a separator. There's nothing about that that couldn't have been understood in 1995 or so.
I think ASN.1, specifically DER, actually would have been better because it avoids the canonicalization problems saml has, as well as the general XML problems like XXE.
If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.
(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)
I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.