This page ties together concepts that are also described on the Emerging digital identifiers and credential issuance platform pages. Read it when you need one mental model before diving into APIs or SDKs.
Standards background: IXO aligns with W3C work on decentralized identifiers and verifiable credentials. See Decentralized Identifiers (DIDs) v1.0 and the Verifiable Credentials Data Model. On-chain and interchain specifics use the did:ixo: namespace and protocol modules documented under IXO Protocol.
Definitions
Decentralized Identifier (DID)
A stable, resolvable identifier for an entity (for example did:ixo:…). It names a subject in the graph without requiring a single centralized account system.
DID document
Metadata bound to a DID: verification methods, controllers, services, and links used for authentication and discovery.
Controller
The party (human, org, or automated process) authorized to update the DID document or act for that identifier, within the rules of the protocol and domain.
Subject
The entity a statement is about. In a verifiable credential, the credential subject is identified by a DID (often the holder's DID).
Claim
A structured assertion about reality—typically about a domain or entity—that can be evaluated, disputed, or accepted against a protocol or rubric. Claims carry or reference evidence.
Verifiable credential (VC)
A tamper-evident, issuer-signed bundle of claims about a subject, usable by verifiers without trusting only the holder's copy. Status and revocation may be checked against registry or service endpoints.
Issuer
The party that signs and issues the VC after validation rules are satisfied.
Holder
The party that presents the VC (often the subject).
Verifier
The party that checks signatures, issuer authority, schema, and status before trusting the content.
Lifecycle (end-to-end)
- Register identity — Create or obtain a DID and domain record so the entity exists in the shared model (digital twins, domain registration).
- Submit a claim — Assert something about that entity with evidence and context (claims).
- Validate / evaluate — Humans, services, or Agentic Oracles check the claim against program rules; outcomes may be recorded on-chain or in linked services.
- Issue a VC — After validation, an issuer may bind selected assertions into a verifiable credential whose subject is the holder's DID (credential issuance).
- Verify or revoke — Verifiers check proofs and status; issuers or governance may revoke or supersede credentials when state changes.
How the pieces relate
- Registry / chain — Authoritative pointers and state for domains, claims lifecycle, and credential status, depending on deployment (registry, IXO Protocol).
- Matrix — Optional encrypted rooms and events when evidence or payloads must not live on-chain (IXO Matrix).
Implementation notes
- Use the Authentication matrix and Networks and endpoints so the correct credentials and base URLs match each API surface (API introduction).
- For TypeScript patterns (client setup, entities, claims), start with Developer workflows and Implementation examples.