Clément Delafargue

Adding support for `.any()` / `.all()` on sets (and the upcoming list and map types) would require higher order functions, to pass arbitrary predicates. Making `&&` and `||` lazy in...

Lazy operators

1

Following #129 and the poc in biscuit-auth/biscuit-rust#188, here is a tentative specification of non-strict boolean operators. The existing spec is a bit light wrt operations, so additional changes bringing more...

Now that biscuit has been deployed more widely, we have a clearer vision of future needs and missing features. In particular, the datalog expressions have a few limitations that we...

Right now the spec provides (rather) precise definitions for the token format, the evaluation model and datalog parsing. What is not specified however is the general API of libraries. Most...

We could introduce parsing operations, allowing to try converting strings into numbers, or JSON strings / bytearrays into map / arrays. This would require `null` (#148) for parsing failures, but...

`reject if`

4

Currently, authorization logic can be described with two mechanisms: - `check`s (and `check all`): when present, a check must be satisfied for the authorization to go through. `check` mandates that...

Laziness of boolean operators

3

Evaluating some expressions trigger an evaluation failure (for instance ill-typed expressions, or arithmetic operations that trigger over/underflows). The specification does not explicitly say what is the expected behaviour: - strict...

Nullability

1

Support for array and map types #135 implies the ability to query them. Since querying an array or a map is a partial operation, we need a way to handle...

The spec mentions in a single place that sets should only contain elements of the same type, but nothing else in the spec mentions it or even relies on this...

Ill-typed operations currently make evaluation fail. This makes it easy to have datalog evaluation errors, since introducing a new fact with terms of an unexpected types can make a rule...