I’m aware of the reputation of XML signatures, but it’s the first time I read about technical details, and they make my head spin.
Q: Is there any non-legacy reason to use SAML instead of libsodium’s public key authenticated encryption (crypto_box)?
Another Q: Is there any non-theoretical risk of parser differential when using libsodium’s cyrpto_box on one end and Golang’s x/crypto/nacl/box on the other end?
Wouldn't using crypto_box mean the developer would have to implement their own custom authorization mechanism from scratch?
i.e. it looks like a reasonably good way of exchanging encrypted messages, but I don't see anything in the docs indicating that it would provide the equivalent of group membership/roles/permissions.
Building something like that as custom code is a huge commitment, and could easily result in severe vulnerabilities specific to that system.
I was thinking you can strip out the retarded signature protocol in SAML (replace that with libsodium) and leave the actual payload intact, or even switch from XML to a simpler wire format like JSON for the payload. But maybe even the payload part of the standard isn't worth saving, I can't tell after reading a single article about it.
Of course, but then you run into the ipv6 problem. How do you upgrade every fucking end-and-middlebox out there? The WAFs the legacy-legacy-sure-we'll-upgrade-this-quarter-oops-next-decade-again boxes that got migrated to the clouuuud (to a private cloud as a Windows Server 2003 VM of course) ...
Q: Is there any non-legacy reason to use SAML instead of libsodium’s public key authenticated encryption (crypto_box)?
Another Q: Is there any non-theoretical risk of parser differential when using libsodium’s cyrpto_box on one end and Golang’s x/crypto/nacl/box on the other end?