Biscuit maintainer here o/

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

Im not trying to be annoying but I still don’t get it. It might be easier for me with some examples. I’m sure when folks start using this, it’ll be more clear.

(biscuit author here) you caught me, I can't help getting excited about the project XD

> Given a long-term token, can I create short-term, auto-expiring tokens?

yes, with attenuation: https://doc.biscuitsec.org/recipes/common-patterns#expiratio...

> Is there some revocation mechanism?

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.

I'd say if you can live with JWTs containing a little data (like a sub to look up in DB) and a simple authz system like a RBAC, keep using it, that will work well. But if you can benefit from attenuation (ex: per request attenuation https://doc.biscuitsec.org/recipes/per-request-attenuation and delegation https://www.biscuitsec.org/docs/guides/microservices/ ), then look into Biscuit, it can help

oh and for OAuth, it can integrate well with it: https://www.biscuitsec.org/blog/oauth-oidc/

(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

> specifies an authorization language where checks can be carried by the token

Why? Wouldn't a developer prefer to implement this inside its application logic anyway?

Edit: I think I figured it out myself: you're likely targeting the case where someone with a certain authorization wants to give someone else a weaker form of that authorization (attenuation).

It could also let your clients do proactive validation without rewriting too much code, seems like?

there's a siimilar concept in Biscuit, the 3rd party block: https://www.biscuitsec.org/blog/third-party-blocks-why-how-w... It's not advertised a lot right now because it's not supported by all libraries yet

It is very much intended :D

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

PASETO is great! It's way better than JWT, for the use cases targeted by JWT. Biscuit explores other use cases, like attenuation