PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for e

PASETO is designed to be resilient against insecure implementation, just as its primitives were. You can do things to make stuff like Ed25519 unsafe (see, for example, a myriad of double-spend attacks), but they involve off-label use, which PASETO precludes. By contrast, JWT was clearly not designed to be resilient against insecure implementation. A cryptographic engineer reading the spec would already have snorted milk through their nose at the sight of the "alg" header, the primitives included PKCSv15 RSA as a default _years_ after we knew it was unsafe, et cetera. A strict JOSE might help, but I think it'll be ineffectual. There's little incentive to move ("we already audited this") and there's lots of incentive to stay because compatibility concerns reach further than security ("Cognito does this weird thing with base64 codas that is different from everyone else and we have to support Cognito"). Consider flipping it around as a thought experiment: if you were willing to give up compatibility, and you were going to integrate a new library anyway, why not go whole hog and do a protocol that was always safe?