Comment by bawolff
XML isnt great for that, but the xml part is the least of the concerns. XSignature and SAML are insane specs, and would still be insane if the underlying presentation language wasnt xml (i mean, then you wouldnt be using xsignature, but if you made sone xsignature like thing for a different presentation language, it would still be crazy)
Signatures in XML are nuts. So is all the mess built around RPC in XML, although IMO that’s not as bad as signatures.
But the problem with signatures has nothing to do with XML per se in my opinion. I could just as easily come up with a similarly poor signature scheme in HTML (snicker), nasty C structs with endian issues, MIME, or even plain English. Hah, someone should make a signature scheme meant to be verified by an LLM that parses it and calls out to a helper to do the actual math :)
Seriously, though, signing XML well is easy. Take some XML, serialize it to bytes, sign with libsodium, and transport the bytes of XML and the bytes of signature. But do not get cute and transport the signed XML as a subtree in another XML document: the bytes must bytes until the signature is verified. You could maybe get away with sticking it in another document as CDATA [0], but base64 would be better, since you basically can’t screw it up.
And it’s entirely possible to screw even this up JOSE-style if you lose track of what a “key” is. DO NOT have the signed (document, signature) tuple specify the signature algorithm or parameters. All of that is part of the public key, which the verifier (obviously) needs to acquire out of band.
[0] Someone may pwn, or at least massively confuse, you if you do this. Imagine what happens if the inner and outer documents have different character encodings.