This is much simpler than JWT; you'd have a hard time to implement this incorrectly as opposed to JWT. I'm not in the loop, but JWT also used to specify an entire tirefire for crypto algorithms. Probably still does.
The big problem was that JWTs specifies the signature algorithm alongside the signature. Some naive implementations allowed all supported algorithms by default... one of which is "none". So an attacker was able to create a key with no signature and the application would accept it. I think nowadays all implementations require you to specifically whitelist the allowed algorithms.
But yeah, JWTs (technically JWS) overlaps with ItsDangerous, but ItsDangerous is much simpler and has fewer footguns.
JWT specified all the crypto algorithms; even future ones. They did not intend people to accept more then a very small subset. This was insufficiently well communicated.
I don't think it means what you're suggesting, but maybe I'm misunderstanding you. The previous paragraph in the RFC says:
> Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").
In the next paragraph it says:
> Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations.
They're making the distinction here between JWT implementations (i.e. libraries) and applications that use JWT. Nothing mandates that applications must accept the "none" method. The earlier paragraph gives specific usage examples in which a small subset of options are allowed by the application. That is the intended use.
In this later paragraph they're just establishing a baseline of encryption support in libraries; i.e., what is the minimal set of choices that a library can offer to an application. Applications are still expected to actually choose.
It still does. In practice one of the first things you do is to only accept the specific crypto algorithms you actually need to use. Libraries don't get that luxury because they need to be generic, but at least you as the web service implementer can do it.
