Skip to main content

Become a Root Trusted Accreditation Organisation

Step 1. Create DID and DID document​

Follow the Legal Entity DID creation guide to create a DID.

Step 2. Obtain Verifiable Authorisation to Onboard​

The VerifiableAuthorisationToOnboard credential will allow you to request access to register your new DID into the DID registry as a Root TAO. You can obtain this credential via email request with the EBSI Support Office.

note

Before you can request the VerifiableAuthorisationToOnboard, you must accept and sign the legal package as an EBSI Application Service Provider via the Acceptance form.

Hands on!

Email the EBSI Support Office.

  • For the 'Subject' field, select 'Register a DID'.

After successfully emailing the request, the EBSI Support Office will issue you the VerifiableAuthorisationToOnboard credential.

Step 3. Register DID and DID document in the EBSI DID Registry​

Use the Verifiable Authorisation to Onboard received in Step 2 to register your DID in the EBSI DID Registry.

info

Follow the Register your DID guide to complete DID registration.

Step 4. Obtain Verifiable Authorisation for Trust Chain​

Root TAOs represent the root or top-level trust point in the EBSI's Issuers Trust model and must be onboarded directly by EBSI. The Trusted Issuers Registry (TIR) is a registry containing a list of Legal Entities that are authorised to issue certain types of credentials.

To receive an invitation from the EBSI Credential Issuer, you must first request a VerifiableAuthorisationForTrustChain. The Credential Issuer will then invite you to join the Trust Chain, reserving a location and issuing the VerifiableAuthorisationForTrustChain for that specific location.

Step 5. Register your Verifiable Authorisation for Trust Chain​

After you have received the Verifiable Authorisation for Trust Chain, you must complete the invitation by registering the credential into the TIR. The following steps will guide you through this process.

Step 5.1 Obtain tir_invite access token from the Authorisation API to write into the Trusted Issuers Registry​

To request a tir_invite access token, you need to present proof of ownership of your Verifiable Authorisation for Trust Chain to the EBSI Authorisation API.

API CALL

Follow this sequence of API calls to request a tir_invite access token:

  • GET Presentation definition: Begin by fetching the presentation definition for the tir_invite scope.

  • POST Token Endpoint: Create and submit a presentation according to the fetched definition that contains proof of ownership of your Verifiable Authorisation for Trust Chain

For further details, please consult our Access Control guide

Upon successful submission, the EBSI Authorisation API will issue a short-lived, OAuth 2.0 compatible tir_invite access token.

Step 5.2 Register Verifiable Authorisation for Trust Chain in TIR​

The invitation is accepted by registering your Verifiable Authorisation for Trust Chain into the Trusted Issuers Registry.

The Verifiable Authorisation has a reservedAttributeId that defines the location where the authorisation must be registered into. You should build a setAttributeData transaction with attributeId from reservedAttributeId.

API CALL

The following endpoint must be used to register your Verifiable Authorisation for Trust Chain into the TIR:

Upon successful submission, your wallet will receive an HTTP 200 transaction from the EBSI TIR Service to be signed. Once the transaction is signed, it is then ready to be returned using the sendSignedTransaction method, which will broadcast the transaction to the ledger. In return, you will receive the transaction hash.

You can get the receipt of the transaction by calling the eth_getTransactionReceipt method of Ledger API's Besu endpoint.

Receipts for pending transactions are not available, therefore you will have to wait until the transaction has been processed � usually a few seconds. We recommend you to poll the eth_getTransactionReceipt method until the receipt is available.

Once the receipt is available, you can check the status field to know if the transaction succeeded (0x1) or failed (0x0). If the transaction failed, the revertReason field will give you insights about the reason for the failure. You can learn more about the format of the revert reason in Besu's documentation.

API CALL

The following endpoint must be used to send a signed transaction:

The following endpoint must be used to check the status of the transaction:

After the transaction has been completed, you are officially onboarded as a Root TAO. Congratulations! ??

Last updated on