Skip to main content
European CommissionEBSI European Blockchain
Get Help

Issuer Trust model

Last updated on
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 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​

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​

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 VC. Verifiable Trust Models contain permissions with policies and are public information 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 Root TAO 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 Root TAO. 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, and the policies are contained in termsOfUse as AccreditationPolicy.

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.

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

Accreditations​

Accreditations certify that an entity is 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 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 AttestationPolicy 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.

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 VC 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 contains policies.

Here is one process to validate the Trust Chain. The process below does not indicate 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
  • 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
  1. 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

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.