Use case: delegation (and management of consent)

Owned by Gerard van der Hoeven
Last updated: Nov 02, 2023 by Vinith Bhandari
6 min read

This use case showcases iSHARE Trust Framework's key functionality 'enable 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 Authorization 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 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 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;
  • Authorization Registry D is the Authorization Registry to which Party A has outsourced managing delegation information.

  • As this is a 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 Authorization 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 Authorization Registry (D) is mandatory before communication. This relation also commences through usage.


As depicted:

 

Prerequisites 

It is prerequisite of this use case that:

  • 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) is able to authenticate the Service Consumer (Trucking Company B);
  • The delegation/authorization 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 Authorization Registry (D);
  • The Service Provider (Party C) knows which Authorization Registry (D) to request the delegation evidence from;
  • The Service Provider (Party C) is able to authenticate the Authorization Registry (D);
  • The Authorization Registry (D) is able to authenticate the Service Provider (Party C);
  • It is clear, through scheme agreements, under what conditions an Authorization Registry can provide delegation information to a Service Provider.

The prerequisites in bold are depicted as follows:

 

Use case

The use case consists of the following steps:

  1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);

  2. 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);

  3. The Service Provider (Party C) requests delegation evidence from the Authorization Registry (D);
  4. The Authorization Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
  5. The Authorization Registry (D) authorizes the Service Provider (Party C) based on the scheme agreements for providing delegation information;
  6. The Authorization Registry (D) provides the delegation evidence;
  7. The Service Provider (Party C) validates the received delegation evidence through the following steps:
    1. The Service Provider (Party C) authenticates the Authorization Registry (D) and validates its iSHARE certification;
    2. The Service Provider (Party C) authorizes the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C), and validates its iSHARE adherence.
  8. The Service Provider (Party C) authorizes the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
  9. The Service Provider (Party C) executes the requested service;
  10. The Service Provider (Party C) provides the service result to the Machine Service Consumer (of Trucking Company B).


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 Authorization Registry.

Sequence diagram

Alternative scenario on management of consent

This alternative scenario showcases key functionality 'enable control over own data through management of consent'.

The example detailed in the above 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 Authorization Registry D. Because this delegation is in order, Party C's ERP system shares a time slot with Trucking Company B's ERP. 

Now imagine:

  • Moments before Trucking Company B's ERP system asks Party C's ERP system for a time slot, Party C decides to revoke Party A's access to requesting a time slot. Consequently, Trucking Company B's request for a time slot gets an access forbidden message; Trucking Company B's request is NOT accepted because Party A, and therewith delegated Trucking Company B, is no longer authorised to ask for a time slot.

Prerequisites 

To the prerequisites, ONLY the following changes:

  • The Service Provider (Party C) changes its entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party C deletes the information indicating that Party A is entitled to request a time slot.

Use case

The alternative use case consists of the following steps, with changes to the above use case in bold:

  1. The Machine Service Consumer (of Trucking Company B) requests a service from the Service Provider (Party C);

  2. 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);

  3. The Service Provider (Party C) requests delegation evidence from the Authorization Registry (D);
  4. The Authorization Registry (D) authenticates the Service Provider (Party C) and validates its iSHARE adherence;
  5. The Authorization Registry (D) authorizes the Service Provider (Party C) based on the scheme agreements for providing delegation information;
  6. The Authorization Registry (D) provides the delegation evidence;
  7. The Service Provider (Party C) validates the received delegation evidence through the following steps:
    1. The Service Provider (Party C) authenticates the Authorization Registry (D) and validates its iSHARE certification;
    2. The Service Provider (Party C) CANNOT authorize the Entitled Party (Party A) based on the entitlement information registered with the Service Provider (Party C)
  8. The Service Provider (Party C) CANNOT authorize the Machine Service Consumer of the Service Consumer (Trucking Company B) based on the validity of the delegation evidence;
  9. The Service Provider (Party C) communicates an access forbidden message to the Machine Service Consumer (of Trucking Company B).

Sequence diagram


What needs to be implemented technically for this use case (and the alternative scenario) is described generically, and specifically per role in the iSHARE Developer Portal.