Geal
commented
2 years ago updated following the 2.0 merge #77
Open Geal opened 5 years ago
Geal
commented
2 years ago updated following the 2.0 merge #77
CMCDragonkai
commented
1 year ago Has there been any update since 3.0?
divarvel
commented
1 year ago I have updated the roadmap. For a tl;dr:
divarvel
commented
1 year ago don't hesitate to reach out if you have ideas / questions
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-wasmandbiscuit-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
Javascript
Haskell
Upcoming features
reject if(v5 blocks)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: - [x] credential language - [x] example queries: #11 - [x] [example implementation of datalog with constraints](https://github.com/Geal/dataexponential) - [x] defining an API over the language, to allow easier, higher level usage: #13 - [x] write a specification for the types and behaviour - [x] text format definition - [x] semantics - [x] define the expected behaviour - [x] define the authority and caveats behaviour in terms of the credential language (see https://github.com/Geal/dataexponential/blob/master/src/biscuit.rs ) - [x] write a specification for the semantics - [ ] cryptography - [ ] asymmetric mode - [x] propose some usable schemes - [x] experimental implementation: #10 - [x] benchmarks (speed for attenuation and verification, size overhead) - [x] choose one of the schemes: #19 - [x] check how easy it is to implement it in various languages (availability of high quality libraries, serialization, etc) - [x] write a specification for the cryptography primitives we will use - [ ] security audit for the chosen scheme and its implementations - [x] replaced with a seal based on signatures ~symmetric mode~ - [x] serialization: #18 - [x] define a format to store the credential language and its basic types - [x] define a binary format for the asymmetric token, with its blocks and signature(s) - [x] define a binary format for the symmetric token - [x] define a way to store the token in text formats (base64 of the binary token, etc) - [ ] tooling - [x] define a common API to create a token, attenuate it and verify it (important point: usable error messages) - [x] pretty printing of the token, and especially its logic language (will be useful for debug, in web inspectors and such) - [ ] Implementation - [x] [Proof of concept implementation in Rust](https://github.com/CleverCloud/biscuit/tree/1fd2cf6546743b547bf9bce9b4bbf6f7f5a73386/code/biscuit-poc) - [x] [Rust](https://github.com/biscuit-auth/biscuit-rust) (v3 support) - [x] [Java](https://github.com/clevercloud/biscuit-java) - [x] v2 support - [ ] v3 support - [x] [Web Assembly + Javascript](https://github.com/biscuit-auth/biscuit-wasm) (based on the Rust version) - [x] make a demo like https://jwt.io/: [biscuitsec.org](https://www.biscuitsec.org) - [x] [Haskell](https://github.com/biscuit-auth/biscuit-haskell) (v3 support) - [x] [Python](https://github.com/biscuit-auth/biscuit-python) (v3 support) - [x] [Go](https://github.com/biscuit-auth/biscuit-go) - [x] v2 support - [ ] v3 support - [ ] usage - [x] [Apache Pulsar](https://pulsar.apache.org/) [authentication and authorization provider](https://github.com/clevercloud/biscuit-pulsar) - [ ] [Warp10](https://www.warp10.io/) - [ ] [KeyCloak](https://www.keycloak.org/) ## 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](https://en.wikipedia.org/wiki/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](https://github.com/CleverCloud/biscuit/issues/11) 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](https://github.com/CleverCloud/biscuit/pull/10): - 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](https://github.com/CleverCloud/biscuit/issues/7), 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).