Skip to main content
European CommissionEBSI European Blockchain
Select the Environment you want to work withEnvironment:

JSON-RPC API

Last updated on
POST 

/trusted-issuers-registry/v5/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

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
  • revisionId: Attribute ID (hexadecimal string prefixed with 0x)
  • issuerType: 1 (RootTAO), 2 (TAO), 3 (TI), or 4 (Revoked)
  • taoDid: DID of the TAO accrediting the issuer
  • attributeIdTao: Attribute ID that accredits taoDid as TAO or RootTAO (hexadecimal string prefixed with 0x)

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 (hexadecimal string prefixed with 0x)
  • attributeData: Verifiable credential converted to an hexadecimal string prefixed with 0x

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 (hexadecimal string prefixed with 0x)
  • 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...