Verifiable Credential support per role

Specifications and best practice implementations for Verifiable Credentials are currently being developed. This page is expected to be updated, closely following these developments.

Each role defined in the iSHARE Trust Framework has specific responsibilities related to issuing, holding, or verifying Verifiable Credentials (VCs). The terminology on this page references the W3C VC Data Model 2.0.

This page describes which roles are expected to provide, consume, or verify particular credential types. It ensures consistent implementation of verifiable identity and authorisation across all iSHARE participants.

Participant Registry

The Participant Registry is responsible for issuing and maintaining Participant Credentials.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Issuance: Creates Verifiable Credentials confirming about organisations such as that the organisation is an iSHARE-adhering participant, member of a certain dataspace, has signed agreements or is using an X509 certificate.

• Credential Type: Participant Credential and Participant Claim Credentials, Bitstring Status List Credential

• Presentation Use: Other roles (Service Consumers, Service Providers, Authorisation Registries, etc.) must present these credentials when interacting with a participant.

Authorisation Registry

The Authorisation Registry issues Data Rights Credentials on behalf of an Entitled Party, that express delegation or authorisation rights.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Issuance: Issues Verifiable Credentials on behalf of Entitled Parties, allowing Service Consumers to prove their right to access specific services or datasets.

• Credential Type: Data Rights Credential, Bitstring Status List Credential

• Presentation Use: Service Consumers present this credential to Service Providers when requesting access to data. The Authorisation Registry must also verify Participant Credentials during registration or token issuance.

Identity Provider

The Identity Provider issues Identity Credentials to human participants to act on behalf of an organisation.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Issuance: Generates Verifiable Credentials that confirm a natural person can act on behalf of their organisation and may integrate with eIDAS 2.0 or European Digital Identity Wallets.

• Credential Type: Identity Credential, Bitstring Status List Credential

• Presentation Use: Used primarily in Human-to-Machine (H2M) interactions for authenticating users in service portals or operational dashboards.

Entitled Party

The Entitled Party manages delegation and may trigger the issuance of Data Rights Credentials through the Authorisation Registry.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Issuance: Requests or authorises the Authorisation Registry to issue Data Rights Credentials to specific Service Consumers.

• Credential Type: Data Rights Credential (via Authorisation Registry), Bitstring Status List Credential

• Presentation Use: Presents Participant Credentials to other roles during data sharing transaction to authenticate identity.

Service Provider

The Service Provider verifies the credentials presented by others and may present its own credentials for trust establishment.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Verification: Must be able to validate Participant Credentials, Data Rights Credentials, and Identity Credentials presented by human or machine Service Consumers and must be able to validate revocation against the Bitstring Status List.

• Credential Types: Participant Credential, Data Rights Credential, Identity Credential, Bitstring Status List Credential

• Presentation: May present its own Participant Credential when onboarding with registries or providing evidence of adherence.

Service Consumer

The Service Consumer acts as a presenter of credentials when accessing data or services.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Credential Types: Participant Credential, Data Rights Credential, Identity Credential(H2M), Bitstring Status List Credential

• Presentation: Presents its Participant Credential and any relevant Data Rights Credential and Identity Credential(H2M) when interacting with a Service Provider.

• Verification: Must be able to validate Participant Credentials presented by other participants during a data sharing transaction

Identity Broker

The Broker facilitates the interaction between participants and Identity Providers and doesn't directly issue or present any specific credential.

• Holding: Must manage its credentials through a Credential Store (wallet).

• Verification: Must validate Participant Credentials from participants connecting to the Identity Provider through it.

• Credential Types: Participant Credential, Bitstring Status List Credential

Impact Table

Role	Participant Credential	Data Rights Credential	Identity Credential (only H2M)	Bitstring Status List Credential
Participant Registry	Verify/Present/Issue	—	—	Issue/Verify/Present*
Authorisation Registry	Verify/Present	Issue (on behalf of EP)	—	Issue/Verify/Present*
Identity Provider	Verify/Present	—	Issue	Verify/Present*
Entitled Party	Verify/Present	Issue (through AR)	—	Verify/Present*
Service Provider	Verify/Present	Verify	Verify	Verify/Present*
Service Consumer	Verify/Present	Present	Present	Verify/Present*
Identity Broker	Verify/Present	—	—	Issue/Verify/Present*

* Depending on implementation: the Bitstring Status List Credential may be published by the issuer on a public URL, or shared via issue/presentation via a holder.

Implementation Notes

• All issued credentials must conform to schemas published at schemas.ishare.eu.

• Verification processes must confirm credential signature validity, issuer trust status, and expiration timestamps.

• Roles acting as issuers or verifiers must support the DCP, OID4VCI and OID4VP protocols for issuance and presentation.