fn verify_jwt(
    // The input from the network/user; the JWT we will be verifying
    untrusted_jwt: String,
    // *The* way in which we expect JWTs to be issued / we will be verifying against:
    verifier: Verifier,
  ) -> ... {

    // Basic sanity checks & decoding.
    let untrusted_jwt: Jwt = ...;

    if !verifier.acceptable_alg(untrusted_jwt.alg) {
       bail;
    }
    verifier.verify(untrusted_jwt)
  }

Where `verifier` is something like `JwtRsa` or `JwtEd25519`, or `JwtHmac`. The verifier should know what few, limited algorithms to look for, and it should reject anything and everything that's not under its domain area. There's no blacklist, no guesswork. (I don't even think I'd have `acceptable_alg`; just let `verify` do that work; it has to look at that field anyways to set up, e.g., the hasher.)

I'm largely omitting¹ JWE, so perhaps there's some hidden dragon in there, or perhaps we just handle those completely separately. But for JWS, am I missing something? Unless you pass `NoneVerifier`, in which case you're explicitly opting in to alg: none and it's goriness.

Sadly, I don't think any of the top three Rust libraries do this.

¹I'm also omitting that RSA has many attached hash algorithms in JWS; one can imagine that JwtRsa might let you configure what hashers it will/will not use. As it is, some libraries take sort of this form, but split the key material off from the algorithm … letting you pass craziness like an RSA key material and HMAC-SHA256, which makes no sense. That is, what hash algorithms (if any) are possible is a function of the type of key material coming in.

¹I'm also omitting verification of the claims, which I think a library should generally handle.