Retrieving a block index about biscuit HOT 9 OPEN

ok so this is interesting, as the same issue has appeared in another problem, for revocation, where we would want to know from which block a revocation id comes from. There are 2 ways this could be done:

• running the query after loading each block into the verifier
• adding metadata to datalog facts to know their origin

the first way would probably make verification harder to follow. The second requires a bit more work as it would change how facts are stored, but it could open some nice optimizations, like recognizing that if we're evaluating block 3, a rule from block 2 will not produce anything new with facts from block 1, because we already applied that rule when loading block 2.

I see 2 ways to implement it:

• each "generation" has its own array of facts and rules. This might make rule application much more complex
• each fact or rule carries its block number along with the predicate. I think I'd go with this one

Then, when we query a fact, we also get its block number. There might even be a way to make a constraint based on the block number, but I'm not sure yet if that's a good idea.

from biscuit.

I pocked a bit at this 2nd implementation option already, but it wasn't super conclusive yet.
The main issue is that facts are generated from the query rule. From my example above, to_validate are generated facts
from a combination of facts from authority (should_sign and data) and from the Nth block (signature).
So I'm not sure which ID to assign on to_validate facts from here.

Now the verifier.query(rule) is calling internally world.queryRule(rule), but the world also have a world.query(fact) available,
which could be exposed on the verifier as a verifier.queryFact(fact), but again hitting the same issue since embedded rules can have generated some facts when the world ran (from biscuit blocks or provided by the verifier). Those could still be labeled as "generated" fact as their origin, but thinking about it, I've ended with the simple stupid solution to expose a verifier.GetBlockID(fact). It searches for a given fact in the biscuit blocks directly, ignoring the world and any generate facts. But it's not super pretty, maybe I'm also missing something on attributing block IDs to those generated facts ?

from biscuit.

I see your point, it's more annoying to implement that I initially thought. The GetBlockID method is a bit raw, and it will not handle cases where the fact you're looking for might be generated from a rule, but it can work.
Otherwise, could the signature fact include the block id? (That might be abused though but I don't see yet how)

At this point, we might as well expose the World instance in the verifier, so we can go through the list of facts manually if needed? And add the block id as metadata to the facts and rules

from biscuit.

I see you've implemented it in https://github.com/flynn/biscuit-go/pull/23/files
Any feedback on its usage, how it should be implemented, etc?

from biscuit.

We still have it under evaluation, it does the job so far in our signature context.
The main issue with it is, as you mentioned it above, that it does not support generated facts. This is fine right now, we have complete control of each party interacting with the biscuit, so we know which facts can be searched and which cannot, but it's definitively not great for a lot of other use cases, and not the most user friendly feature.

For implementation, my best guess is probably to leave this lookup implementation to the caller, and simply update the lib to allow peeking into a biscuit blocks and facts. This make it more obvious which facts are actually available.

from biscuit.

that would make sense. The limitation on non generated facts is not a great issue, since a lot of biscuit usage will depend on conventions followed by every element of the system but it could live as an external API, yes

from biscuit.

Is there actually use case where we'd have to lookup a block index for a generated fact ? As I currently see it, they are the result of the execution of the datalog program (the biscuit) fed with some user input (ambients provided to verifier), so they really only exists in the world, where order doesn't matter. They don't really get attached to a biscuit or block

from biscuit.

here's another approach I'd like to consider: having a block id authority fact added and removed by the verifier when loading each block.

Here's the process for each block:

• load facts and rules from block N
• add the block_id(#authority, N) fact
• execute all the rules
• remove the block id fact

for your signature case, there could be this authority rule:

blocks_after_signature(#authority, $block_id) <- signature($dataID, $pubkey, $signature, $signerNonce, $signerTimestamp), block_id(#authority, $block_id)

Then, the verifier would have to query the blocks_after_signature facts, take the minimal one, decrement, and we get the block id we want. Then about hashing previous blocks, I'm already considering it for revocation ids ( cf #1).

I'm not sure if there are many other use cases for that block_id fact though

from biscuit.

This sounds neat! I'll give it a try soon

from biscuit.