(author of the paper in your second link, which the Biscuit spec also references)
Macaroons are an abstract thing. They don't define an encoding format, nor any semantics or language for the caveats. So a lot of detail is left up to the implementer, which is why they're fairly hard to use. Their basic form is also built on symemtric keys and hmacs, so only the issuer can verify, which is a significant limitation in the real world.
AFAICT Biscuits define those (protobuf for encoding, a logic language for the caveats) and use public keys instead to allow other parties than the issuer (=holder of the root key) to verify them.
That abstraction is also a strength. I think one of the reasons Macaroons really resonate with security engineers is that the underlying cryptography is simple and user-proof, and the resulting formats and protocols are super flexible†, which is not a combination you typically get with cryptosystems. It's also one of the truly great security papers; having worked with a team for a year scaling them out, I get something new every time I read it. My only quibble is the internal naming ("CID", "VID").
We're doing a big-ass blog post as we speak about how our Macaroon tokens work, and it covers how we worked around the issuer/verifier constraint (spoiler: a litefs-backed replicated isolated internal API) and we did basic stuff like encoding (spoiler: we defined a rigid struct schema, and just MsgPack'd it).
One of the things I think I have to say about Macaroons is that there's a sliding scale of how much you use it; I think there are some simple ideas in them that would be pretty neat in any application's authentication cookie scheme.
† Also one of a couple reasons, I think, that "standard Macaroons" and their associated libraries never went anywhere.
Very much looking forward to the blog post! At G we’ve relied on some existing key replication APIs and the caveats have just been the simplest possible and rigid protobufs for each application.
(And thanks! I’m still citing your Velvet Underground comparison.)
I’m very intrigued and excited about this! I read your earlier post comparing schemes and saying after years beating the drum for macaroons, after trying to implement them, you wouldn’t beat that drum any more. Have you come back around?
Macaroons are an abstract thing. They don't define an encoding format, nor any semantics or language for the caveats. So a lot of detail is left up to the implementer, which is why they're fairly hard to use. Their basic form is also built on symemtric keys and hmacs, so only the issuer can verify, which is a significant limitation in the real world.
AFAICT Biscuits define those (protobuf for encoding, a logic language for the caveats) and use public keys instead to allow other parties than the issuer (=holder of the root key) to verify them.