Macaroons are a symmetric-key-based token format. It allows an entity with access to the secret key generate a bearer token embedding one more "caveats" (rules for usage, such as restrictions on path, expiration time, or valid operations). The bearer of the token can add additional caveats (reducing permission) but doesn't have the ability to remove them.

Anyone else with the secret key (such as the same host or another host in the cluster) can then verify the token as apply the authorization rules in the caveats.

1. Delegating fine-grained access: Rucio generates a token to access a single file at a site (using its X509 client cert to authenticate), then sends the token to an end-user. Hence, the end-user doesn't need to authenticate with the site (no user X509 necessary) in order to download files. The VO (ATLAS, via Rucio) can manage the fine-grained rights they delegate to the user -- even if the storage is run by the site.

2. Enabling third-party-copy: If client C wants server A to download from server B, the client can contact server B for a fine-grained access token and provide it to server A as part of the HTTP COPY request.

IIUC, Macaroons are implemented by dCache and DPM. I utilized the same caveat formats and API for requesting new tokens, but generally one would not expect tokens to be reusable across different implementations or site installations.

Currently, the token is generated via a XrdHttp plugin but should be usable throughout the authorization framework; however, you need an encrypted channel between client and server to use it safely.

- SciTokens are based on asymmetric (public key) cryptography whereas Macaroons are symmetric key. This means anyone can verify a SciToken but only the issuing entity can verify a Macaroon.

- In the SciTokens model, the VO issues the authorization, which may be valid across many sites. The macaroon is specific to the site and requires an interaction with the site to generate.

- Macaroons can be attenuated (made weaker) by the end-user. I can take a powerful macaroon and add additional limitations without contacting a third-party, then safely give the limited macaroon to another person if I desire. SciTokens can only be attenuated by contacting the VO to exchange the powerful one for a new one (hence, the VO always generates the token).

Just as one uses a mix of asymmetric and symmetric cryptography throughout the course of the day, I see SciTokens and Macaroons as complementary approaches, each enabling some distinct and some common use cases.

So - one natural question for me is whether this better lives inside the xrootd repository or standalone. Unlike SciTokens, the dependency stack for Macaroons is more manageable (a direct dependency on libmacaroons - https://github.com/rescrv/libmacaroons - and an indirect dependency on libbsd). This means upstreaming of the macaroons code is more approachable than the SciTokens code. Additionally, since the code includes both an issuer and a verifier, Macaroons are more immediately usable - no non-Xrootd services setup.