Use case: portable identity
This use case showcases iSHARE Trust Framework's key functionality, 'facilitate portable identity(s) for parties and humans'.
The example described in the linked chapter is as follows:
Human X, working for Party A, has credentials issued by iSHARE certified Identity Provider Y. The credentials, and thus the identity of Human X, can be used to identify and authenticate Human X at party B.
Human X will now use its Identity Provider Y credentials to request a status update from the ERP system (machine) of Party B.
The following explains this example in detail, utilising the iSHARE Trust Framework.
Roles and Relations
The following roles are fulfilled in this use case:
Party A requests a status update, so it is the legal entity fulfilling the Service Consumer role.
Party B responds with the status update, so it is the legal entity fulfilling the Service Provider role;
No delegation takes place, so Party A also fulfils the Entitled Party role.
Human X is the Human Service Consumer that represents Party A.
Identity Provider Y is one of the Identity Providers to which Party B has outsourced identification, authentication and authorisation of humans, and the party that has given Human X his keycard.
Optionally (and shown in this case), Identity Broker Z is the Identity Broker that provides Party B access to different Identity Providers, and that offers Human X the option to choose with which Identity Provider to identify and authenticate itself.
Legal relations
As always, a mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B) establishes the entitlements of the Entitled Party (Party A);
A mandatory relation between the Service Provider and the Identity Broker covers the use of Identity Broker Z's services, including a connection to several Identity Providers, by the Service Provider (Party B);
A mandatory relation between the Service Consumer (Party A) and Identity Provider Y covers the use of Identity Provider Y's keycards by the Service Consumer's (Party A's) humans, including Human X.
As depicted:
Prerequisites
It is prerequisite of this use case that:
[Classic JWT]
The Service Provider (Party B) has and manages its own entitlement information indicating what Entitled Parties are entitled to what (parts of) services, i.e. Party B has information indicating that Party A is entitled to status updates from its ERP system;
The Service Consumer (Party A) has and manages its own authorization information indicating which Human Service Consumers are authorized to act on its behalf;
The delegation/authorization responsible at the the Service Consumer (Party A) registers the authorization information at the Identity Provider (Y);
The Human Service Consumer (Human X) is able to authenticate the Service Provider (Party B);
The Service Provider (Party B) is able to authenticate the Human Service Consumer (Human X);
The Identity Provider (Y) is able to authenticate the Service Provider (Party B);
The Service Provider (Party B) is able to authenticate the Identity Provider (Y);
The Identity Broker (Z) is able to authenticate the Service Provider (Party B);
The Service Provider (Party B) is able to authenticate the Identity Broker (Z);
The Human Service Consumer (Human X) has been issued identity credentials by the Identity Provider (Y).
[VC Variant]
Human Service Consumer (X) has been issued an Identity Credential by the Identity Provider (Y)
Service Consumer (Party A) and Service Provider (Party B) have been issued a ParticipantCredential once onboarded into dataspace;
Human Service Consumer (Human X) has been issued a DataRights Credential from the Entitled Party (in this case Party A);
All parties can verify each others Verifiable Credentials upon request.
The prerequisites in bold are depicted as follows:
Use case [Classic JWT]
The use case varies between implementations and consists of the following steps:
The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
The Service Provider (Party B) requests a login from the Identity Broker (Z);
The Identity Broker (Z) asks the Human Service Consumer (Human X) to select his Identity Provider (Y);
The Identity Broker (Z) requests a login from the Identity Provider (Y);
The Identity Provider (Y) authenticates the Human Service Consumer (Human X) (based on Human X's credentials);
The Identity Provider (Y) issues an identity assertion and an authorisation assertion for the Service Provider (Party B) to the Identity Broker (Z);
The Identity Broker (Z) forwards the identity assertion and authorisation assertion to the Service Provider (Party B);
The Service Provider (Party B) validates the identity assertion and authorisation assertion through the following steps:
The Service Provider (Party B) authenticates the Identity Broker (Z) and validates its iSHARE certification;
The Service Provider (Party B) authenticates the Identity Provider (Y) and validates its iSHARE certification.
The Service Provider (Party B) authenticates the Human Service Consumer (Human X) based on the validity of the identity assertion, and validates the iSHARE adherence of the Service Consumer (Party A);
The Service Provider (Party B) authorises the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the authorisation assertion and the entitlement information registered with the Service Provider (Party B);
The Service Provider (Party B) executes the requested service;
The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).
Use Case [VC Variant]
The use case consists of the following steps:
The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
The Service Provider (Party B) requests a verifiable presentation (VP) from Human Service Consumer (HSC) with all the required verifiable credentials (Identity, Participant and DataRights);
Human Service Consumer (Party A) creates the verifiable presentation (VP) and sends it to Service Provider (Party B);
The Service Provider (Party B) verifies the credentials inside the verifiable presentation;
The Service Provider (Party B) verifies the revocation status of the credentials;
The Service Provider (Party B) verifies the issuer of the credentials;
The Service Provider (Party B) executes the requested service;
The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).
As depicted:
Note that this use case is the same as primary use case 3, as found under detailed Functional descriptions. In this section, the same use case is also explained without an Identity Broker.
[Classic JWT]: Sequence diagram
[VC Variant]: Sequence diagram
What needs to be implemented technically for this use case is described generically, and specifically per role in the iSHARE Developer Portal.
Last updated