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?
If you need any other validations, it's entirely up to you to specify what those are.
You might care about checking `exp`, but I might instead care about `iat` with a hard-coded token lifetime.
PASETO supports whatever zany business logic developers need, but doesn't enforce anything by default.
But once you add a rule to your parser, it will fail-closed on those rules.
> A token without timestamp will never be valid if a rule for checking timestamp is added in the parser?
Correct.
If your parser is set to check timestamps and one is invalid or omitted, it throws an exception.
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?