IXO Credentials

IXO Credentials is the system IXO uses to issue verifiable credentials to people, keep them in the person's encrypted Vault, share only the claims a service needs, and revoke them. Read this page to understand the parts and how they connect before you integrate as an issuer, a verifier or a wallet. To try the whole chain first, follow Try it on devnet. For the general model of Decentralized Identifiers (DIDs) and credentials on IXO, see Identity and credentials.

Where it runs

IXO Credentials is live on all three networks. Each network has its own Credentials worker and its own Auth Hub wallet; nothing is shared between networks.

Every worker host describes itself at /docs (interactive API reference), /openapi.json (the full contract) and /llms.txt (a short summary for agents), for example dev.credentials.ixo.earth/docs. The library for issuers, verifiers and wallets is @ixo/credentials-kit on npm.

Devnet also has a test issuer and a test verifier for trying the flow. They issue and accept fake credentials only; never use them for real people. See Try it on devnet.

What it is

IXO Credentials uses open standards end to end:

IXO implements a profile of each standard, not all of it. For example: no authorization code flow, no transaction codes, no batch issuance, and requests outside the DCQL subset are refused. The exact versions, what is implemented, and how this compares with the European Digital Identity (EUDI) Wallet are on Standards and conformance.

On top of the standards, IXO adds one shared service and one set of rules:

• The Credentials worker lets issuers and verifiers reach a person by their DID. It has four jobs: an offer inbox (credential offers addressed to a DID), a presentation broker (signed proof requests addressed to a DID), a status-list registry (issuer-signed revocation lists) and a public catalog (what each issuer says it issues and what each verifier says it accepts, with the name, logo and card look wallets show). It also keeps each person's block list: the senders that person no longer accepts offers or requests from. It never holds a claim or a credential, and never signs one.
• The IXO Credential Profile v1 narrows each standard to one way of doing things, so every IXO issuer, verifier and wallet checks the same things.

Credential types (vct values) are not hosted on the Credentials worker. New types follow the existing IXO pattern: a type document in the GitHub repository ixofoundation/ns and a protocol entity, as the KYCAMLLevel1 type does. Self's IdentityLevel1 keeps its current vct (https://credentials.ixo.world/types/IdentityLevel1).

The roles

Credentials are stored only in the person's Vault, an end-to-end encrypted room on IXO Matrix. The Auth Hub keeps its working data for the wallet (cached offers and requests, the cached Vault index, standing consents, the activity log, its copy of the block list) in a credentials database of its own, separate from the Hub's account database.

How it fits together

The credential travels from the issuer to the wallet, and the presentation from the wallet to the verifier, encrypted to the verifier's key. Neither passes through the Credentials worker. Only the Auth Hub receives webhooks; any other wallet polls the worker as the person.

When to use it

Use IXO Credentials when:

• your service checks something about a person once (identity, age, a qualification) and other services need to rely on that check;
• your service needs proof of a fact about a person without collecting the underlying data, for example "over 18" without a birth date;
• you need to revoke what you issued.

Do not use it for:

• claims about entities, projects or impact outcomes: use IXO claims;
• service-to-service authorization: use UCAN delegations and the patterns in Authentication.

Core capabilities

What IXO adds and what stays standard

What protects a person

There is no central trust list. The same rules apply to every sender, IXO's own services included. Every DID is its own sender, exactly as written: did:web:example.com, did:web:a.example.com and did:web:example.com:user:alice are three senders, each with its own limits, its own block and its own catalog entry. There is no grouping by domain.

Names, logos and card looks are self-declared. Each comes only from the sender's own catalog entry, never from an offer or a request. Nobody checks them, and a sender can copy another sender's name and look. So none of the protections below depends on a name or a look.

The Auth Hub never shows a web address that a sender supplied, not as a link and not as text to copy. A harmful link would be blamed on IXO. A sender appears only by its name, logo and card look, and the Hub loads logos only through its own media proxy (png, jpeg or webp).

What protects a person:

• The person's block list. A person can block any issuer or verifier. The Credentials worker then refuses that sender's offers and requests for them, and closes the ones already waiting. See Block a sender.
• Two waiting items per sender. A sender can have at most 2 offers and, separately, 2 requests waiting for one person at a time. A sender cannot fill a person's inbox.
• The cryptographic check of every credential. A wallet stores a credential only if the issuer's signature is valid, it is about the person (sub) and it is bound to the person's key (cnf). A verifier checks the same on every presentation, plus status and key binding.
• Each verifier's own choice of accepted issuers. A verifier names the issuer DIDs it accepts for each type. A credential from any other issuer fails the check, whatever name or look it carries.

What a verifier always sees

Selective disclosure hides only the claims the issuer made disclosable and the request did not ask for. Every presentation also shows the verifier, in the clear:

• the person's IXO account ID (sub, their did:ixo, the same at every service);
• the holder key (cnf.jwk, also the same at every service);
• the status reference (the status list URL and the person's index in it);
• the issuer (iss), the type (vct) and the dates (iat, exp, and nbf when set);
• every claim the issuer did not make selectively disclosable (for Self, for example identity_level and document_verified).

So two services that compare notes can tell they saw the same person. This is what every presentation carries; it is not a list the wallet shows on its sharing screen.

Next steps