# Delegation paths

A key functionality of the iSHARE Trust Framework is delegating rights to another party, authorising them to act on your behalf. A single delegation was described in the [delegation use case](https://framework.ishare.eu/use-cases/use-case-delegation-and-management-of-consent).

In essence, Service Providers need to decide whether a Service Consumer is allowed access to a certain resource. To take the right access decisions, Service Providers need to interpret all relevant evidence to come to a decision: in other words, a 'logical sum' of evidence. This page further elaborates on situations where more than one delegation is issued that has overlapping properties.

### Example 1: Single delegation <a href="#delegationpaths-example1-singledelegation" id="delegationpaths-example1-singledelegation"></a>

In the situation of a single delegation, a Service Provider could encounter the following situation:

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-c5eb4e267f7b5807cd2bfb135501dfd9f725cd6c%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

### Example 2: Simple path of delegation <a href="#delegationpaths-example2-simplepathofdelegation" id="delegationpaths-example2-simplepathofdelegation"></a>

In practice, various organisations can delegate rights to various other organisations. Combining these delegations, a 'path of delegation' can be established, as is illustrated in the following example:

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-f1df252d1e7d37742796230f0ba41d660437772b%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

### Example 3: Complex path of delegation <a href="#delegationpaths-example3-complexpathofdelegation" id="delegationpaths-example3-complexpathofdelegation"></a>

The following example illustrates a more complex delegation situation, where specific rights are delegated in terms of actions, resources and the right to further delegate these rights:

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-572c1f30d13c80a81bb87b86334b8015ed1f6f56%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

Party Q resides over party A's resources. When evaluating the available delegation evidence, organisation Q can conclude that organisation D has 'read' rights to resources X and Y, but is not allowed to delegate these reading rights any further.

What is important to note for this path of delegation is that the delegation rights **do not have to be given in a chronological order**. If party C just now delegated rights to D, while party D would have requested access earlier than party C would have delegated rights, the delegation path would not exist.

Within the data spaces/ iSHARE network, it is possible to define more detailed rights to resources, as described in the [key functionality section in the introduction](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context). For a detailed technical explanation of delegations, please refer to the '[structure of delegation evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence)' chapter.