Roadmap

[Geal]

After a few iterations on both cryptographic primitives and language designs, biscuit is in a phase of iterative improvements.

Biscuit is used in production in several places, the rust implementation now has a stable API and is used as the basis for other implementations (biscuit-wasm and biscuit-python).

Biscuit blocks are versioned and this mechanism has allowed gradual introduction of new features without disrupting existing deployments. Features that are not part of token serialization and authorization are not versioned and remain under the responsibility of each implementation. This includes datalog parsing for instance.

This roadmap starts from biscuit v2, which is the minima version supported by libraries. Due to an issue in the initial release of biscuit v2, a breaking change update had to be released, so biscuit v2 corresponds to version 3 of blocks. In the roadmap, only block versions will be used (v3+).

Roadmap

Documentation

• Getting started
• Third-party blocks
• Usage in various langs
  • Rust
    • NodeJS
    • Python
    • CLI
    • web components
  • Haskell
  • dotnet
  • java
  • go
• Recipes
  • RBAC
  • ABAC

Support for v3 blocks

• biscuit-rust
  • biscuit-wasm
  • biscuit-python
  • CLI
  • web components
• biscuit-haskell
• biscuit-dotnet
• biscuit-java
• biscuit-go

Support for v4 blocks

• biscuit-rust
  • biscuit-wasm
  • biscuit-python
  • CLI
  • web components
• biscuit-haskell
• biscuit-dotnet
• biscuit-java
• biscuit-go

API support for third-party blocks

• biscuit-rust
  • biscuit-wasm
  • biscuit-python
  • CLI
  • web components
• biscuit-haskell
• biscuit-dotnet
• biscuit-java
• biscuit-go

API support for snapshots

• biscuit-rust
  • biscuit-wasm
  • biscuit-python
  • CLI
  • web components
• biscuit-haskell
• biscuit-dotnet
• biscuit-java
• biscuit-go

Integration with web frameworks

Rust

• Actix-web
• Tower.rs

Javascript

• Express

Haskell

• Servant
• WAI
• Twain

Upcoming features

• ECDSA
  • Initial design
  • PoC
  • Specification
• WebAuthn signatures
  • Initial design
  • PoC
  • Specification
• New datalog features (v5 blocks) Datalog breaking changes #147
  • reject if (v5 blocks)
    • Specification
    • Implementation
  • Foreign calls in datalog
  • Non-strict boolean operators (Laziness of boolean operators #129)
    • PoC wip: short-circuiting boolean operators biscuit-rust#188
    • spec Lazy operators #150
    • rust implementation
  • Arrays and maps (Add array and map types #135)
  • New operators (Nullability #148 Type casting / parsing operations #149)
• Resumable execution

Old roadmap

there's already been a lot of discussion around what the biscuit can be and how it could work, so it's probably a good time to sum things up and see what's needed.

Roadmap

To get to a usable token implementation, here's what we would need now:

• credential language
  • example queries: Example logic queries #11
  • example implementation of datalog with constraints
  • defining an API over the language, to allow easier, higher level usage: Example API #13
  • write a specification for the types and behaviour
  • text format definition
• semantics
  • define the expected behaviour
  • define the authority and caveats behaviour in terms of the credential language (see https://github.com/Geal/dataexponential/blob/master/src/biscuit.rs )
  • write a specification for the semantics
• cryptography
  • asymmetric mode
    • propose some usable schemes
    • experimental implementation: add experiment using EC-VRF for aggregation #10
    • benchmarks (speed for attenuation and verification, size overhead)
    • choose one of the schemes: Choose a cryptographic scheme #19
    • check how easy it is to implement it in various languages (availability of high quality libraries, serialization, etc)
    • write a specification for the cryptography primitives we will use
    • security audit for the chosen scheme and its implementations
  • replaced with a seal based on signatures symmetric mode
• serialization: Serialization format #18
  • define a format to store the credential language and its basic types
  • define a binary format for the asymmetric token, with its blocks and signature(s)
  • define a binary format for the symmetric token
  • define a way to store the token in text formats (base64 of the binary token, etc)
• tooling
  • define a common API to create a token, attenuate it and verify it (important point: usable error messages)
  • pretty printing of the token, and especially its logic language (will be useful for debug, in web inspectors and such)
  • Implementation
    • Proof of concept implementation in Rust
    • Rust (v3 support)
    • Java
      • v2 support
      • v3 support
    • Web Assembly + Javascript (based on the Rust version)
      • make a demo like https://jwt.io/: biscuitsec.org
    • Haskell (v3 support)
    • Python (v3 support)
    • Go
      • v2 support
      • v3 support
  • usage
    • Apache Pulsar authentication and authorization provider
    • Warp10
    • KeyCloak

Semantics

With #6 and #8, along with some out of band discussions, we have a better idea of how attenuation should work:

• the first caveat specifies an authority field indicating the basic rights for this token, out of a set of rights the verifier knows about
• some of those rights can be marked as critical, and the verifier should refuse a token that does not put bounds on it (to allow accidental elevation of rights)
• there's an ambient authority with information coming from the context, ie which resource is accessed, current time, source IP address, etc
• the verifier also provides information from its own context (different verifiers might care about different rights or resources, etc)
• each caveat checks that the request is within what it authorizes (resource accessed, kind of operation...)

Caveat language

We're evaluating a datalog like language to express the caveats. It is simple to implement and allows complex queries. It can also be used to generate the authority field in a compact way.

We have been exploring example queries to get a feel for how it could work.

Cryptographic primitives

Asymmetric mode

We need to support our goals of a token that can be attenuated offline and verified in a decentralized way. To that end, we explored a few cryptographic systems:

• first one is an aggregated signature scheme using pairing based cryptography on BLS curves. Easy to follow and very compact, but verification can be quite slow, and very few good libraries are available
• second one is an aggregated zero knowledge discrete log proof using verifiable random functions. Quite fast and there's a version that does not add too much size overhead
• third one uses a PKI like system with a challenge/response to authenticate the last element of the chain (its properties are a little bit different than the others)

All three of them would be usable, but we will need an audit of the schemes before deciding which one to go with.

Symmetric mode

It would be useful to have an alternative mode to transform a biscuit token to a symmetric construction, a bit like macaroons.
That mode is not well defined yet, but the idea would be to send an asymmetric token to the authentication service, which will check the token and its caveats, and create a new token with the same caveats, but using a symmetric mode, possibly with encryption.
At the cost of one RTT, we get a token that is much faster to check and can be fixed for requests to only one service (the one who knows the secret key).

[Geal]

updated following the 2.0 merge #77

[CMCDragonkai]

Has there been any update since 3.0?

[divarvel]

I have updated the roadmap. For a tl;dr:

• for go and java, the current objective is to support v4 blocks (check all, third-party blocks)
• as for the spec itself,
  • there is work on supporting specific EcDSA profiles in addition to ed25519, and integration with webauthn
  • we are starting to think about new datalog features that would warrant a new block version
• there is still work to be done on documentation and use cases / experience reports

[divarvel]

don't hesitate to reach out if you have ideas / questions