Resolve

GET /v1/resolve/{did}

This endpoint answers "what does this DID resolve to." The DID method segment (did:eid:…, did:ethr:…) selects the chain the oracle reads from; the caller never chooses a chain explicitly. A did:eid:… resolves against eIDChain, a did:ethr:… against Ethereum.

Parameters

Request

curl https://<host>/v1/resolve/did:eid:4tARKz6hK5GuWr9fkdzsG1Bf9X3b3agzh7RPBdjdpLWapHRh \
  -H "Authorization: Bearer idc_live_..."

Response

{
  "id": "did:eid:4tARKz6hK5GuWr9fkdzsG1Bf9X3b3agzh7RPBdjdpLWapHRh",
  "keys": [
    {
      "id": "...",
      "type": "...",
      "publicKeyMultibase": "...",
      "relationships": ["..."]
    }
  ]
}

Each entry in keys is a verification key, and it carries exactly one of two fields, never both:

• publicKeyMultibase: the Substrate, Sr25519-style key encoding, present when the DID resolves against eIDChain.
• blockchainAccountId: an eip155:<chainId>:<address> reference, present when the DID resolves against Ethereum, alongside a type of EcdsaSecp256k1RecoveryMethod2020.

Both fields are omitted from the JSON when not set, rather than sent as null. A client that reads DID documents from more than one chain must handle both shapes; there is no single field that is always present across sources.

Status codes

The 404 case is deliberately not split further. A DID that does not exist on its chain and a DID method the oracle has no adapter for both come back as a plain 404; the response does not distinguish "not found" from "not supported."