Introduction

Verifiable Credentials (VCs) are typically issued by legal entities. Verifiers need to know the issuer of the VCs, whether the issuer is recognised as trusted within the domain and who provided this recognition. By default, legal entities have no accreditations, meaning verifiers may not recognise the VCs they issue.

EBSI introduces a Verifiable Trust Model that contains permissions and policies. Permissions allow for governance or issuance within the Trust Model, while policies define who made the accreditation, which trust framework is followed and its legal basis. Trust Model participants make the entire verifiable Trust Model publicly available by registering it in the EBSI Trusted Issuers Registry.

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

Verifiable Authorisations model the Decentralised Access Management (DAM) consumed by the EBSI Platform Identity and Access Management (IAM). DAM can be used to onboard new legal entities or 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

Abbreviation	Term	Description
-	Trust chain	Implementation of a Trust Model
DID	Decentralised Identifier	Legal entity identifier for Trust Model; cannot be natural person in context of Trust Model
Root TAO	Root Trusted Accreditation Organization	Legal entity governing the whole trust chain
TAO	Trusted Accreditation Organization	Legal entity governing a trust chain segment
TI	Trusted Issuer	Legal entity participating in a trust chain as an issuer
TIR	Trusted Issuers Registry	Registry for Issuers to register their accreditations
VC	Verifiable Credential	Base type for Verifiable Attestation, Accreditation and Authorisation
-	Verifiable Trust Model	Permissions with policies to either accredit or attest

Concepts

A trust chain enables a single point of trust within a given trust domain. A verifier can choose to trust the Root TAO and verify the accreditation chain referenced in the issued Verifiable Credential. All Verifiable Accreditations are public information and stored in the Trusted Issuers Registry.

Trust Model Roles and their Permissions

A Root TAO is the owner of the chain, responsible for the governance of the entire trust chain. Root TAOs may accredit TAOs to govern a segment of the chain. Root TAO and TAOs may also accredit TIs to issue specific VCs. 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, with each accreditation belonging to one trust chain that grants issuing or governance capabilities.

A trust chain should contain all three roles, even if a single DID represents all three roles. The roles must be Root TAO, TAO and TI, where only TI may issue domain-specific Verifiable Credentials.

Root Trusted Accreditation Organisation (Root TAO)

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 VCs
• accredit any legal entity to govern or issue domain-specific VCs
• revoke an accreditation from a legal entity 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 VCs
• accredit any legal entity to govern or issue domain-specific VCs
• revoke accreditation from a legal entity that was accredited by the TAO

The TAO permission is defined by VerifiableAccreditationToAccredit.

Trusted Issuer (TI)

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

A VC contains a reference to the issuer's accreditation. VCs can be issued to natural persons or to legal entities.

Accreditations

Accreditations certify that an entity is qualified to accredit or attest. Accreditations are attribute-driven and 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 grant rights to use EBSI services.

The VerifiableAuthorisationToOnboard 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. TAOs can issue VerifiableAuthorisationToOnboard credentials to legal entities. Onboarding alone will not provided 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 attestations (default), while accredited TIs may issue domain-specific VCs with the accreditation by attaching the IssuanceCertificate into termsOfUse.

End Users (legal entities or natural persons) can accumulate multiple VCs 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 cover how to verify signatures or schemas; 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 the use case must 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

Trusted Policies Registry (TPR) validation exceptions

When validating a Verifiable Credential (VC), it is typically unnecessary to check the Trusted Policy Registry (TPR), with one specific exception: Self-Accreditation to Attest.

The conditions that require a TPR check include:

• The VC's type property includes VerifiableAccreditationToAttest.
• The VC subject is also the VC issuer
• The VC subject is authorised to issue VerifiableAuthorisationForTrustChain credentials.

In this case, the TPR must be checked to determine if the VC issuer has one of the following policies:

• TIR:insertIssuer
• TIR:updateIssuer
• TIR:setAttributeMetadata

The extra validation is done on the VerifiableAccreditationToAttest VC containing:

credentialSubject.accreditedFor[x].types = [ ..., "VerifiableAuthorisationForTrustChain" ]

note

This process is automatically handled by our EBSI VC library when the user invokes the verifyCredentialJwt function. However, users not utilising EBSI's VC library will need to implement this check and perform the verification manually.