> But there can be no reasonable argument for a standard conceived of in the last 10 years to allow users to deploy something for which the payload chooses the cryptographic interpretation of the payload. No application anyone on HN is deploying needs user-selectable cryptography. This is never a feature; it's only ever an invitation to horrible vulnerabilities.

When I read about JWT's I saw the alg fields to a simple indicator of the algorithm being used on the JWT, not that it is allowing the token to select whatever algorithm it wants for the server to run. Granted, this is a semantic difference, but if you treat the alg field as such it then becomes the servers choice of what algorithms to support. The practical solution is simple: Only support one algorithm, and if the token's alg does not match what the server is expecting, do not authorize. Sure this is a weakness in the JWT spec, but the real underlying issue is dev's not understanding the security mechanisms and libraries they are deploying. That is bad news no matter what tech they are using.