[tptacek]

SAML is the only mainstream user of XMLDSIG and 99%+ of the installed base of XMLDSIG. SAML libraries should include purpose-built, locked-down, SAML-only XMLDSIGs, and those XMLDSIGs should include purpose-built, stripped-down XMLs.

The XML isn't even the hard problem here! XMLDSIG and XML Canonicalization are much more complicated than the baseline XML parser.

[layer8]

> SAML is the only mainstream user of XMLDSIG

That’s not quite accurate. XMLDSIG is widely used in SOAP, and also in the European XAdES signature standard (which is an extension of XMLDSIG).

[vbezhenar]

Yep, in Kazakhstan almost every government web service uses XML signatures for interoperating. Of course nobody sees it outside of those systems, but it's everywhere inside. I have no idea about other countries, but I would not be surprised to find out that there are many other similar countries or organizations where that stuff works inside. You won't know about it until you touch it.

[cesarb]

Here in Brazil too, for instance the NF-e (electronic "nota fiscal", the English term seems to be "receipt", the documentation is at http://www.nfe.fazenda.gov.br) and the recently released digital payment network (PIX, see https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn... for the current release of the relevant manual) both use XMLDSig.

[neilv]

Yep, I've implemented SAML multiple times with a purpose-built processing.

And I implemented a non-SAML use of XML-DSIG standards, and discovered, when attempting to interoperate, that a major platform vendor's implementation of wasn't compliant, such that hashes would only be correct using that vendor's implementation (which I initially assumed was a mistake of mine, until an expert confirmed the major vendor was actually wrong).