Thanks for your response. > 2. it doesn't, internal session class does and IMO most apps do not need expire claim. If you're generating a token to send to an

Thanks for your response. > 2. it doesn't, internal session class does and IMO most apps do not need expire claim. If you're generating a token to send to an SPA or native app, you can't rely on any other expiration mechanism. It needs to be embedded in the token or stored server-side in a database-backed session or what have you. > 3. Just put issuer/issued_at/whatever in your object You're missing the point that these features would require additional SLOC to verify the "claims." > 4. I suggest to look at messageverifier and do your own (and use sha256 hmac). Why? Lets consider 50 lines of code not "maintaining your crypto fork" but merely helpers. By this logic, ruby-jwt isn't crypto, just helpers. It seems to be frowned upon simply because it includes additional features some people may not need, and those features and alternative signing methods require more SLOC than your presumed "optimal" implementation. Do you see no value in a flexible, reusable library? > 5. JWT has more LOC inside, say header payload is just useless. I believe having OpenSSL::HMAC helpers is better and simple enough to not do it wrong How can critics justify the position that people should write their own OpenSSL::HMAC helpers because they can't correctly call the JWT helpers?