Maybe if the changes you're doing are small and cheap, sure. But if they are invasive and costly...

So you can elide some details when you talk to leadership, investors, and regulators, but you can't elide everything.

  - what happened
  - impact
  - root causes
  - what will be changed (commitments)

It's fine for executives to get only a summary of impact + commitments. But the whole post-mortem process has to be followed, and some people have to be aware of all the details.

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

XML Schema (just like JSON schema) did not. When we're talking about a "simple format" in terms of security we are talking about parsing footguns like these features, not about complexities that may exist with any wire format such as schema and data validation.

Were there any better formats for simple messages back in 2002?

I would argue that yes.

1. ASN.1 is horribly complex, but PKCS #7 (Cryptographic Message Syntax, a.k.a. CMS) was already established, and it was better than XML Signatures in one regard: it did not try to fuse the signed content with its envelope. But this probably wasn't he best choice.

2. If all you needed is a bag of keys and values, you could easily go with an RFC 822 style header + values format (which worked well for both email protocols and HTML). As a bonus S/MIME was already well established at this point, so you had an obvious way to sign this data.

3. Simple binary formats like XDR (used by NFS) or simple textual formats like LDIF or the RFC 822 header format mentioned above could be freely combined with any existing signature protocol that did not mandate structured data (i.e. every signature protocol in existence before XML Signature came in).

4. An even better approach of course, would have been to say no to fine-grained cryptographic agility[1]. That was a terrible mistake, but it was the default design choice back in 2002, and it's hard to single out OASIS. The JOSE/JWT authors should have known better though. You could have define a couple of ciphersuites/version, and a simple, fixed signature protocol for each version.

5. The best approach would have been to just avoid signatures completely and require TLS, but this wasn't viable back in 2002. Even OAuth 1.0 and OpenID 1.0, which came out several years later, included their own cryptographic signatures, but their schemes were still far simpler than SAML.

I think the key takeaway today is that SAML is no longer necessary today. TLS is not an option for secure web resources. There are no features of SAML that cannot be supported by OAuth or OIDC (only security misfeatures). All IdPs and most products support OIDC. In fact, OIDC is probably more well-supported than SAML.

SAML is only used because of enterprise inertia and self-inflicted FUD. As a professional, we should treat SAML with the the same disdain we've directed we've directed towards Internet Explorer 6. This is an insecure legacy technology that presents a drag on the entire industry.

---

[1] https://www.blockchaincommons.com/musings/musings-agility/

2. Yes, unless you need much more structure, then you have to think about ASN.1, XDR, PB, JSON, etc.

3. XDR is a perfectly reasonable basis for an ASN.1 encoding rules family. In fact, PER/OER resemble XDR in many ways. XDR is only simple because a) it's way simpler than the supposedly-simple tag-length-value encodings that ASN.1 came with originally, and b) Sun actually built a solid codegen tool (rpcgen(1)) for it. Never underestimate the value of having excellent tooling as a way of simplifying things :)

4. Alg. agility needs to be tied to the signing keys, not allowed to vary in the headers. Apart from that, you do need alg. agility, so its complexity can be minimized, but not made to disappear.

5. No, because TLS only establishes a channel between two entities, but here we have three or more entities: the two end-points of a TLS connection + all the trusted third parties. The trusted third parties need to communicate to entities they have no direct connection/channel to, and having those pairs of peers initiate connections to get those items is actually quite complex for reasons.

5. It really is the case that signed tokens are extremely handy and simpler than not having them -- it's just that getting signed tokens right has proved tricky in part due to advances in cryptanalysis exposing design mistakes no one knew they were making decades ago.

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

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.

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.

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.

C. A. R. Hoare

I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.

I think that hints at the problem space being... large and complex and requiring large and complex solutions.

What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.

Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...

What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.

Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?