anchor.diff:  it has less overhead. But if you are storing in the token claims that require
   privacy, JWE is the solution that should be used.
   
  +=== ECDSA vs EdDSA ?
  +
  +ECDSA algorithm has one very weak point - it requires cryptographically secure
  +random numbers not  for key generation but also for EVERY signature creation.
  +
  +If attacker has two signatures for same data and can guess random number used
  +for their creation, then she can calculate private key (see PS3 ECDSA exploit
  +for example).
  +
  +Ed25519 on the other hand is specifically designed to avoid this kind of errors,
  +it also has very good performance characteristics both for signing and verification,
  +it's recently been standardized
   
   [[generate-keypairs]]
   === How I can generate keypairs?
  
positive.code: |====================================================================================
  |Algorithm name     | Hash algorithms   | Keywords           | Priv/Pub Key?
  |Elliptic Curve DSA | sha256, sha512    | `:es256`, `:es512` | Yes
  |RSASSA PSS         | sha256, sha512    | `:ps256`, `:ps512` | Yes
  |RSASSA PKCS1 v1_5  | sha256, sha512    | `:rs256`, `:rs512` | Yes
  |HMAC               | sha256*, sha512   | `:hs256`, `:hs512` | No
  
negative.code: openssl rsa -pubout -in privkey.pem -out pubkey.pem
  ----
  
  OpenSSL's command line utilities do not support Ed25519 keys yet.
  See <<ed25519-generation,this section>> for Ed25519 key pair generation
  example
  
  === Involved RFC's?
  
  * https://tools.ietf.org/html/rfc7519
  * https://tools.ietf.org/html/rfc7518
  * https://tools.ietf.org/html/rfc7516
  * https://tools.ietf.org/html/rfc7515
  * http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05
  * https://tools.ietf.org/html/rfc3394
  * https://tools.ietf.org/html/rfc7517
  * https://tools.ietf.org/html/rfc7638
  * https://tools.ietf.org/html/rfc8037
  
  == Developers Guide
  
  