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.

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.

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.

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.