> For the complete documentation index, see [llms.txt](https://trustbok.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://trustbok.ishare.eu/apply-ishare/authorisation/delegation-chains/macaroon-model.md). # Macaroon Model Macaroons are a cryptographic, token-based delegation mechanism that encode authorisations together with constraints, called *caveats*. Unlike structural models that explicitly trace delegation paths, macaroons provide a way to embed rules directly in the token. Each new party can append additional caveats when delegating rights further, creating a compact but flexible chain of constraints. For example, the data owner issues a macaroon authorising access to a dataset. When Party A delegates to Party B, it adds caveats such as *“only valid until tomorrow”* or *“only for transport documents”*. Party B can then further delegate to Party C, adding new caveats on top of the existing ones. Validation means checking that all caveats are satisfied: if any fail, the macaroon is invalid. This design offers strong privacy benefits. Since macaroons only contain embedded caveats, downstream parties do not see the full delegation path or identities of all intermediaries. Furthermore, validation is fast: it requires only cryptographic checks on the token itself, without registry lookups. However, macaroons have significant limitations in flexibility. Once caveats are embedded, they cannot be modified, and revocation is difficult because there is no central registry to consult. Revoking one macaroon typically requires reissuing all tokens. This makes macaroons less suited for ecosystems where revocation propagation is critical. Additionally, while caveats allow for constraints like expiration dates or access scopes, they cannot easily represent complex policies or alternative delegation paths. The macaroon model is therefore best suited for privacy-sensitive contexts where delegation chains are relatively short-lived, efficiency is critical, and fine-grained constraints are more important than revocation flexibility.

Figure 12: A delegation model where the data owner creates a macaroon using a trusted
party, which is then passed along the delegation chain.

Table 4: The key strengths and weaknesses for the macaroon-based delegation model.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://trustbok.ishare.eu/apply-ishare/authorisation/delegation-chains/macaroon-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.