What are the main differences between Branca and PASETO?

Based on my brief reading of both, it seems like the main differences are:

* Branca has no signing mode, just authenticated encryption (eg. only "local" mode)

* Branca's payload is just arbitrary bytes, whereas PASETO has a defined payload format

* Seems like the same ciphers are used for Branca and PASETO v2/local.

Is that a fair assessment?

Yep, that's a fair assessment.

If you want ultra-simplicity and don't need clearsigned tokens (i.e. signed by a third party), you can get away with just using Branca. PASETO covers both use cases.

Hm, I think I prefer branca from a quick look (simpler is better). I'm a little worried that both seem to hide away datestamp/validity though.

Branca notes checking the timestamp as optional - I couldn't tell what paseto does by default - other than a reference to a timestamp in the implentor's readme (and then only as an example parameter to the php code).

Paseto does helpfully state that there's no replay protection - so don't use it for stateless (serveless) session tokens.

But to both/either default to some kind of timeout?

I don't really see any use cases where I'd want infinite validity - so in addition to sane algorithms, sane/required exipery seems like it should be part of such things?

I think I might want a serial and a black-list too.. But maybe there are cases where invalidation aren't ever needed? I can't think of one right now.

PASETO has the same "claims" as JWT, except they're ISO 8601 timestamps rather than integers (UNIX timestamps).

They're not required (as they weren't in JWT). If you want to use them, use them. The parser will validate them if you want it to.

https://github.com/paragonie/paseto/blob/master/src/Rules/No...

https://github.com/paragonie/paseto/tree/master/docs/02-PHP-...

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?

The default is to not enforce any rules beyond the cryptographic signatures.

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.

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?

PGP definitely has it's issues. It is a good tool for dealing with files, but yeah, it has it's problems.

It looks like Google's security team prefers the use of Tink[0] when having to encrypt things.

[0] https://github.com/google/tink

Tink is great! I wish there were more supported languages. AEAD and AWS KMS to decrypt the key set is perfect for our needs.

Yes, Tink is acceptable too. :)

Tink is fantastic.

To come back to one other point. Why Google payments uses PGP: because all other payment companies in the world do too. We work with many different companies, and when dealing with files, they all figured out how to use PGP 20+ years ago and probably won't change unless they are forced to. :)

(googler opinions are my own)