> 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/recursive-path-models.md). # Recursive Path Models Recursive models extend each delegation with a pointer to its predecessor, allowing the entire chain to be reconstructed step by step. They preserve a natural sense of lineage: validation means “walking backwards” through the authorisation trail until the original data owner is reached. Within this family, two main approaches can be distinguished: storing the identifier of the delegating party or the identifier of the preceding delegation evidence. #### **Previous Party ID** In this approach, each delegation explicitly records the identifier of the party that granted the rights. Validation then becomes a matter of recursively checking: did C receive rights from B, did B from A, and did A from the data owner? This model has an important strength: it allows parallel paths to converge. Imagine Party 2 receiving rights from both the shipper and an intermediary subcontractor. Party 2 can then consolidate these rights into a single delegation to Party 3. This flexibility is especially valuable in dynamic ecosystems like logistics, where subcontracting is fluid and paths can change from one shipment to the next. *Figure 2.1* illustrates this type of scenario, while *Figure 2.2* shows the basic model structure.

Figure 8: The scenario where two paths converge to a single point, and is further delegated.

Figure 9: A delegation model where the delegation evidence contains a reference to the
party before the current party.

Revocation under this model is also more resilient. If one upstream link is revoked but an alternative path remains valid, downstream rights can continue without disruption. This avoids unnecessary breakage of chains, a key advantage when multiple contracts or delegations overlap in time. The trade-off comes with privacy and performance. Each delegation reveals the identity of the delegator, which means parties always see at least their immediate predecessor. In most real-world cases this does not leak new information — a party usually knows who authorised them — but it contrasts with more opaque models. Validation also requires contacting the relevant Authorisation Registries (ARs) for each hop. Without caching or AR identifiers embedded in evidence, this can create latency across large or multi-registry chains. Overall, the Previous Party ID model fits dynamic, flexible environments such as logistics supply chains, where subcontracting and path changes are common, and resilience is valued over strict traceability.

Table 1: The key strengths and weaknesses of the previous party-based delegation model.

#### Previous Delegation ID Instead of recording the delegating party, this model stores a reference to the identifier of the previous delegation evidence itself. Each link therefore points to a specific, immutable piece of evidence. When validating, the chain can be reconstructed exactly, as if following a linked list of evidence objects back to the original data owner. The result is deterministic and offers audit-friendly traceability. Revocation is simple and unambiguous: if one link is revoked, all downstream delegations that depend on it automatically become invalid. This is attractive in regulated environments, where clear lineage and unbroken audit trails are critical. For example, in finance or healthcare, auditors may demand proof of every delegation hop, and regulators may require certainty that no rights persist after revocation. *Figure 2.3* illustrates this model.

Figure 10: A delegation model where a reference is stored to the previous delegation

Nonetheless, this strictness makes the model fragile. Even if a party had rights through another route, those rights are lost if the specific referenced link breaks. The model enforces lineage over flexibility, which can be problematic in real-world scenarios where overlapping delegations exist. Validation also requires multiple recursive lookups across registries, potentially introducing latency unless discovery mechanisms or caching are in place. The Previous Delegation ID model is therefore best suited for audit-heavy domains where lineage is more important than resilience such as finance, healthcare, or government data sharing — even if that means sacrificing some flexibility and robustness.

Table 2: The key strengths and weaknesses of the previous delegation-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/recursive-path-models.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.