> For the complete documentation index, see [llms.txt](https://framework.ishare.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.ishare.eu/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization.md).

# Use case: H2M interaction (with coarse-grained authorisation)

This use case showcases iSHARE Trust Framework's key functionality, '[support Human to Machine (H2M) interaction](/main-aspects-of-the-ishare-trust-framework/key-functionality/support-human-to-machine-h2m-interaction.md)'.

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 authorisations](/main-aspects-of-the-ishare-trust-framework/key-functionality/facilitate-flexible-authorizations-applicable-in-any-context.md)', 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 authorisation.

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

### Roles and Relations <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations" id="usecase-h2minteraction-withcoarse-grainedauthorization-rolesandrelations"></a>

The following roles are fulfilled in this use case:

* Party A requests a status update, so it is the participant fulfilling the **Service Consumer role**.
* Party B responds with the status update, so it is the participant 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:

<figure><img src="/files/kU9kmxfAMr6inDKHjMoV" alt=""><figcaption></figcaption></figure>

### Prerequisites <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites" id="usecase-h2minteraction-withcoarse-grainedauthorization-prerequisites"></a>

It is a prerequisite of this use case that:

* **\[Classical 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 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 authorisation information indicating which Human Service Consumers are authorised to act on its behalf;
  * **The delegation/authorisation responsible at the the Service Consumer (Party A) registers the authorisation information at the Service Provider (Party B);**
  * The Human Service Consumer (Human X) can authenticate the Service Provider (Party B);
  * The Service Provider (Party B) can authenticate the Human Service Consumer (Human X);
  * **The Human Service Consumer (Human X) has been issued identity credentials by the Service Provider (Party B).**
* **\[VC Variant]**:
  * Human Service Consumer (Human X) has been issued an Identity Credential
  * Service Consumer (Party A) and Service Provider (Party B) have been issued a ParticipantCredential once onboarded into data space;
  * Human Service Consumer (Human X) has been issued a DataRights Credential from the Entitled Party (in this case Party A);
  * Service Provider (Party B) can verify Service Consumer's (Party A) Verifiable Credential/Presentation and vice versa.

### Use case <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-usecase" id="usecase-h2minteraction-withcoarse-grainedauthorization-usecase"></a>

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) authorises the Human Service Consumer (Human X) of the Service Consumer (Party A) based on the entitlement- and authorisation 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

<figure><img src="/files/KrYvy4rjT6UNwvhq2K55" alt=""><figcaption></figcaption></figure>

Note that this use case is the same as primary use case 2, as found under [detailed Functional descriptions](/detailed-descriptions/functional.md).

### Sequence diagram <a href="#usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram" id="usecase-h2minteraction-withcoarse-grainedauthorization-sequencediagram"></a>

<figure><img src="/files/YoBEr9m5QL0xWjPnFDoE" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**\[VC Variant] :** Service Provider checks authentication, delegation, and iSHARE adherence simultaneously by verifying the Service Consumer's Verifiable Presentation (which include Identity and DataRights Credential of the HSC and Participant Credential of the SC).
{% endhint %}

What needs to be implemented technically for this use case is described [generically](/detailed-descriptions/technical/technical-standards.md), and specifically per role in the [iSHARE Developer Portal](https://dev.ishare.eu/).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://framework.ishare.eu/use-cases/use-case-h2m-interaction-with-coarse-grained-authorization.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.