If, like me, you had no idea what this was from reading the release announcement:
Biscuit is an authorization token with decentralized verification, offline attenuation and strong security policy enforcement based on a logic language.
Thank you, and I'd also like to point out that adding a little description to the title would not hurt. Otherwise I look at the title and feel compelled to joke "well, I mean, it's biscuit. It's in the name, it's biscuit." (Do you want to Accept Cookies? - Julie Nolke).
Is it another one of those "cool new technologies" which exist only to push ETH? Or is it from the "hey we might have learned something from blockchain so we will apply some of the techniques but leave out the grift" side of the spectrum (so like KERI)?
When I first heard of biscuits it was in the context of addressing the issues of macaroons. Macaroons have nothing to do with ETH. I don't care if biscuits can also be used in the context of ETH. I love macaroons and I wish they could be used in practice. Perhaps biscuits can be a good replacement for macaroons
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
They are auth tokens, like JWTs or macaroons. And there is an associated policy language.
> That was one of the motivating goals for Biscuit: what if we could attenuate the token, but still be able to verify it with public key cryptography?
Avoid having to share a critical secret across many services.
> With Biscuit, there's another way. Authorization policies can be provided by the verification service, but they can also be carried by the token. The service can specify its policies, and the user can attenuate tokens with their own policies. And they will all be evaluated in the same way, while guaranteeing that the token cannot get more rights with user policies. So from an initial token, an entire parallel authorization design can be developed that will still be compatible with the original one.
Proudly supported by [anonymous]. Well, there's the contributors to the repo, but is there the intent to standardize this? Support for the long haul? Biscuit looks quite interesting, but not knowing about any commitment, future plans (roadmap isn't updated) aren't pros for adoption.
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)
In English-English, "biscuit" is the same thing as "cookie" in American-English.
French Macaroons.... they're on another level compared to what the English and Americans do (fresh, in France - in the UK and NL they've been disappointing).
I think the lack of real-life examples Biscuit's power and usefulness is the missing piece in the docs.
Because they are a building block often used in proprietary systems, people can't even imagine what they could be used for.
What does attenuation refer to in an authentication context? From the word I would guess it would be something like being able to make another token with fewer rights/less access from a more powerful token without involving the issuer.
Edit: Seems my guess was right:
> But it does a lot more! It supports offline attenuation (like Macaroons): from a Biscuit token, you can create a new one with more restrictions, without communicating with the service that created the token.
Biscuit is an authorization token with decentralized verification, offline attenuation and strong security policy enforcement based on a logic language.
- https://www.biscuitsec.org/
Seems like an elegant replacement for use cases where people commonly reach for JWTs.