It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up.
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
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.)
jmbwell · · focus · HN ↗
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
ameliaquining · · focus · HN ↗
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.
tptacek · · focus · HN ↗
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.
ameliaquining · · focus · HN ↗
tptacek · · focus · HN ↗