Delegation Chains

This article explains how delegation chains can be managed in line with the iSHARE Trust Framework. It does not introduce new specifications, but rather explains how the existing delegation specifications can be applied in different ways. The aim is to highlight patterns for managing delegation chains in complex data spaces, drawing on both research and real-world practice. Different models are possible, and the model choice may vary across data spaces or even individual parties. The approaches described here are therefore illustrative and not prescriptive. Altogether, participants are encouraged to evaluate which patterns best fit their requirements, to adapt them as needed, and to share their experiences with the iSHARE Foundation so that the ecosystem can continue to refine and optimise delegation practices.

Delegation in Complex Data Sharing

Data sharing is crucial for enabling third parties (including companies, individuals, and public institutions) to access data sets for the development of new applications and services. The iSHARE Trust Framework was developed to facilitate trusted data exchange between parties, particularly focusing on identification, authentication, and authorisation (IAA). These elements are indispensable for any communication between parties in a data-sharing environment.

In practical implementations, particularly within the larger supply chains, delegation chains are a common occurrence. For example, a shipper authorises Transporter A, who subcontracts to B, who relies on C. When C arrives at the warehouse, it must prove it acts legitimately on the shipper’s behalf, which requires validating the entire delegation path. Similar multi-hop patterns occur in healthcare referrals and other domains. This creates a complex delegation chain that must be managed effectively to ensure security, privacy, and efficiency. A visual example from the healthcare sector is portrayed below:

Figure 1.1: A simplified illustration of a single delegation chain.

Within iSHARE, evidence objects already carry links that help reconstruct paths (e.g., delegation_path, previous_steps) so an Authorisation Registry (AR) can verify that rights have been passed correctly. In practice, however, as paths span more parties and ARs, validation slows down, revocations ripple unpredictably, and privacy leaks if too much chain detail is exposed.

While the iSHARE Trust Framework provides technical specifications and a robust authentication flow for managing delegations, several constraints arise when dealing with extended and complex delegation chains. These include privacy concerns, complexity in managing delegation policies, flexibility to adapt to varying scenarios, risks related to security, and efficiency in processing delegation evidence. Moreover, delegation chains are rarely linear. They can split into multiple parallel paths and later converge, introducing ambiguity and potential policy conflicts, as illustrated in Figure 1.2.

Figure 1.2: An example delegation chain containing a parallel path.

Current solutions have not fully addressed these challenges, particularly when delegation chains become long and involve multiple parties. The need for a systematic approach to improving the delegation model is evident.

The goal of this article is to strengthen iSHARE’s delegation model so that multi-party chains remain verifiable, private, and performant without sacrificing interoperability. We treat ARs as evidence validators that answer valid/invalid while revealing as little path detail as possible, and we evaluate alternative models that change what is recorded per step: previous delegation ID vs. previous party ID, or encapsulate constraints cryptographically (e.g., macaroons).

Principles for Delegation Paths

While iSHARE’s current specification supports delegations, extended and complex chains surface constraints that current solutions do not fully balance theese main principles:

1. Privacy: Ensure confidentiality by implementing zero-knowledge principles, limiting visibility of roles and identities within the delegation chain.

2. Complexity: Manage multiple delegation policies and traceable paths effectively, accommodating intricate delegation chains without excessive complexity.

3. Flexibility: Provide adaptable solutions that support various scenarios, including those with overlapping dates and changing paths.

4. Risks: Mitigate security vulnerabilities and unauthorised access by implementing robust verification processes and tamper-proof evidence management.

5. Efficiency: Optimise processes to minimise overhead and reduce the number of interactions needed to verify delegation evidence.

Importantly, Authorisation Registries cannot hand out delegation evidence to any requester. The requesting party must provide sufficient proof that they are entitled to receive the delegation evidence. For instance, by being explicitly named as the delegated entity (to entity to whom entitlements are delegated) or by demonstrating that they act on behalf of the delegated entity through valid credentials. Only then does the Authorisation Registry issue delegation evidence.

Empirically, long chains and cross-organisation settings amplify these constraints. A hybrid study of literature and real-world data spaces shows privacy is a dominant concern, with a partial mismatch between academic focus (revocation propagation, efficiency) and operational focus (transparency, interoperability). This underscores the need for systematic, model-level improvements rather than ad-hoc fixes.