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