[dward]

The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).

[evancordell]

I implemented publicly-verifiable macaroons as a PoC and found them reasonably ergonomic: https://github.com/ecordell/watchstander

(docs are sparse, I wrote an accompanying doc that might help: https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0N...)

The basic idea is what you described: append only asymmetrically verifiable signatures.

As with most things Macaroons, the harder part is developing a caveat language and verifiers that actually meet your needs. And convincing people that they're a good idea.

[lvh]

I think there are a few weird incompatibilities between libraries that are likely to bite you unless you have 1 library you use, but generally speaking: yes, figuring out how to structure your claims is the hard part. Most claims are really quite simple, which is why I’m bullish on most tiny startups just sticking a random token in a database and calling it a day.

[ithkuil]

I found this part to be one of the most common gotchas of macaroons. As often happens when everybody is "holding it wrong", users are not probably the only ones to be blamed.

That said, macaroons (from what I understood) are meant to be a token that is only verifiable by the issuer.

Third party caveats allow more complex scenarios, but they necessarily involve actual s2s communication to set up (as opposed to the "verification at a distance" allowed by pure asymmetrical crypto)

For example: service A issues a macaroon to service B. Now imagine service B needs to talk to service C, which in turns needs to ensure that B can perform some action on service A. If C could verify A's public key signature, we could stop here.

With macaroons, C needs to issue a macaroon to B, with a third party caveats that requires B to obtain a "discharge macaroon" from A. When B later performs the request on C, it brings both macaroons (the one issued by C with the 3rd party caveat, and the one issued by A, that proves that the caveat is discharged).

C can verify such a macaroon. In particular it can cheaply verify that A is the source of the 3rd party verification.

[lvh]

Are you thinking Vanadium or some other spec?

[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.