Watch the talk at the bottom of the page. JWT/JOSE are chock full of dangerous footguns that aren't just theoretical, they have repeatedly been shown to be poorly designed and too risky to implement correctly as written. Using fewer, known secure cryptographic primitives as part of the spec ensures it's impossible to get the security wrong, can't be misused.

The point is that the JWT spec leaves it open to the implementer which primitives to use, which invites bad implementations to be insecure. PASETO requires a small subset of known secure primitives, preventing that problem altogether. It's not "just nonsense".

Here's a list of "alg: none" JWT vulns. Every one of these would've been avoided had the standard been something like PASETO which didn't allow that. https://github.com/zofrex/howmanydayssinceajwtalgnonevuln/bl...

You say "I am not going to watch the talk" and then you continue to argue in bad faith. Please walk away if you're not going to engage honestly.

The JWT spec can thus be fixed by changing the recommended set of primitives. No need to reinvent the wheel with custom serialization (that probably also has vulnerabilities when implemented by clueless people).

You parade the alg=none vulnerability that has been fixed long ago as the reason to reinvent the world. It's simply not.

The spec is fundamentally flawed. The fixed spec would be a different spec, i.e. something like PASETO.

You keep repeating that. What is "fundamentally flawed"?

PASETO has exactly the same vulnerabilities. You can specify a different version, and a buggy implementation can misinterpret it. With PASETO, the algorithm selection is fully under the control of the attacker.

these "potential crypto attacks" resulted in multiple CVEs and several real life attacks. I think even the Storm-0558[1] could be traced to how hard it is verify a valid JWT, due to some of the over-engineering mistakes that have been involved in the standard's design. I don't know if PASETO would have solved that particular attacks, but the PASETO standard solves some of the most common CVEs we see with JWT libraries: alg=none, Algorithm Confusion attacks and invalid curves.

[1] https://www.microsoft.com/en-us/security/blog/2023/07/14/ana...

Yes it allows Ed25519, but it doesn't disallow other curves. That's the whole point. If you allow primitives that have potential issues, it's risky to use.

There is no standard saying that implementations MUST support P-256. So you're free to just turn on Ed25519.

And so far, I don't think NIST curves have been cracked? iOS secure enclave only supports them, for example.

It's not about the curves being cracked. https://auth0.com/blog/critical-vulnerability-in-json-web-en...