H2M with Verifiable Credentials

This subsection shows how the classic H2M sequences changes when using Verifiable Credentials (VCs). With VCs, the execution becomes a single, standard flow; the only difference from the classic variants is that identity information is carried in a Verifiable Presentation (VP) from the Human Service Consumer to the Service Provider. This Identity Credential is part of the prerequisites and is thus not included in the execution flow (no runtime Identity Provider or Identity Broker needed).

General prerequisites (VC):

• The Human Service Consumer (HSC) holds an Identity VC in a wallet and can 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 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).

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.

General Execution Flow

1. Human Service Consumer requests service from Service Provider;

2. Service Provider requests Verifiable Presentation from Human Service Consumer;

3. Human Service Consumer sends the Verifiable Presentation with the requested credentials to Service Provider;

4. Service Provider verifies the Verifiable Presentation (iSHARE adherence, signature, keys, issuer trust, schema, revocation status, validity window);

5. SP provides service results to HSC.

Steps 1–3 may be combined if the HSC includes a VP (with all required credentials) in the initial request.

A) Without Identity Broker

1) Authorisation via Identity Provider Checking Authorisation Registry (AR)

• Classic JWT : Service Provider asks Identity Provider; Identity Provider checks Authorisation Registry; Identity Provider issues identity/authorisation token; Service Provider validates multiple tokens.

• VC: All Identity Provider and Authorisation Registry runtime calls disappear. Human Service Consumer presents VP; any credential required is in the VP (Identity and DataRights). Service Provider verifies once, then authorises.

2) Authorisation via Identity Provider Providing an Authorisation Link to the Service Provider

• Classic JWT: Identity Provider returns a link for Service Provider to fetch and verify.

• VC: Link is replaced by the VP from the Human Service Consumer. Service Provider verifies locally; no fetch-from-Identity Provider.

3) Authorisation via Authorisation Registry Verifying Service Consumer using Participant Registry info

• Classic JWT: SP/IdP/AR roundtrips, Authorisation Registry queries Participant Registry, then Service Provider validates.

• VC: Participant Registry checks are implicit via ParticipantCredential and issuer trust. Human Service Consumer’s VP carries the Identity and Participant credential; Service Provider verifies and applies policy, no Authorisation or Participant Registry runtime calls.

Sequence Diagram

B) With Identity Broker

An Identity Broker is not required in the VC runtime. It is OPTIONAL and only relays the Verifiable Presentation request and response.

For scenarios 1–3, the sequence diagram is identical to the broker-less flow; just replace the direct Service Provider ↔ Human Service Consumer exchange with Service Provider ↔ Identity Broker ↔ Human Service Consumer (no extra checks or tokens are added).

Sequence Diagram