Use case: delegation (and management of consent)

This use case showcases iSHARE Trust Framework's key functionality, enabling data exchange based on delegations - even between unknown parties.

The example described in the linked chapter is as follows:

Party A hires Trucking Company B to deliver Container X to Party C. Trucking Company B's ERP system asks Party C's ERP system at what time it should deliver the container. Party C's ERP system does not know Trucking Company B, but can check the delegation to Trucking Company B that Party A has registered at Authorisation Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP.

The following explains this example in detail, utilising the iSHARE Trust Framework.

After the explanation of the delegation use case, a scenario is introduced that showcases key functionality 'enable control over own data through management of consent'. In this Use case: delegation (and management of consent)#Alternative scenario on management of consent, Party C decides to revoke Party A's access to requesting a time slot.

Roles and Relations

The following roles are fulfilled in this use case:

Delegation takes place, with Party A being the party originally entitled to request a time slot. Party A therefore fulfils the Entitled Party role;
Trucking Company B is delegated the right to request a time slot, so it is the legal entity fulfilling the Service Consumer role.
Party C responds with the time slot, so it is the legal entity fulfilling the Service Provider role;
Authorisation Registry D is the Authorisation Registry to which Party A has outsourced the management of delegation information.
As this is an M2M use case, a Machine Service Consumer represents Trucking Company B.

Legal relations

As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party C) establishes the entitlements of the Entitled Party (Party A);
A mandatory relation between the Entitled Party (Party A) and the Service Consumer (Trucking Company B) covers the delegation of the right to request a time slot.
A mandatory relation between the Entitled Party (Party A) and the Authorisation Registry (D) covers the outsourcing of managing delegation information.
No relation between the Service Consumer (Trucking Company B) and the Service Provider (Party C) is mandatory before service consumption, i.e. the Service Consumer and the Service Provider do not need to know each other. This relation only commences through usage.
No relation between the Service Provider (Party C) and the Authorisation Registry (D) is mandatory before communication. This relation also commences through usage.

As depicted:

Prerequisites

The a prerequisites vary depending on the implementation model:

[Classic JWT]
- The Service Provider (Party C) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party C has information indicating that Party A is entitled to request a time slot;
- The Service Consumer (Trucking Company B) is able to authenticate the Service Provider (Party C);
- The Service Provider (Party C) can authenticate the Service Consumer (Trucking Company B);
- The delegation/authorisation responsible at the Entitled Party (Party A) delegates (part of) the Entitled Party's (Party A's) rights (as registered at the Service Provider (Party C)) to the Service Consumer (Trucking Company B). He registers this delegation in an Authorisation Registry (D);
- The Service Provider (Party C) knows which Authorisation Registry (D) to request the delegation evidence from;
- The Service Provider (Party C) can authenticate the Authorisation Registry (D);
- The Authorisation Registry (D) can authenticate the Service Provider (Party C);
- It is clear, through scheme agreements, under what conditions an Authorisation Registry can provide delegation information to a Service Provider.
[VC Variant]
- The Service Provider (Party C) maintains entitlement info stating Party A is entitled to request a time slot;
- ParticipantCredentials have been issued by the Participant Registry to Service Provider (Party C) and Service Consumer (Company B) including iSHARE adherence claim;
- The Entitled Party (Party A) has delegated the right to Service Consumer via Authorisation Registry (Party D), which issued a DataRightsCredential to the Service Consumer (B) upon request;
- The Machine Service Consumer (MSC) has a wallet able to hold and present the DataRights and Participant Credentials;
- All parties can verify each others Verifiable Credentials upon request.

The prerequisites in bold are depicted as follows:

Discovering Authorisation Rules:

The Service Provider discovers the Authorisation Registry for the specific capability in this order; the first condition that applies determines the Authorisation Registry:

Entitled Party has registered an Authorisation Registry for the specific capability in its /capabilities endpoint;
Else the Entitled Party has registered the Authorisation Registry for the specific capability in the Participation Registry;
Else the Entitled Party has registered an Authorisation Registry for a specific data space in the Participant Registry;
Else the Entitled Party's has set a default Authorisation Registry in the Participant Registry.
Else the Entitled Party and Service Provider have shared an Authorisation Registry bilaterally by other means (e.g., Service Provider has a profile/configuration for each Entitled Party to gather such information).

Use case

The use case varies depending on implementation model:

[Classic JWT]

The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);
The Service Provider (Party C) authenticates the Machine Service Consumer (of Trucking Company B) and validates the iSHARE adherence of the Service Consumer (Trucking Company B);
The Service Provider (C) discovers the applicable Authorisation Registry (D) as described in Discovering Authorisation Rules.
The Service Provider (Party C) requests delegation evidence from the Authorisation Registry (D);
The Authorisation Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
The Authorisation Registry (D) authorises the Service Provider (Party C) based on the scheme agreements for providing delegation information;
The Authorisation Registry (D) provides the delegation evidence;
The Service Provider (Party C) validates the received delegation evidence through the following steps:
1. The Service Provider (Party C) authenticates the Authorisation Registry (D) and validates its iSHARE certification;
2. The Service Provider (Party C) authorises the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C), and validates its iSHARE adherence.
The Service Provider (Party C) authorises the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
The Service Provider (Party C) executes the requested service;
The Service Provider (Party C) provides the service result to the Machine Service Consumer (of Trucking Company B).

[VC Variant]:

The Machine Service Consumer (MSC) of Trucking Company B requests a service from the Service Provider (Party C);
The Service Provider (Party C) requests a Verifiable Presentation (VP) describing the required claims (e.g., DataRightsCredential + ParticipantCredentials);
The MSC returns a VP containing the requested credentials;
The Service Provider (Party C) verifies the VP (signatures, keys, issuer trust, schema, credentialStatus);
The Service Provider (Party C) authorises the MSC based on the verified credentials;
The Service Provider (Party C) executes the service;
The Service Provider (Party C) provides the service result to the MSC.

As depicted:

Note that this use case is exactly the same as derived use case 1c, as found under detailed Functional descriptions. This section also includes delegation use cases with delegation information held by other roles than an Authorisation Registry. Note that this use case is exactly the same as derived use case 1c, as found under detailed Functional descriptions. This section also includes delegation use cases with delegation information held by other roles than an Authorisation Registry.

[Classic JWT]: Sequence diagram

[VC Variant]: Sequence Diagram