biscuit-auth/biscuit

Roadmap

Geal opened this issue · 4 comments

Geal commented

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

Support for v3 blocks

Support for v4 blocks

API support for third-party blocks

API support for snapshots

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) #147
  • 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
  • semantics
  • cryptography
    • asymmetric mode
      • propose some usable schemes
      • experimental implementation: #10
      • benchmarks (speed for attenuation and verification, size overhead)
      • choose one of the schemes: #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: #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

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 commented

updated following the 2.0 merge #77

CMCDragonkai commented

Has there been any update since 3.0?

  • 👀1
divarvel commented

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 commented

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