Skip to main content

Troubleshooting

Accreditation CLI​

The CLI returns "Invalid DID format"​

Symptom: the CLI rejects the indicated DID with an invalid format message.

Cause: the DID does not have the correct prefix for the environment. The prefix must match the DID_PREFIX value of the target TIR server (did:isbe:uc for production, did:isbe:uc-pre for pre-production, ).

Solution: check that the DID you use in --sub and in issuerDid of isbe-config.json has the correct prefix for the environment you are operating in.

The JWT generated by the CLI is rejected by ISBE when trying to publish it​

Symptom: ISBE returns an error when trying to register the accreditation on the blockchain.

Most common cause: the kid field of the signing key does not match exactly the verificationMethod registered in the DID. The kid must have the form <DID>#<JWK_thumbprint>.

Solution: verify that the key.json file has the correct kid field by consulting the DID in the resolver and copying the id of the corresponding verificationMethod.

The CLI cannot find the configuration file​

Symptom: error when executing any CLI command.

Cause: the isbe-data/ directory does not exist or isbe-config.json is not at the expected path.

Solution: run ./isbe-accreditation-cli.sh config --show to generate the default configuration. Then edit isbe-data/isbe-config.json with the values for your environment.

TIR JSON-RPC API​

Error -32600 Unauthorized: Invalid API Key​

Symptom: the call to POST /trusted-issuers-registry/v1/jsonrpc returns HTTP 401 with JSON-RPC error -32600.

Cause: the x-api-key header is missing or the API Key is invalid.

Solution: contact the ISBE team to obtain a valid API Key for the corresponding environment.

Error -32601 Method not found​

Symptom: the call returns JSON-RPC error -32601.

Cause: the method field in the request body does not correspond to any of the three supported methods: setAttributeMetadata, setAttributeData, sendSignedTransaction.

Solution: verify the exact spelling of the method name (case-sensitive).

Error -32602 Invalid params: Missing parameter: ...​

Symptom: the call returns JSON-RPC error -32602 indicating a missing parameter.

Cause: the parameters object in params[0] does not include all required fields for the invoked method.

Solution: check the API reference (JSON-RPC Methods) and make sure to include all mandatory fields with the correct type.

Error -32602 Invalid Ethereum address for parameter from​

Symptom: validation error on the from field.

Cause: the from field is not a valid Ethereum address (must be 0x followed by 40 hexadecimal characters).

Solution: use the Ethereum address of the key that will sign the transaction, not the DID.

Error -32602 Invalid issuerType for parameter issuerType​

Symptom: validation error on the issuerType field.

Cause: the issuerType value is not among the valid enum values: NONE, ROOT_TAO, TAO, TI, REVOKED.

Solution: use the constant name ("TI", "TAO", etc.), not the numeric value, in the JSON-RPC request.

The transaction sent with sendSignedTransaction does not appear in the TIR​

Symptom: sendSignedTransaction returns a transaction hash, but the accreditation is not queryable at the REST endpoint.

Cause: the transaction has been sent to the mempool but has not yet been included in a block, or the transaction failed (status 0x0 in the receipt).

Solution: query the transaction receipt with eth_getTransactionReceipt using the returned hash. Wait until the receipt is available (may take several seconds). If status = 0x0, check the revertReason field of the receipt for more details on the failure.

Trust chain validation​

The verifier rejects a credential issued by my entity​

Symptom: the verifier returns an error indicating the issuer is not trusted.

Step-by-step diagnosis:

  1. Query the TIR with your entity's DID:

    curl "<tir-url>/v1/issuers/<YOUR_DID>/attributes/<ATTRIBUTE_ID>"

    Check that issuerType is TI (not REVOKED) and that validUntil has not passed.

  2. Follow the URL in termsOfUse[0].id and check the status of the TAO that accredited you. If the TAO is revoked or expired, credentials you issue are also invalid.

  3. Check that the credential type you issued is in accreditedFor of your TI accreditation.

  4. Verify that the DID of your TI accreditation signer matches the TAO DID in termsOfUse.

The CLI returns "trust anchor not found in chain"​

Symptom: chain validation fails because it does not reach the configured trust anchor.

Cause: the accreditation chain does not ascend to the DID configured in trustAnchors of the CLI, or the configured DID is incorrect for the environment.

Solution: verify that the trust anchor in isbe-config.json corresponds to the environment (see Environments → Trust anchors). Check that the URL in --accreditedBy of each accreditation points to the TIR of the correct environment.

The accreditation URL returns 404​

Symptom: querying <tir-url>/v1/issuers/{did}/attributes/{attributeId} returns a 404.

Most likely cause: the attributeId in the URL does not match exactly the one registered in the TIR. Remember that the REST endpoint expects the attributeId without the 0x prefix.

Solution: use the 64-character hexadecimal attributeId without the 0x prefix. If the problem persists, contact ISBE to confirm the accreditation was registered on the blockchain.