Again, the library can provide that functionality in a better way. In this case, the library could provide a means for the consuming code to be queried about wh

Again, the library can provide that functionality in a better way. In this case, the library could provide a means for the consuming code to be queried about what keys are available. E.g., in JS-like pseudo-code: validator = new JwtValidator(); // By default, the validator should reject everything, until you call… validator.add_signing_key(new RsaSigned((a strongly-typed RSA key)); // I wouldn't even add this to the library, but let's // say you want to comply with the RFC fully: validator.add_signing_key(new CompletelyUnsafeNoneAlgorithm()); // (And I'd name it that explicitly, to let the consumer know that // what they're doing is nuts.) This validator knows exactly which algorithms — and keys — are valid. If the full keyset is somehow not known ahead of time, a callback to enumerate keys of a certain type could be configured. Better API design here prevents this vuln. from ever happening. (Personally, I wish the RFC had never added "alg": "none"; it's a mistake waiting to happen. I wish JWS/JWT could be updated to remove it.)