Introduction
The Trusted Issuers Registry (TIR) is a decentralised registry for storing information about Trusted Issuers (TIs), such as public information and accreditations. The TIR stores all information within a smart contract as Verifiable Accreditations, which are issued by Trust Chain participants or self-issued. Issuers can designate proxies for credential verification that can be used to assess the validity of the credential or check whether it has been revoked.
The TIR service comprises a smart contract (TIR SC) and an API (TIR API). The TIR SC is an Ethereum smart contract deployed on the EBSI ledger, and all public smart contract methods are accessible via APIs. Two types of APIs are available: JSON-RPC for write operations and REST for read operations. The JSON-RPC contains the Ethereum transaction build methods and a signed transaction publishing method. The TIR API enables the management and verification of TI information and accreditations. However, the accreditation of TIs is domain-specific and falls outside the scope of EBSI.
The TIR service is protected by the Authorisation Service, which follows the OpenID for Verifiable Presentations (OID4VP) standards; Thus, a bearer token must be requested before any write operations can be performed. Refer to obtain an Access Token for further details on this process.
For more information, see:
- EBSI Support - Service Desk
- EUPL-1.2
- CLI tool page: Test the capabilities using the EBSI CLI tool
Glossary
| Abbreviation | Term | Description |
|---|---|---|
| EBSI SO | EBSI Support Office | Technical support by EBSI team |
| Root TAO | Root Trusted Accreditation Organization | Can issue Verifiable Accreditations for Trusted Accreditation Organization |
| TAO | Trusted Accreditation Organization | Can issue Verifiable Accreditations (Accreditations, Attestations and Authorisations) of the accredited types for legal entities |
| TI | Trusted Issuer | Legal Entity with one or more accreditations. Accredited to accredit, attest or authorise |
| TSR | Trusted Schema Registry | Registry that holds schemas used to validate the Verifiable Credentials |
| TIR | Trusted Issuers Registry | Registry that holds Issuers belonging to a Trust Chain |
Becoming a Trusted Issuer in a Trust Chain
To become a TI, the Legal Entity (LE) must have a valid entry in the DID registry and must be invited into a Trust Chain. An invitation allows the LE to accept the registration by writing the VC into the smart contract. A TI may participate in multiple Trust Chains with multiple roles, and each participation can be revoked separately from the smart contract.
Invite a Legal Entity
Only RTAOs and TAOs participating in a Trust Chain can invite other LEs to join that Trust Chain as a TAO or a TI.
Invitation occurs by first building the Ethereum transaction with setAttributeMetadata and then publishing it to the validators through sendSignedTransaction.
A VC with type VerifiableAccreditationToAccredit (for TAO) or VerifiableAccreditationToAttest (for TI) must be issued for the LE. The VC is the proof of the accreditation, where metadata, like role, the Root TAO, and the inviter, can be seen from the TIR with the attached reservedAttributeId.
The invitation is designed to be built during the VC issuance flow, where the subject LE requests a Verifiable Accreditation from the TAO or Root TAO. The TAO or Root TAO can then initiate a deferred flow for the Credential Request, build the setAttributeMetadata transaction, sign the transaction and publish it, optionally wait for the completion of the transaction, issue the Verifiable Accreditation with the reservedAttributeId and then hand over the credential to the subject LE.
The diagram below assumes that the TAO has received a valid bearer token from EBSI Authorisation API.
Accept invitation
The invitation is accepted by registering the provided VC into the TIR. The Verifiable Accreditation has a reservedAttributeId, which defines the location where the accreditation MUST be registered into. The same location contains the role of the TI and possible revocation status (in-place of the role).
Before the LE can call the TIR, it must obtain an Access Token from the EBSI Authorisation Service. The required scope is tir_invite (tir_write works only if the LE is already a TI), which accepts the received Verifiable Accreditation as proof of access.
Invitation acceptance occurs by first building the Ethereum transaction with setAttributeData and then publishing it to the validators through sendSignedTransaction.
After the Verifiable Accreditation has been received by the LE, it may refresh the access with the EBSI Platform, build a setAttributeData transaction with attributeId from reservedAttributeId, sign the transaction and publish it, and optionally wait for the completion of the transaction. After the transaction has been completed, the LE becomes a TI in the defined Trust Chain and can start to use the tir_write scope if needed.