[tptacek]

It's a little-loved library in the standard library that wasn't designed to support cryptographic security, but was by many projects repurposed as such to support SAML. It was a mistake for any SAML project to depend on encoding/xml.

[ivanbakel]

> that wasn't designed to support cryptographic security

An XML library doesn't have to support cryptographic security - it just has to perform XML en/decoding effectively. How can it be a mistake for a project to rely on part of the standard library?

[tptacek]

You write this as if XMLDSIG was straightforward, but people who have worked with XMLDSIG before know that it is not, and people who haven't worked with XMLDSIG should know that they need to research new cryptosystems before slapping them together out of spare parts.

Just to clear it up and state it plainly: it is never reasonable to assume that a given XML library is suitable for building XMLDSIG on top of or alongside.

[eznzt]

I don't know what I'm talking about, but if the XMLDSIG support of encoding/xml does not work properly and no one can fix it, can't they just drop it?

[tptacek]

Drop what? encoding/xml was never a reasonable building block for SAML and XMLDSIG, that was pretty immediately apparent from the library itself, and the Go project never told people they should using encoding/xml this way. They never picked it up in the first place, is what I'm saying.

[xyzzy_plugh]

I don't doubt it was a mistake, but I'm curious what the alternative is here? I'm looking to add SAML to my to project in the medium-term.

[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).

[KajMagnus]

> I'm looking to add SAML to my to project in the medium-term

Did you hear about SCIM, "System for Cross-domain Identity Management"? If combining with OIDC, then, seems to me one gets a more modern alternative to SAML. I've read just a bit about SCIM though.

SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

I wrote more in this comment: https://news.ycombinator.com/item?id=25425665

(What's your project about?)

[tatersolid]

If you want enterprise customers, you still need to support SAML in 2020.