OK. I think a brief paragraph along these lines probably should be in (one of) the readme(s). Personally I think temporal validity really is needed in most cas

OK. I think a brief paragraph along these lines probably should be in (one of) the readme(s). Personally I think temporal validity really is needed in most cases - and probably should be default. I suppose maybe not for use as long lived api-keys. Then again... infinent validity is almost certainly wrong.. From time to time I wonder how I'd implement kerberos for the web today - probably trading shared secrets for public key/anchoring trust in certificates... And I usually end up realizing it likely will end up just as complex as kerberos5, with similar trade-off/weaknesses (eg ticket hijack). Maybe paseto has different goals (which is fine) - and maybe it makes sense as a building block - but I think I'd like to see a simple toke spec that demands: valid keys/certs, blacklist/revocation, temporal validity (the simplest is probably a valid from/to on the token). And no crypto algo agility/negotiation etc. What is the prime motivation behind/use case/goal for paseto?