DISCLAIMER

The information contained in this page will be applicable to future versions. Currently, the implemented Issuer Trust model is defined here.

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

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
RTAO	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 to attest

Concepts

The Trust Chain enables a single point of trust for the given Trust Model. The Verifier can choose to trust the Root TAO and verify the accreditation chain that is referenced from the issued Verifiable Credential. Verifiable Trust Models contain permissions with policies and are public information stored in the Trusted Issuers Registry.

Trust Model Roles and their Permissions

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

A Trust Chain must 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, and the policies are contained in termsOfUse as TrustFrameworkPolicy. 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, and the policies are contained in termsOfUse as AccreditationPolicy.

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.

The TI permission is defined by VerifiableAccreditationToAttest, and the policies are contained in termsOfUse as AccreditationPolicy. When the Trusted Issuer is using their accreditation to issue a domain-specific VC, the issued domain VC must contain a termsOfUse property with AttestationPolicy type, which links to the Trusted Issuer's accreditation and into Root TAO's accreditation, where both are located in TIR.

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 AttestationPolicy 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.

Policies Overview

The Trust Framework Policy is a document that links to a regulation, directive, national policy, or similar document that may define requirements that must be met. These requirements may include security, legal, operational, or functional requirements.

All Trust Model policies are located in the termsOfUse property of the corresponding VerifiableTrustModel credential that contains the permissions related to the policy.

Validating the Trust Model's data model

Every accredited domain-specific Verifiable Credential must include the AttestationPolicy in termsOfUse. The policy refers to a Root TAO's VerifiableAuthorisationForTrustChain and Trusted Issuer's VerifiableAccreditationToAttest. VerifiableAuthorisationForTrustChain contains policies related to the Trust Framework, while VerifiableAccreditationToAttest has policies regarding accreditation. Policies in VerifiableAccreditationToAttest refer to VerifiableAccreditationToAccredit, which also has policies.

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
• TIRData /attribute/issuerType must not be Undefined or Revoked
• Let TIRData /attribute/body be a subtype of VerifiableTrustModel
  • VerifiableTrustModel /credentialSubject/id must equal with TIRData /did
  • If TIRData /attribute/issuerType is RootTAO
    • Then VerifiableTrustModel /type must contain VerifiableAuthorisationForTrustChain
    • Then VerifiableTrustModel /termsOfUse/type must be TrustFrameworkPolicy
    • Then VerifiableTrustModel /credentialSubject/issuer must be EBSI Support Office
  • If TIRData /attribute/issuerType is TAO then VerifiableTrustModel /type must contain VerifiableAccreditationToAccredit
  • If TIRData /attribute/issuerType is TI then VerifiableTrustModel /type must contain VerifiableAccreditationToAttest
  • If TIRData /attribute/issuerType is TAO or TI
    • then VerifiableTrustModel /termsOfUse/type must be AccreditationPolicy
    • then VerifiableTrustModel /credentialSubject/issuer must equal with TIRData /attribute/tao
• return VerifiableTrustModel for use case validation

Validate Domain VC's AttestationPolicy

1. Apply Process: TIR dereference for /termsOfUse/rootAuthorisation

• Resulting VerifiableTrustModel
  • /credentialSubject/permissionFor[x]/types must equal with Domain VC /type
  • /credentialSubject/permissionFor[x]/schemaId must equal with Domain VC /credentialSchema
  • /credentialSubject/permissionFor[x]/jurisdiction must be acceptable for the use case
  • /termsOfUse/trustFramework must be acceptable for the use case
  • /termsOfUse/policyId must be acceptable for the use case
  • /termsOfUse/legalBasis must be acceptable for the use case
  • /credentialSubject/id must be allowed for the use case

2. Apply Process: TIR dereference for /termsOfUse/parentAccreditation

• Resulting VerifiableTrustModel
  • /type must be VerifiableAccreditationToAttest
  • /credentialSubject/permissionFor[x]/types must equal with Domain VC /type
  • /credentialSubject/permissionFor[x]/schemaId must equal with Domain VC /credentialSchema
  • /credentialSubject/permissionFor[x]/jurisdiction must be acceptable for the use case
  • Recursively the step 2. until equivalent link of AttestationPolicy rootAuthorisation has been found.
    • /type must be VerifiableAccreditationToAccredit
    • /credentialSubject/permissionFor[x]/types must equal with Domain VC /type
    • /credentialSubject/permissionFor[x]/schemaId must equal with Domain VC /credentialSchema
    • /credentialSubject/permissionFor[x]/jurisdiction must be equal or greater than last VerifiableTrustModel