Identity and data on one layer: how Ontology’s decentralized identity works

By the end of 2026, every EU member state has to make at least one European Digital Identity Wallet available to its citizens, under the amended eIDAS regulation. It is the largest deployment of decentralized identity anyone has attempted, and it rests on an architecture that will be familiar to anyone who has followed Ontology: the person holds their own credentials, shares only what a service needs, and the service checks the claim without going back to whoever issued it.

That architecture has three roles and one question. The roles are issuer, holder and verifier. The question is where the trust anchor lives: the place a verifier goes to confirm that an identifier is real, that a key belongs to it, and that a credential has not been withdrawn. This piece walks through how Ontology answers that question, and why identity and data belong on the same layer.

Decentralized identity has three roles and one public registry

An issuer is anyone whose word a verifier will accept about something: a bank confirming a customer passed its checks, a university confirming a degree, a platform confirming a player’s record. A holder is the person the claim is about. A verifier is the service that needs to know.

In older systems the verifier asks the issuer directly every time, which means the issuer learns who is checking on whom, and the claim is worthless the day the issuer goes offline. In decentralized identity the verifier asks a registry instead. Ontology’s registry is its public chain. Identifiers, their public keys and the status of credentials are written there, and anyone can read them. The issuer signs a claim once and steps out of the way.

ONT ID: an identifier the holder controls

ONT ID is Ontology’s decentralized identity framework, built on the W3C Decentralized Identifiers model. A DID is a string that resolves to a document listing the keys that can act for it. On Ontology that document is anchored on chain, so resolving it does not depend on any company’s server staying up.

Three properties follow from that, and they are the ones that matter in practice. The holder controls the keys, so no platform can repossess the identifier or lock the person out of it. Keys can be rotated without changing the identifier, so a lost phone does not mean a lost identity. And one person can hold several identifiers for different parts of their life, so a gaming profile and a financial profile do not have to be linkable unless the person links them.

Credentials carry the claims, the chain carries the checks

The claims themselves travel as verifiable credentials: signed statements from an issuer about a holder, kept by the holder. A credential can carry a single fact, such as “over 18” or “passed KYC with this provider on this date”, so it can be shown without the rest of a record.

What goes on chain is deliberately small. The issuer’s identifier and keys, so a verifier can check the signature. The holder’s identifier, so the credential can be tied to the person presenting it. And a status list entry, so the issuer can revoke the credential and every later check fails. The credential’s content, the documents behind it and any profile built from it stay off chain with the holder. A verifier gets an answer to one question and learns nothing else from the chain.

This split is what makes the system usable for regulated work. Last week we looked at SEC Commissioner Hester Peirce’s case for verifying facts instead of collecting files. Every proposal in that speech needs exactly these three things: a claim the holder carries, an identifier anyone can resolve, and a way to withdraw the claim.

Identity is half the layer, data is the other half

An identifier with nothing attached is a login. What makes decentralized identity useful is the data a person can attach to it and prove: a verified identity check, a reputation built from years of play, a health record, a history of contributions. That is why Ontology treats identity and data as one layer rather than two products.

ONTO Wallet is where that comes together for a user. A person connects the sources they choose, such as social accounts, gaming accounts and identity verification, and the results are held against their own identifier. When a service asks for something, the person decides item by item what it sees. In May we argued that the right vocabulary for this is consent, audit and revocation rather than ownership alone: being able to grant access, see where data went, and take access back. The status list is the mechanism that makes the third of those real.

Data held this way can be built on. A reputation score is a good example: it is derived from data the person connected, it is held by them, and it can be shown to a new community without that community needing access to the raw records. That is next week’s subject.

Why a public chain

Ontology could have built decentralized identity on a private database run by one company. It did not, for three reasons that each come from the problem rather than from a preference for blockchains.

The first is portability. A credential issued by one company needs to be checkable by a competitor, a regulator in another country, or a service that does not exist yet. A public registry is the one place all of them can read without asking anyone’s permission.

The second is survival. Issuers go out of business, platforms shut down and APIs change. A credential anchored on a public chain can still be verified years later, after the system that issued it has gone.

The third is privacy for the holder. When verification goes through a registry instead of the issuer, no single party sees every check. The bank that verified you does not learn which exchange, game or employer asked.

The EU’s wallets will make the decentralized identity model of holder, issuer and verifier familiar to hundreds of millions of people over the next few years, inside national trust frameworks. Ontology runs the same model on a public chain that works across borders and across industries, and has done since 2018. If you are building something that needs to know a fact about its users and would rather they held the evidence, that layer is ready to build on.

Further reading from Ontology: Zero-knowledge KYC and the Peirce speech, Build a gaming reputation nobody can fake, Beyond Data Ownership: Consent, Audit, Revocation and our Korea Blockchain Week recap.