geal

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

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

(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

(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

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

Right, we forgot to add the context on this release, thank you for the feedback!

(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

We in fact tested multiple languages. I can even point you to various works done at the ANSSI like https://github.com/ANSSI-FR/bootcode_parser (python) or https://github.com/ANSSI-FR/caradoc (OCaml). I tried Haskell for VLC and it was not really suited for it (GC pauses in a synchronized media pipepline, and not meant to be called from C). But this was not a paper about comparing parser implementations.

Type-safety and lack of garbage collection are essential properties, could you tell me why you don't think that's the case?

Giving the reason for our language choice felt useful. Otherwise, it would have really looked like Rust developers steamrolling into projects :)

(one of the authors here): parser generators are generally good for one thing: parsing programming languages. For more complex formats, where you have to carry state around, or binary formats, they're extremely cumbersome to use. I often meet people that tell me they want the parser generator to end all parsers. But for most real world formats, you'll have to hack around the generator's limitations. Theoretically, parser combinators are less expressive, but they're just functions: you can write whatever you want inside a subparser, and integrate it with the rest. That approach works well, since we wrote a lot of complex parsers with nom.

thanks!

does it provide ordering and transcript verification, even in case of partition and resume? I know that XMPP is meant to handle that kind of stuff reliably, but a multiparty OTR or Axolotl ratchet should make sure that even if the transport is compromised, you can detect any message drop or tampering.

That new git server is so fast, it finished before you started it!

More seriously, the performance improvement here is really significant