Skip to main content
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

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.
Metadata bound to a DID: verification methods, controllers, services, and links used for authentication and discovery.
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.
The entity a statement is about. In a verifiable credential, the credential subject is identified by a DID (often the holder’s DID).
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.
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.
The party that signs and issues the VC after validation rules are satisfied.
The party that presents the VC (often the subject).
The party that checks signatures, issuer authority, schema, and status before trusting the content.

​
Lifecycle (end-to-end)

  1. Register identity — Create or obtain a DID and domain record so the entity exists in the shared model (digital twins, domain registration).
  2. Submit a claim — Assert something about that entity with evidence and context (claims).
  3. Validate / evaluate — Humans, services, or Agentic Oracles check the claim against program rules; outcomes may be recorded on-chain or in linked services.
  4. Issue a VC — After validation, an issuer may bind selected assertions into a verifiable credential whose subject is the holder’s DID (credential issuance).
  5. 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

​
See also

Core concepts

Vocabulary for domains, PODs, cooperation, and Qi.

Glossary

Short definitions with links to deeper pages.

Authentication

Credentials and session patterns for developers.