# Use case: H2M interaction (with coarse-grained authorization)
This use case showcases iSHARE Trust Framework's key functionality '[support Human to Machine (H2M) interaction](https://framework.ishare.eu/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction)'.
The example described in the linked chapter is as follows:
* Human X, working for Party A, requests a status update from the ERP system (machine) of Party B. It does so via a user interface.
To showcase the key functionality '[facilitate flexible authorizations](https://framework.ishare.eu/version-2.2/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context)', Party A's ERP system (machine) is allowed to request ANY information about ANY (part of a) bill of lading. This can be considered a coarse-grained authorization.
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.
The only **legal relation** is the mandatory relation between the Entitled Party (Party A) and the Service Provider (Party B), which establishes the entitlements of the Entitled Party (Party A). 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 allowed to request ANY information about ANY (part of a) bill of lading 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 (Party B);**
* 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 Human Service Consumer (Human X) has been issued identity credentials by the Service Provider (Party B).**
### Use case
The use case consists of the following steps:
1. The Human Service Consumer (Human X) requests a service from the Service Provider (Party B);
2. The Service Provider (Party B) authenticates the Human Service Consumer (Human X), and validates the iSHARE adherence of the Service Consumer (Party A);
3. The Service Provider (Party B) authorizes the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the entitlement- and authorization information registered with the Service Provider (Party B);
4. The Service Provider (Party B) executes the requested service;
5. The Service Provider (Party B) provides the service result to the Human Service Consumer (Human X).
As depicted
Note that this use case is exactly the same as primary use case 2, as found under [detailed Functional descriptions](https://framework.ishare.eu/version-2.2/detailed-descriptions/functional).
### Sequence diagram
What needs to be implemented technically for this use case is described [generically](https://framework.ishare.eu/version-2.2/detailed-descriptions/technical/technical-standards), and specifically per role in the [iSHARE Developer Portal](https://app.gitbook.com/o/Qzg8z1T4h1fZNOPhEzay/s/hIVZwp4ZxhYhb39SlKH3/).
%20(1).png?alt=media)
%20(1).png?alt=media)
%20(1).png?alt=media)