There's definitelt some cool use cases we could collaborate on. One thing I'm looking at more deeply right now is tokens carrying the necessary data as they go through the system,to make sure one call does not see some of it rights change dynamically when going from service to service
(biscuit author here) I tried a lot of different formats, especially looking for something that generated small tokens, that could have a canonical form, and that was supported in a lot of languages. The canonical part was a dead end as most formats did not support that well. Protobuf ended up being the one which generated the smallest tokens, and was easily supported in most languages, even if, like you, I don't agree with everything in the way it's serialized.
Self describing formats were a dead end as well because it grows the token size
check if: if any one of those fails, the entire authorization fails
allow if/deny if: they are tried in order, we stop at the first that matches. If an allow if matches and all checks passed, then the request is authorized
In a token, each block has a revocation id, so if you revoke a token, all the tokens derived from that one will be revoked as well. As for how to handle those revocation ids, it's the same strategies as in other systems, reintroducing some state to check revocation lists: https://www.biscuitsec.org/docs/guides/revocation/
> How do these things line up against JWT or OAuth? When should I prefer this, but also when should I NOT prefer this?
JWT has a lot of footguns, especially in the way it handles the list of algorithms, and libraries tend to all go through the same set of mistakes (a lot of them are stable now though). JWT are good to transmit a small amount of data, and are overall well supported. JWTs do not enforce any authorization system, you have to add one yourself.
Biscuit is very strict in how it deserializes and verifies tokens, so it avoids the usual JWT issues (partly by its spec, partly by an extensive test suite). Biscuits can be larger than JWTs, and can take longer to verify (one signature verification per block). Biscuit comes with its own authorization, based on a logic language, that can be both carried by the token and provided by the verifier. It has implementations in a lot of languages but is not as widely supported as JWT yet.
(Biscuit author here) there is some support for revocation with the way revocation ids are implemented: there's one generated for each block of a token, so if you add the token's last block's revocation id to the revocation list, then all tokens derived from that one will be revoked as well.
We outline the strategies to manage revocation in https://www.biscuitsec.org/docs/guides/revocation/ but as you said, there is no magic here, adding revocation reintroduces state in the system.
As for why you would use this over JWTs: Biscuit avoids JWT's usual footguns, specifies an authorization language where checks can be carred by the token, it adds attenuation and third party blocks. You can build a lot more with those tokens
No standardization for now, as we were still exploring the model. The spec is carefully built for evolution though, providing backwards compatibility where possible.
The main developers are Clément Delafargue, maintainer of the Haskell version, now employed full time at Outscale to work on Biscuit, and me, Geoffroy Couprie, original designer of the token and maintainer of the Rust version, working at Apollo GraphQL (unfortunately not on Biscuit yet)
This is not a cryptocurrency technology,it was designed with microservices authorization in mind, inspired from JWT and macaroons.
I have looked at cryptocurrency related tech earlier though (pairing libs from zcash, gamma signatures), because it could be a good basis for attenuation, but moved to simpler solutions lately
(biscuit author here) I like how that post points a crucial issue in authorization systems: how powerful and flexible should we make them?
If you go towards flexibility, you get more complexity and possibly unexpected results. And they become hard to audit and explain.
You can choose simple, single purpose systems, like a RBAC only authz backed by a SQL database. You write tight, easy to understand policies. But systems always grow beyond the bounds of those rules, and you end up with a lot of ad hoc rules, or role explosion.
Datalog was a good tradeoff for Biscuit (https://www.biscuitsec.org): powerful enough to cover a lot of use cases, simple enough to be implemented the same way in multiple languages
There's definitelt some cool use cases we could collaborate on. One thing I'm looking at more deeply right now is tokens carrying the necessary data as they go through the system,to make sure one call does not see some of it rights change dynamically when going from service to service