4 ms·

> The biggest problem with SAML is probably XML-DSig. I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s o

by zeveb 7y ago

> The biggest problem with SAML is probably XML-DSig. I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. My personal opinion is that it set the industry back by a decade. It just blows my mind the amount of effort (time & money) which was poured into such a flawed architecture. Ditto Java, really. The early-2000s vision was one great mass of Java & XML. Why we didn't stick with Lisp & S-expressions I'll never know.

lvh 7y ago
I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like a fundamental mistake and sexp-dsig would not have been a better spec. All of the problems you get from in-band signing and encryption are still there--case in point, our blog post on how not to sign a JSON object[0] would be a fine spike on a blog post about why XML-DSig is bananas. (One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.) [0]: https://latacora.micro.blog/2019/07/24/how-not-to.html https://latacora.micro.blog/2019/07/24/how-not-to.html
Edmond 7y ago
The problem with SAML et al is not Java or XML. The problem is the spec conflating transport protocol concerns with the content format concern. If you can cleanly separate the transport component's cryptography (making sure the content is secure and private) from the formatting and processing of the actual content it makes things a lot clearer.
throw0101a 7y ago
> I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. The alternative was SGML. Would you have preferred that, because that was the 'only' over option at the time. It would be like saying twenty years from now: "wow, I'd love to learn why people used fossil-fuelled cars instead of EVs: ICE cars are so inferior". Well, at the time nothing better had been developed and we did the best we can.

by zeveb 7y ago

lvh 7y ago

I'm a lisper and dislike XML as much as the next guy, but XML-DSig seems like a fundamental mistake and sexp-dsig would not have been a better spec. All of the problems you get from in-band signing and encryption are still there--case in point, our blog post on how not to sign a JSON object[0] would be a fine spike on a blog post about why XML-DSig is bananas. (One counterexample I can think of: you probably wouldn't do CDATA and comments the same way as XML did, which led to Kelby Ludwig's fantastic SAML auth bypass--which also gets a review in that blog post.) [0]: https://latacora.micro.blog/2019/07/24/how-not-to.html https://latacora.micro.blog/2019/07/24/how-not-to.html

Edmond 7y ago

The problem with SAML et al is not Java or XML. The problem is the spec conflating transport protocol concerns with the content format concern. If you can cleanly separate the transport component's cryptography (making sure the content is secure and private) from the formatting and processing of the actual content it makes things a lot clearer.

throw0101a 7y ago

> I hope that I live long enough to read the book-length historical treatment of the late 90s/early-2000s obsession with XML. The alternative was SGML. Would you have preferred that, because that was the 'only' over option at the time. It would be like saying twenty years from now: "wow, I'd love to learn why people used fossil-fuelled cars instead of EVs: ICE cars are so inferior". Well, at the time nothing better had been developed and we did the best we can.