Page Comparison

...

Human X, working for Party A, has a personal keycard issued by iSHARE certified Identity Provider Y. The card, 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 keycard to request a status update from the ERP system (machine) of Party B.

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

...

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 and authentication 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.

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 the Service Consumer's (Party A's) humans, including Human X.

As depicted:

Prerequisites

It is prerequisite of this use case that:

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 Service Provider;
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 (a keycard) by the Identity Provider (Y).

...

What needs to be implemented technically for this use case is described generically, and and specifically per role :

...