[dward]

Albeit this was years ago but I was referring to the construction linked from the original paper proposed in:

https://cs.nyu.edu/media/publications/TR2013-962.pdf

It’s pretty unweildy compared to HMAC construction because:

* each caveat addition requires local generation of a new asymmetric key pair

* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.

* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.

It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.