> IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done.
The difference between IP and the OSI stack is the standards development organizations: IP was specified in a fairly unofficial way (RFCs) by academics via email in what eventually evolved into the IETF, while OSI was specified by ISO. ISO is much more difficult to work in than the IETF. But there are still specifications behind IP. It's not 'just send a packet and see what happens'.
> Protocol complexity is where bugs hide, including vulnerabilities.
You can't make that go away. TCP/IP is not a non-protocol. The best you can do is minimize that complexity.
XML is as complex as DER, and since there is a way to use XML in ASN.1 -called XER, or XML Encoding Rules-, XML is also as complex as ASN.1, and when you add FastInfoSet, even more still.
XML is deceptively simple-seeming, but it's not simple at all. JSON isn't actually trivial, mind you, but by comparison to XML, ASN.1/DER, etc, JSON is trivial.
The only reason to prefer ASN.1/DER here is that the likelihood of very badly broken libraries that fail to validate signatures becomes comparable to the same for x.509/PKIX certificates: fairly low due to the need for a whole ASN.1/DER ecosystem. It's the must-be-this-tall-to-ride effect.
To be fair to OASIS, in 2002 XML was textual and simple-seeming. It was the obvious choice. It must have seemed brilliant. They didn't know it would turn out badly.
Even with JSON you need solid decoders, excellent libraries, and you'll still want a JSON Schema and tooling.
> When authentication is just not a document or data stream that needs marked-up.
You've lost me here due to my experience with Kerberos and OAuth (JWTs specifically), though I mean JSON, not XML, so if by "marked-up" you meant "XML bad", well, that I would agree with.
Kerberos has something of a "markup" in that it has typed holes for carrying all sorts of useful metadata about the subject, especially what it calls 'authorization-data', but a) it's a real pain to get KDCs to include useful site-local things, b) it's remarkably harder to get Kerberized services to be able to get at that authorization data! (b) is surprising. I worked that problem for a bit -- I've done a lot of work on Kerberos, but APIs involve lots of work, not just C but Java, Python, all the things, so the last mile requires a ton of work to bridge, and then you end up with a pile of {some kind of data type ID, data encoded accordingly} that the application has to decode, so you have to:
- specify syntax/encoding for your site-local authz data
- write KDC-side code (preferably just plugins)
- implement RFC 6680
- including language bindings for various langs
- implement authz data decoders to use in apps
- use those decoders in those apps
It's never ending.
Now compare to JSON: when you're done validating the signature or MAC, or decrypting the token, you now have a JSON text for the claims. Injecting site-local claims in your token issuer is trivial now. Using them in your applications is even more trivial (provided you have a JWT validator, otherwise it's too trivial if you forget to validate the signature!).
JWT got this right. Kerberos got it wrong.
In defense of Kerberos, it goes back to the mid to late 80s depending on which version you want to start counting at, and GSS-API goes back to the early- to mid-90s. So we're talking 30+ to 40+ years, all of it predating JSON and XML.
But today, in 2026, Kerberos is indefensible. Kerberos is still necessary, yes, because there are specs for and support in so many useful application protocols and implementations thereof, and because of Active Directory.
The lesson I draw from this is that GSS-API in the mid-00s needed to have grown a version of `gss_accept_sec_context()` that outputs a JSON text. I wish I could go back in time and build that.
So, yes, authentication context metadata, including metadata useful for authorization, can and should be represented in a "markup" language, specifically JSON.
It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).
Re: canonicalization: design things to not need it, so don't bother with it. Relying parties need to received the blob of whatever (XML, JSON, DER, PB -- don't care or decode till the signature is validated), validate the signature over the exact blob you've received, then decode. This means you need the signing key's algorithm to be identifiable from its issuer and key ID metadata / URI. The header you'll need should only have the information you need to find (dereference) the issuer's signing public key. You'll never need to canonicalize anything this way.
Ideally you should use encrypted tokens so you're forced to do authenticated decryption before getting to the claims portion, but no one has bothered to build that in a way that scales. I did build something like this for Kerberos in Heimdal (https://github.com/heimdal/heimdal), but we need it for encrypted JWTs too: derive symmetric encryption keys from {current epoch, base key, audience/relying party name}, and let the relying party download those keys (by authenticating) much the way they do for signed JWTs. But switching from signed JWTs to encrypted ones is a pain as it requires that the issuer know if the relying party can handle it.
Right. Watermarks are the same in every copy -- they mark a copyright or whatever. Whereas these things are personalized, therefore they do track you as a source of sharing.
The difference between IP and the OSI stack is the standards development organizations: IP was specified in a fairly unofficial way (RFCs) by academics via email in what eventually evolved into the IETF, while OSI was specified by ISO. ISO is much more difficult to work in than the IETF. But there are still specifications behind IP. It's not 'just send a packet and see what happens'.
> Protocol complexity is where bugs hide, including vulnerabilities.
You can't make that go away. TCP/IP is not a non-protocol. The best you can do is minimize that complexity.
reply