This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to g

This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to give the end-user mix-and-match primitives. But I don't think that JWT really gives you that, at least at the level I think you're discussing. For example, JWT doesn't let you choose an asymmetric cipher and a hash algorithm; you have to choose a precomposed whole, such as "RS256" (RSA w/ SHA-256) or "HS256" (HMAC w/ SHA-256). To me, this seems equivalent to NaCl, in a sense. In JWT, I must choose one of "RS256", "HS256", etc. In NaCl, I must choose one of the crypto_* functions. Are these not both giving the user equivalent choices between equivalently pre-composed functionality? (Are you simply saying that the JWT standards offer too many choices between essentially equivalent cryptographic combinations, such as multiple choices for HMAC or RSA, and/or that you disagree w/ the exact combinations offered?) > I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time Perhaps it's what you're leaving unsaid, but the gist I get from your proposal is that you're discarding the entirety of JWT's claims section, essentially equating a JWT with an authenticated and potentially encrypted message; i.e., the output of the NaCl functions that you present.