PASETO is a marked improvement and doesn't have the specific problem mentioned here, by using versions instead of an attacker-controlled alg field.

One of the things that makes "The JWT Problem" such a hard post to write (and not one we've already just written) is that the cryptographic flaws are but one problem; architecture implications are another. So, to say "yes go use PASETO" instead implies that something "like" PASETO or JWT is even the right answer, and in the vast majority of cases where we've seen JWTs applied at Latacora that has not been the case.

How is the (attacker-controlled, no?) version & purpose field in PASETO not subject to the same issues as the JWT header? (Are we just lucky that none of the currently existing version/purposes can conflict?)

The issues folks have around JWT's header field always seem to be interface issues: libraries need to understand what keys they can use to validate, and what types those keys are, and validate them against the header.

(Though, I do not know why there is a "none" algo. That does seem like a folly. Could we recon that in the RFC?)

I believe the distinction is that with PASETO, the versions are by specification not backwards compatible.

So, if my application supports v2 and you "forge" a v1 token, my application will not validate it.