Hacker News Reader

Comment by jmbwell | Hacker News Reader

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

View on HN

OpenID Connect actually has all the machinery needed to support federated login as part of its dynamic discovery and dynamic registration specifications. The issue is that absolutely no one uses them or implements them.

Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.

Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.

OpenID started its life as an attempt at a federated login standard.

From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.

OpenID Connect is OAuth2 extended to cover a similar feature set as OpenID.

Yeah I’m so old, I remember when LiveJournal (probably when bradfitz was still involved) were among the first to support original OpenID.

There is nothing left from the OpenID 1.0 and 2.0 protocol in OpenID Connect, except for the core features (identity federation, identity information encoding and updates).

OpenID Connect is basically OpenID reimagined on top of OAuth 2.0, with using JWT for the identity data.

The core OpenID Connect spec is still purely a federated identity standard. There are many other standards pushed by the OpenID foundation, but OpenID Connect itself was never meant to be anything more. The main feature differentiator from the OG OpenID is that it's built on top of OAuth, so you can add other features supported by OAuth (like authorization) ad-hoc.

Why haven't (we?) these federation features been used?

Federation sounds like decentralization to me. Decentralized is like a dirty word when you’re in the business of either selling SaaS or pushing private citizens to go all in on the GOOG/AAPL/MSFT ecosystems. And everyone with any influence over what gets adopted and used, is in those categories.

They are being used. Workload Identity Federation is often used to assign oidc identities to workloads and the Client ID Metadata Document (basically dynamic client registration) is used in protocols such as MCP and atproto

As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?

Who do you think would host the "federated login" system that would replace the major authentication companies?

You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.

GP was probably thinking of Azure AD / Entra as the "SSO tax".

https://sso.tax/

Thanks!

With dynamic client registration, I could host my own IdP server at home, or with a provider of my choice, and it would just work everywhere without any coordination work for anyone, manual signups to be assigned a client id/secret, etc. The entire point is that you won't let me do that because you want to charge extra for better, simpler, cheaper security for everyone. That is the SSO tax.

I should be able to just give my email or domain name, and it kicks off an oauth flow to that domain no matter who I use for my email/identity. In the same way that I can give you my email address and you'll just email me without me having to pay extra for enterprise email.

As the article points out, it's not really fair to criticize SAML for not using JSON, given that JSON barely existed at the time.

If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.

(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)

I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.

I don't understand this definition of "fair". Things are either good or they're not. Signed XML is not good. That's a fair claim, even if the designers of XMLDSIG didn't know as much as we do.

The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.

My comment was aimed at the particular critique I was replying to, namely, that using XML for ordinary structured data is bad because XML is a markup language. I am not defending SAML more broadly or claiming that none of its mistakes were foreseeable, and particularly am not defending the idea of signing a DOM tree instead of a sequence of bytes. (Though the latter mistake is in principle orthogonal to XML vs. JSON; I confess to not really understanding why they're so correlated.)

OK, totally fair: I'm hair-trigger about attempts to rehabilitate DSIG and SAML, but I have basically no opinions about XML itself. Sorry!

I’d point out that it’s possible for SAML to be acknowledged as okay or “good for its time,” even, and also be acknowledged as today amounting to a steaming pile of crap that ought to be avoided and phased out wherever possible. Even if all its flaws were just the bad luck of existing before other things were invented.

We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.

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.

XML did not become more complex following 2002. DTD, Namespaces, Comments, processing instructions, CData, attribute vs. child dichotomy - all of these things exited from day 0.

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/

1. Disagree. I think ASN.1 is not horribly complex, but I think BER/DER (which, yes, are in the ASN.1 family) and XML are.

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.

I think ASN.1, specifically DER, actually would have been better because it avoids the canonicalization problems saml has, as well as the general XML problems like XXE.

Saml serializing to XML is not a problem at all, the problem is then including the signature within the XML, which Saml idiotically does. They could just as well have appended it to the xml with a separator. There's nothing about that that couldn't have been understood in 1995 or so.

> 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

IndieAuth exists, it's just not widely supported.

IndieAuth is the way. Unfortunately, I don't think there's a lot of incentive for a site to implement it as a login option unless the site already has some reason to cater to IndieWeb lovers (including me). :^(

You can do that in principle. Most non enterprise tools don't support it because they don't merely want an IdP, they want an IdP doing anti-spam and reputation and outsourcing of account recovery and throttling of bulk user creation.

If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.

The real problem is that they used eXtensible Markup Language but invented their own inner extensibility syntax on top of a language where this was already a core feature! It’s the first word in the name!

It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.

That's what the original OpenID (from back in the LiveJournal days) was supposed to be right?

"Host your own identity"

Yeah, it never really got off the ground though because incentives weren’t aligned. Everyone wants you to sign up on their site for data hoarding reasons, not to use an identity from elsewhere.

When I first learned about OIDC, I thought.. I can log in to Google and Apple using MY identity? Sweet.

Turns out, you can support Google and Apple accounts in your app, not the other way around. Well..

(Still a win though, especially if you need to gate your app with a login.)

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

> What we are missing is a provider-independent way to do this.

A new IndieAuth-like pattern is emerging for how to do this, based on the combination of OAuth, FedCM and DIDs.

https://notes.erlend.sh/3mpodece2qk2g

Reply on news.ycombinator.com