[http-api] request tokens should be JWTs

[mistermoe]

currently, the request token used to authenticate requests like GET /exchanges is a JWS that include:

Header:

• alg
• kid

Payload:

• timestamp

I'm proposing that we shift to using JWTs instead.

the JWT should contain the following:

Header:

• typ: JWT.
  • we have all sorts of signatures and tokens flying around. setting typ to JWT as recommended by the JWT spec to provide a means to disambiguate
• kid: fully qualified verificationMethod ID. used to locate the verification method in a DID Document that should be used to verify the JWT signature
• alg: cryptographic algorithm used to compute the JWT signature

Payload:

• aud: the intended PFI's DID
  • In our existing setup, if a request token is compromised, it could potentially be misused with any PFI. By incorporating the aud claim, we can limit the risk to just one PFI, thereby reducing the surface area for misuse.
• iss: the requester's DID
  • including to be informative. this is technically duplicative as the kid also includes the requester's DID
• exp: expiration timestamp
  • limits the amount of time a compromised request token can be used. our current request tokens have no expiration. if one were compromised they could be used indefinitely. including exp limits the duration of the attack vector
• iat: when the JWT was created
  • including to be informative
• jti: used as a nonce to prevent replay attacks.
  • spec text should include more detail around exactly how to prevent replay attacks

TODOs:
PR to address this issue should:

• update relevant spec text
• re-generate test vectors.
• publish draft PR and await PRs for JS and KT

[mistermoe]

cc: @jiyoontbd

[jiyoonie9]

the todos here also mention adding nbf which is another timestamp. do we need this field in addition to jti (since that's essentially a timestamp as well)?

[mistermoe]

Good question @jiyoontbd! Can't think of a reason to include nbf. Down to leave it out if you are. Can't really see scenarios where people are generating and storing request tokens ahead of time that shouldn't be used until a specified time