It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up.
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
> 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.
AIUI a “markup” language is for applying structured enhancement to a document containing effectively arbitrary contents. An unstructured source, but we need to add some structured components. Obviously today it has all reverted to a structured document object model, but one of the insights of HTML was, at least in the era of gopher and ftp, the system shouldn’t interfere with the data more than it needs to. If I write up a nicely formatted RFC text file, and I want to put it on the World Wide Web, I shouldn’t have to translate the whole thing to some other language. With HTML, I could, in a structured way that remains independent of the structure of my document, add enough bits to make it work with the World Wide Web. I could, in other words, take my already formatted and structured document, and mark it up with metadata.
At the time this “markup” concept got everyone all excited. But it ended up not being the way to solve problems like what you seem to describe, which don’t have the arbitrary document aspect at all.
Which is exactly my point. Markup and structured data are different. Even at the time of XML’s reign, there were plenty of established ways to serialize and exchange structured data.
Trying to solve a structured data problem with a markup language is how the markup language as a concept got contorted into a data structure system that was simultaneously both too flexible and arbitrary and too maddeningly rigid.
JSON solves it by being a data structure first and last.
> At the time this “markup” concept got everyone all excited. But it ended up not being the way to solve problems like what you seem to describe, which don’t have the arbitrary document aspect at all.
But it does have the "arbitrary document aspect" when you add the desire for site-local claims.
> JSON solves it by being a data structure first and last.
I'd say that JSON solves it by being remarkably simpler than XML and by having become ubiquitous.
Your points about HTML... keep in mind that HTML is for humans, but what we're talking about here is for programs.
jmbwell · · focus · HN ↗
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
cryptonector · · focus · HN ↗
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:
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.
jmbwell · · focus · HN ↗
At the time this “markup” concept got everyone all excited. But it ended up not being the way to solve problems like what you seem to describe, which don’t have the arbitrary document aspect at all.
Which is exactly my point. Markup and structured data are different. Even at the time of XML’s reign, there were plenty of established ways to serialize and exchange structured data.
Trying to solve a structured data problem with a markup language is how the markup language as a concept got contorted into a data structure system that was simultaneously both too flexible and arbitrary and too maddeningly rigid.
JSON solves it by being a data structure first and last.
cryptonector · · focus · HN ↗
But it does have the "arbitrary document aspect" when you add the desire for site-local claims.
> JSON solves it by being a data structure first and last.
I'd say that JSON solves it by being remarkably simpler than XML and by having become ubiquitous.
Your points about HTML... keep in mind that HTML is for humans, but what we're talking about here is for programs.