Concatenation Models
Concatenation models aim to reduce validation overhead by embedding the entire delegation chain (or a compressed version of it) directly into each new piece of evidence. Instead of requiring recursive lookups across multiple registries, the authorisation path is self-contained and can be validated in a single step. This makes the model appealing for efficiency, though it comes with trade-offs in flexibility and privacy. Two variants exist: a full concatenation model and an ID-only concatenation model.
Full Concatenation
In this variant, every new delegation includes the full chain of delegations that preceded it. For example, if Party D is authorised via A → B → C → D, then the evidence held by D contains all the steps A→B, B→C, and C→D. Validation is straightforward: the chain can be checked locally without contacting external registries.
This approach maximises efficiency. Since all information is bundled in the evidence, validation requires no additional network calls. However, the cost of this simplicity is privacy and evidence size. Each delegate receives visibility into the full chain, including parties upstream that they might not need to know. As chains grow longer, the evidence becomes larger, raising concerns about performance, scalability, and metadata leakage.
ID-only Concatenation
To address the privacy and scalability issues of the full model, the ID-only variant stores only delegation identifiers, not the full evidence contents. Each new delegation includes a concatenated list of the IDs of all upstream delegations.
This provides a middle ground. The validation process still requires looking up the referenced IDs in the relevant registries, but since the list is provided up front, traversal can be more efficient than recursive linked-list models. Privacy is better preserved than in the full model, since delegatees see only opaque identifiers rather than identities or detailed delegation data.
However, revocation handling becomes trickier. If an upstream ID is revoked, the entire concatenated list may need to be revalidated, and the chain can break unless alternative paths exist. Additionally, while smaller than full concatenation, the ID list still grows linearly with chain length.
Both the full and ID-only approaches illustrate the trade-off between efficiency, privacy, and scalability. The core idea remains the same: by concatenating the delegation path into each new evidence object, validation can be streamlined. The difference lies in how much information is carried along — either full delegation details or just opaque identifiers. Figure 3.1 below presents the generic concatenation model, and the accompanying Table 3.1 summarises the main strengths and weaknesses of both variants.
Last updated