1. 12
  1.  

  2. 2

    Sounds interesting but light on technical detail. Macaroons which you can verify with just a public key is a pretty nice feature set.

    I’m not certain that the use of HMAC was a big problem for the intended use of macaroons though? The model was always that the initial token is created and consumed by the same service

    I’d be slightly leery of using this scheme until it’s been looked at a bit because it sounds like it does interesting things with PKI. As I understand it, all the asymmetric cryptographic primitives have interesting algebraic pitfalls depending on very precise details of how you use them?

    Presumably since you’re stacking these up you’re going to need to use ED25519 signatures or some other EC thing? RSA sigs are huge and already make jwt unwieldy.

    Being British I am obviously obligated to be fond of the name at least.

    1. 1
      1. 1

        tldr; biscuits take away the HMAC, and add a datalog policy language for the attenuation checks.

        So I came back to this, and Macaroons already let you use PKI to verify per the paper

        The upside of PKI for macaroons(which appear to be the same with biscuits), is anyone can verify the chain at any point in time, but it slows the crypto down, and doing sub ms checks suddenly fly out the window, which is a nice use-case for macaroons if you need to do Presence type caveat checks. Which is the same thing biscuit’s PKI supposedly give you.

        So the only think Biscuit’s seem to really add is a language for defining the caveats in(using macaroon speak) or ‘policy’ in bisquit speak.

        But there is nothing in Macaroons that say you can’t use a datalog like policy language, you could in fact just steal it from biscuit and keep right on using macaroons.

        Note, I haven’t yet checked if the biscuit PKI stuff is the same as the macaroon PKI stuff, or how they differ.