Isolated block execution about biscuit

[zarutian]

Hmm... perhaps a way to explictly refer to facts defined/derived in previous blocks in combination with solution 2 could be the third solution?

[clementd-fretlink]

so if i understand correctly, the default would be "only see facts produced by the authority, verifier and current block", and a special keyword (for instance), would make a check operate on those facts + the facts of the previous block?

[zarutian]

I was thinking more of an spefic fact import mechanism.
Like 'import Foo facts from just the second block' kind of thing.
That way one could compose a new block that checks for the facts produced by authority, verifier, the current block, and spefic facts from other prior blocks. This allows for blocks with 'nonsense facts' (alt-facts?) to be ignored while using other facts from that same blocks.

[divarvel]

Oh, that could play well with an idea I have for mimicking 3rd party caveats: allowing blocks to be signed with an extra secret key. In datalog we could add: trust blocks from hex:<public_key> to add facts and blocks from the relevant pks.

[Geal]

IIRC one of the use cases was in making a token that would not be valid until specific data appear. Ex: the first or second block has a check requiring the presence of a block signed by a revocation oracle. Until the token is attenuated with data from such an oracle, it will not be usable. That was one of the motivations behind the "check after" idea

[divarvel]

• Having a per-block marker is interesting because it would apply to rules and checks (but makes granular checks more cumbersome)
• Having a scope descriptor authority | previous (current behaviour) | blocks signed with <private key set> handles both this use case and 3rd party caveats

[divarvel]

The last biscuit v2 update changed the default to trusting only current + authority block.

3rd party blocks will supersede scope descriptors (see #88 )