Skip to main content
European CommissionEBSI European Blockchain
Get Help
Select the Environment you want to work withEnvironment:
warning icon

A new version of this API is now available.

EBSI will stop supporting this maintenance version in the upcoming months. You can find the details of the upcoming release and affected endpoints in the change log. Please contact eu-ebsi@ec.europa.eu if this upcoming release might cause a high impact on either an ongoing development or a piloting demonstration.

JSON-RPC API

Last updated on 
POST 
/trusted-issuers-registry/v4/jsonrpc

The JSON-RPC API provides methods assisting the construction of blockchain transactions for TIR SC operations, and interaction with the ledger.

Request​

Body

The body follows the JSON-RPC 2.0 specification.

It requires the following fields:

  • jsonrpc: must be exactly "2.0"
  • method: method to be invoked
  • params: method parameters
  • id: identifier established by the client

API Methods​

insertIssuer​

Requires an access token with tir_write scope.

Call to build an unsigned transaction to insert a new issuer. This method is restricted to RootTAOs, TAOs, or admins registered in the Trusted Policies Registry. If the new issuer is a RootTAO it must be registered by an admin registered in the Trusted Policies Registry.

Parameters:

  • from: Ethereum address of the signer
  • did: DID of the issuer to insert
  • attributeData: Verifiable credential converted to hex string
  • issuerType: 1 (RootTAO), 2 (TAO), 3 (TI), or 4 (Revoked)
  • taoDid: DID of the TAO accrediting the issuer
  • taoAttributeId: Attribute ID that accredits taoDid as TAO or RootTAO

updateIssuer​

Requires an access token with tir_write scope.

Call to build an unsigned transaction to add a new attribute to, or update an existing attribute of, an issuer. The issuer can be updated by the corresponding TAO, RootTAO, or an admin registered in the Trusted Policies Registry.

Parameters (add a new attribute):

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • attributeData: Verifiable credential converted to hex string
  • issuerType: 1 (RootTAO), 2 (TAO), 3 (TI), or 4 (Revoked)
  • taoDid: DID of the TAO accrediting the issuer
  • taoAttributeId: Attribute ID that accredits taoDid as TAO or RootTAO

Parameters (update an existing attribute):

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • prevAttributeHash: Attribute ID to update
  • attributeData: Verifiable credential converted to hex string
  • issuerType: 1 (RootTAO), 2 (TAO), 3 (TI), or 4 (Revoked)
  • taoDid: DID of the TAO accrediting the issuer
  • taoAttributeId: Attribute ID that accredits taoDid as TAO or RootTAO

setAttributeMetadata​

Requires an access token with tir_write scope.

Call to build an unsigned transaction to set the metadata of an attribute.

Parameters:

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • attributeId: Attribute ID
  • issuerType: 1 (RootTAO), 2 (TAO), 3 (TI), or 4 (Revoked)
  • taoDid: DID of the TAO accrediting the issuer
  • taoAttributeId: Attribute ID that accredits taoDid as TAO or RootTAO

setAttributeData​

Requires an access token with tir_invite or tir_write scope.

Call to build an unsigned transaction to set an attribute.

Parameters:

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • attributeId: ID of the attribute to set
  • attributeData: Verifiable credential converted to hex string

addIssuerProxy​

Requires an access token with tir_write scope.

Call to build an unsigned transaction to insert a new proxy to an issuer. It can be added by the issuer itself or an admin registered in the Trusted Policies Registry to update issuers.

Parameters:

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • proxyData: Proxy configuration to be used during the verification of credentials. For the registration to be accepted, the configured proxy must serve a status list which is valid and signed by the issuer requesting the proxy. The validation is done by combining "prefix" with "testSuffix" and executed before accepting the registration. Proxy must be configured before any VCs are issued. The validation will fail if the credential status proxy doesn't exist. It must be a JSON object converted to a string. Example: JSON.stringify({"prefix":"https://example.net","headers":{"Authorization":"Bearer 1234567890"},"testSuffix":"/cred/1"}).

updateIssuerProxy​

Requires an access token with tir_write scope.

Call to build an unsigned transaction to update an existing proxy of an issuer. It can be updated by the issuer itself or an admin registered in the Trusted Policies Registry to update issuers.

Parameters:

  • from: Ethereum address of the signer
  • did: DID of the issuer
  • proxyId: ID of the existing proxy
  • proxyData: Proxy configuration to be used during the verification of credentials. For the registration to be accepted, the configured proxy must serve a status list which is valid and signed by the issuer requesting the proxy. The validation is done by combining "prefix" with "testSuffix" and executed before accepting the registration. Proxy must be configured before any VCs are issued. The validation will fail if the credential status proxy doesn't exist. It must be a JSON object converted to a string. Example: JSON.stringify({"prefix":"https://example.net","headers":{"Authorization":"Bearer 1234567890"},"testSuffix":"/cred/1"}).

sendSignedTransaction​

Requires an access token with tir_invite or tir_write scope.

Sends a signed transaction to the blockchain and returns the hash of the transaction.

Warning: the transaction is not immediately processed. Make sure to check that the transaction has been successfully included in a block before moving on.

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.

    jsonrpc stringrequired

    Must be exactly "2.0"

    method stringrequired

    Method that needs to be invoked

    params object[]required

    Array of parameters

    id integerrequired

    Identifier established by the client

Responses​

Response

Schema
    jsonrpc string

    Must be exactly "2.0"

    id integer

    Same identifier established by the client in the call

    result object

    Result of the call

    oneOf
    string
Loading...