Very quick high level review about biscuit HOT 2 OPEN

thank you for taking the time to review biscuit 😄

On the crypto side, I looked into pairings and were indeed too slow. See https://github.com/CleverCloud/biscuit/blob/master/experimentations/README.md for the benchmarks. Aggregated gamma signatures offered a good compromise, and the overhead of keeping all the keys has not yet been a big issue (I should optimize it a bit though).

On clock synchronization, expiration dates are always best effort but still useful, and something that users will expect. The real issue will happen if a token is carried from one microservice to the next in a network.

On revocation, we're planning on building such a pubsub system (having a central system that everyone asks for revocation lists would quickly become a nightmare).

The idea of DFA for caveats is intriguing! That would definitely be useful when there's a large number of rules. Could it express the various queries I showed here? #11
Also, do you see the DFA used to compress the caveats in the token? (which might not be doable, with the signature etc). Or would the DFA be generated on the fly before validation?
Note that the verifier can come with its own rules and caveats: this way I can reduce further the token's size by storing common rules on the verifier's side.
Right now the Datalog implementation is pretty simple (negation is not even implemented) and the number of facts and rules used for verification is limited. The "context" feature we're testing ( #30 ) allows the verifier to provided only the necessary data

from biscuit.

Nothing in the linked thread appears hostile to DFAs. It really is just a matter of encoding and the expressiveness of the DFA language. I.e. It'd be nice to do dynamic membership lookups like Alice \in orgs/CleverCloud, referring to the dynamic set CleverCloud in the dynamic set orgs. Or to reference a channel binding token for the transport session to prevent invoked messages from leaking outside of the TLS et al session they were invoked against. Do note that wouldn't suffice to guarantee an at-most-once delivery as the client might not receive the acknowledgement of delivery and retry in the next session. If at-most-once delivery matters, retries should act for session resumption and not re-apply effects.

I see the DFA reduction as an optional service provided by the mint which only reduces away the redundancies and re-packages it up with a new single signature if it validates correctly; thus it remains semantically equivalent to the redundantly attenuated credential. You'd invoke this service like you would invoke any other message; but like caveats and messages are separated in their domains, this would need at least one bit difference from caveats and messages too.

The validators don't need to do any DFA reduction unless benchmarks demonstrate it cheaper after some threshold. If a client sends the validator a reduced credential, the validator does have less work to do. If a client consistently reuses a common prefix, that could be reduced in a cache.

The client might however benefit from a local DFA reduction for early failures when the caveats can be locally verified without access to the validator state. This reduced DFA only accelerates the validation but cannot be forwarded to the validator because the bearer doesn't have the necessary key, that the mint has, to re-mint the reduced credential.

This context sounds a lot like a 3rd party caveat. Though speaking of negation, we can do inverted DFA queries. I.e. !(write) to blacklist the write operation. But as whitelist-blacklist semantics go, whitelisting caveats are much safer as future features could evade the intention of a blacklist.

from biscuit.