Thanks for the pointers - I'd looked at that, I think, but missed the add-rule bit.
But to be clear, it's easy to set up the validating service so that it accepts a token with expired timestamp as valid - it's the default to not check the timestamp if present?
A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
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?
But to be clear, it's easy to set up the validating service so that it accepts a token with expired timestamp as valid - it's the default to not check the timestamp if present?
A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?