Skip to main content
European CommissionEBSI European Blockchain

Issuer Trust model

Last updated on

Introduction

Verifiable Credentials (VCs) are, in most cases, issued by legal entities. Verifiers need to know who issued the VCs, whether the issuer is recognised as trusted within the domain, and who made the recognition. By default, legal entities have no accreditations; thus, verifiers may not recognise the Verifiable Credentials they issued.

EBSI introduces a Verifiable Trust Model that contains permissions and policies. Permissions allow governance or issuance in the Trust Model, while policies are used to define who made the accreditation, which Trust Framework is followed, and the legal basis of it. Trust Model participants make the whole Verifiable Trust Model publicly available by registering it in the EBSI Trusted Issuers Registry.

The Trust Model enables verifiers to trust roots of hierarchies without needing to know each issuer directly. All permissions and policies are verifiable by verifiers, which allows building greater trust towards issuers.

Verifiable Authorisations model the Decentralised Access Management (DAM) that is consumed by the EBSI Platform Identity and Access Management (IAM). DAM can be used, for example, to onboard new legal entities or to create new Trust Chains.

Depending on their accreditations and authorisations, legal entities can play the following roles:

  • Root Trusted Accreditation Organisation (Root TAO)
  • Trusted Accreditation Organisation (TAO)
  • Trusted Issuer (TI)

Glossary

AbbreviationTermDescription
-Trust ChainImplementation of a Trust Model
DIDDecentralised IdentifierLegal entity identifier for Trust Model, cannot be natural person in context of Trust Model
RTAORoot Trusted Accreditation OrganizationLegal entity governing the whole trust chain
TAOTrusted Accreditation OrganizationLegal entity governing a trust chain segment
TITrusted IssuerLegal entity participating in a trust chain as an issuer
TIRTrusted Issuers RegistryRegistry for Issuers to register their accreditations
VCVerifiable CredentialBase type for Verifiable Attestation, Accreditation and Authorisation
-Verifiable Trust ModelPermissions with policies to either accredit, or to attest

Concepts

Trust chain enables single point of trust for the given trust domain. Verifier can choose to trust the Root TAO and verify the accreditation chain that is referenced from the issued Verifiable Credential. All Verifiable Accreditations are public information and stored in Trusted Issuers Registry.

Trust Model Roles and their Permissions

Root TAO is the owner of the chain, responsible for the governance of the whole trust chain. Root TAOs may accredit TAOs to govern a segment of the chain. Root TAO and TAOs may also accredit Trusted Issuers to issue specific Verifiable Credentials. The Verifiable Accreditation defines permissions with policies that the accreditation holder must follow. Accreditation holders (legal entities) can have multiple accreditations from single or numerous trust chains, where each accreditation belongs to a one trust chain that gives them issuing or governance capabilities.

A Trust Chain should contain all three roles, even if a single DID would represent all three roles. The roles must be RTAO, TAO, and TI, where only TI may issue domain-specific Verifiable Credentials.

Root Trusted Accreditation Organisation (RTAO)

A Root TAO represents a Trust Model and has full control of the Trust Chain. It may:

  • accredit itself to govern or issue domain-specific Verifiable Credentials
  • accredit any legal entity to govern or issue domain-specific Verifiable Credentials
  • revoke an accreditation from a legal entity that is participating in the trust chain

The RTAO permission is defined by VerifiableAuthorisationForTrustChain. The VerifiableAuthorisationForTrustChain is always issued by the EBSI Support Office.

Trusted Accreditation Organisation (TAO)

A TAO governs an accredited segment on behalf of the RTAO. It may:

  • accredit itself to issue domain-specific Verifiable Credentials
  • accredit any legal entity to govern or issue domain-specific Verifiable Credentials
  • revoke accreditation from a legal entity that was accredited by the TAO

The TAO permission is defined by VerifiableAccreditationToAccredit.

Trusted Issuer (TI)

A Trusted Issuer represents the Issuer in a trust chain. It may issue domain-specific Verifiable Credential types defined by the received accreditation. Issuers may issue Verifiable Credentials outside the trust chain, but these are not associated with a Root TAO and contain no reference to an accreditation.

A Verifiable Credential contains a reference to the Issuer's accreditation. VCs can be issued to natural persons or to legal entities.

Accreditations

Accreditations are certifications of being qualified to accredit or attest. Accreditations are attribute-driven and are always restricted to domain-specific credential types. These restrictions cannot be extended. For example, if a legal entity is accredited to accredit Issuers of diploma VCs, they may only pass this or a subset downstream of the hierarchy. Depending on the accreditation, the accredited legal entity may govern (accredit) or issue (attest), but always within the Trust Model and the accredited boundaries.

Authorisations

Authorisations are rights to use EBSI services.

The Authorisation to onboard is used to anchor the DID Document into the DID Registry. This is a mandatory step for all legal entities and is required before any accreditations can be done, as the subject must be able to prove the ownership of the DID. Onboarding guarantees safe entry for the DID and DID Document. Trusted Accreditation Organisations can issue Verifiable Authorisation to onboard for a legal entity. Onboarding alone won't give any access rights or onboarding capabilities, as it is just a means to anchor the DID Document.

Attestations

All Verifiable Credentials are attestations of something. Any issuer may issue non-accredited attestation (default), while accredited Trusted Issuers may issue domain-specific VCs with the accreditation, by attaching the IssuanceCertificate into termsOfUse.

End Users (legal entities or natural persons) can accumulate multiple Verifiable Credentials from one or many Trust Models.

Hierarchy examples

The following diagram shows multiple top-level Root TAOs, where a single legal entity is accredited by two individual trust chains. One of the Root TAOs is stand-alone and has no hierarchy.

Validating the Trust Model's data model

Here is one process to validate the Trust Chain. The process below does not indicate how to verify signatures or schemas, and it only describes data model validation. The credential schema identifier may be hex or base58btc encoded, and the equality check must be encoding agnostic. It is advisable to cache the results and have evictions based on the TIRData /attribute/hash (updates) and TIRData /attribute/issuerType (revocations). Caches come with data staleness, which is up to the use case to define. It is also possible to listen for TIR events to manage the caches.

EBSI Support Office

  • DID did:ebsi:zZeKyEJfUTGwajhNyNX928z

Process: TIR dereference

  • Dereference the TIR link and let it be TIRData
  • Let TIRData's value /attribute/body be a subtype of VerifiableAttestation
    • VerifiableAttestation's value /credentialSubject/id must equal with TIRData's /did
    • If TIRData's value /attribute/body is of type VerifiableAuthorisationForTrustChain
      • Then the LE is an RTAO
      • Then VerifiableAuthorisationForTrustChain's value /credentialSubject/issuer must be EBSI Support Office
    • If TIRData's value /attribute/body is of type VerifiableAccreditationToAttest
      • Then the LE is a TI, who can issue Domain VCs
    • If TIRData's value /attribute/body is of type VerifiableAccreditationToAccredit
      • Then the LE is a TAO, who can issue VerifiableAccreditationToAttest or VerifiableAccreditationToAccredit

Validate Domain VC's IssuanceCertificate

Apply Process: TIR dereference for /termsOfUse/id

  • Resulting VerifiableAttestation
    • /type must be VerifiableAccreditationToAttest
    • /credentialSubject/accreditedFor[x]/types must equal with Domain VC /type
    • /credentialSubject/accreditedFor[x]/schemaId must equal with Domain VC /credentialSchema
    • /credentialSubject/accreditedFor[x]/limitJurisdiction must be acceptable for the use case
    • Recursively apply Process: TIR dereference for /termsOfUse/id and perform the following steps until a VerifiableAuthorisationForTrustChain has been found.
      • /type must be VerifiableAccreditationToAccredit
      • /credentialSubject/accreditedFor[x]/types must equal with Domain VC /type
      • /credentialSubject/accreditedFor[x]/schemaId must equal with Domain VC /credentialSchema
      • /credentialSubject/accreditedFor[x]/limitJurisdiction must be equal or greater than last VerifiableAccreditationToAccredit
    • Lastly for 'VerifiableAuthorisationForTrustChain'
      • /credentialSubject/id must be a trusted DID for the entire trust chain to be trusted