# 1d. M2M service provision with Verifiable Credentials

This subsection shows how [**1a**](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision), [**1b**](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision/1b.-m2m-service-provision-with-the-ep-as-the-delegation-info-pip), and [**1c**](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision/1c.-m2m-service-provision-with-the-ar-as-the-delegation-info-pip) change when using **Verifiable Credentials (VCs)**. With VCs, the execution becomes a single, standard flow; the only difference across variants is who issues the DataRights Credential and how the Machine Service Consumer (MSC) obtains it before calling the Service Provider (SP).

### General prerequisites (VC):

* The Machine Service Consumer (MSC) can hold credentials and create a Verifiable Presentation (VP) upon request;
* The Service Provider (SP) can request and verify VPs (signatures, keys, issuer trust, credential schema, credential status/revocation, and validity window);
* Parties have been issued ParticipantCredentials issued by the Participant Registry during onboarding (evidence of iSHARE adherence);
* Parties can verify each other's credentials upon request (to verify iSHARE adherence, revocation status, and trusted issuer lists when applicable).

{% hint style="info" %}
These credential verification checks (revocation status and whether the credential was issued by a trusted credential issuer) are assumed in every step, even if not explicitly described in the diagrams.
{% endhint %}

### General Execution Flow

1. Service Consumer requests service from Service Provider;
2. Service Provider requests Verifiable Presentation (VP) from Service Consumer;
3. Service Consumer sends the VP with all requested credentials to the Service Provider;
4. Service Provider Verifies VP (iSHARE adherence, signature, keys, issuer trust, schema, revocation status, validation window);
5. Service Provider provides service results to Service Consumer.

{% hint style="info" %}
Steps **1-3** may be combined if the SC includes a VP (with all the required credentials) in the initial request.
{% endhint %}

### 1a. M2M service provision (SC = EP)

No third-party delegation is needed. The Service Consumer (SC) is also the Entitled Party (EP) and already has the right.

#### **Sequence Diagram**

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-414480314dd676701a0a7a953422ca382997d550%2Fbasic-execution-flow-VC.png?alt=media" alt=""><figcaption></figcaption></figure>

***

### 1b. M2M service provision with the **EP** as the delegation info PIP

The Entitled Party expresses delegation by issuing a DataRights Credential (VC) to the SC/MSC as a prerequisite.

#### **Sequence Diagram**

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-ee3d5e7eb37e7fa7e22906a13975cb4bd00f7e65%2F1b-VC.png?alt=media" alt=""><figcaption></figcaption></figure>

***

### 1c. M2M service provision with the **AR** as the delegation info PIP

The Authorisation Registry stores the delegation information of the Entitled Party. The Service Consumer first discovers the Authorisation Registry (following Authorisation Registry discovery logic) & requests a DataRights Credential.

#### **Sequence Diagram**

<figure><img src="https://399850463-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVbeX1IpIWRqMpyA3SdQH%2Fuploads%2Fgit-blob-48bbd7367dfa64ac8349ffe3b0e22d0d08db59df%2F1c-VC.png?alt=media" alt=""><figcaption></figcaption></figure>