Digital Trust | Trust Over IP

A Day in your Life with KERI

Nicholas Racz, Senior Partner at Key State Capital and Steering Committee Member at Trust over IP |
A Day in your Life with KERI

 How your digital lifecycle changes with decentralized identity 

 
Trust Over IP (ToIP), a Linux Foundation Decentralized Trust project, has reached a significant milestone: the KERI Suite specifications. This post provides a preview of how our lives could change once the implications of KERI — Key Event Receipt Infrastructure, along with its companion specs ACDC and CESR — are fully realized. One person, one wallet, one day.

Here's your Tuesday.

  

7:12 AM — Waking to a New Call

Your phone buzzes. Unknown number. Normally you'd ignore it — everyone does now because caller ID can be faked by anyone with a $20 robocall kit.

But this call looks different. Your screen shows a verified banner: the name of your dentist's office, their logo, and the reason for the call — "Appointment confirmation." Not pulled from a crowdsourced contacts database. Not a best guess from your carrier.

What happened behind the scenes is that a verifiable dossier — a new type of evidence container standardized at ToIP — traveled with the call. A dossier is not a single credential. It's a curated, cryptographically signed bundle of chained ACDCs (Authentic Chained Data Containers), each link independently verifiable. Think of it as a permission slip assembled from multiple independent roots of trust (authorities in telecom, government, healthcare, etc.) represented as data that you control.

For this call, the dossier proves three things at once: the dentist's office is a real legal entity (via a vLEI (verifiable Legal Entity Identifier) credential anchored to GLEIF, they have the right to use both the phone number (via a telecom authority credential) and their brand assets — name, logo, etc. (via a trademark attestation).

No single issuer vouches for all three claims. Instead, each issuer vouches for what they know, and the dossier binds them together into a single verifiable evidence graph. Your phone verified the whole chain on-device before it ever rang.

This is Open Verifiable Calling, demonstrated by the GSMA — the body representing every major mobile carrier on the planet — at Mobile World Congress in 2026. The dossier protocol and the identifier in your Veridian wallet speak the same language. The dentist's carrier didn't need to call your carrier. No central database was consulted. The proof traveled with the signal.

You answer. Thursday at 2:00 pm works.

  

8:45 AM — Walking Into a New Doctor's Office

You moved to Utah six months ago. Today's your first visit to a new primary care physician. The front desk hands you a tablet and asks for your ID and insurance.

You have an app on your phone called Veridian. It holds your identifier — not a username, not an account number, not a token issued by a company. A cryptographic identifier that you created, that you control, and that no one can revoke.You open Veridian. Tap "present." The office's system requests three things: proof of identity, proof of insurance, and authorization to pull your records from your previous provider in Ohio.

Here's what actually happens:

Identity. Utah doesn't issue digital IDs the way other states do. Under SB 275 — passed unanimously by both chambers of the Utah legislature — the state endorses identifiers that citizens already hold rather than issuing its own. You brought your Veridian identifier to the DMV when you moved. Utah verified you and endorsed your digital identity. Now that endorsement is a credential — one you solely use, one that works anywhere, one that isn't locked to Utah's servers or Apple's platform or anyone's proprietary system — sitting in your wallet.

You share your name, date of birth, and address. Nothing else. Not your driver's license number, not your Social Security number. The office sees exactly and only what they need because the credential supports selective disclosure. You prove specific facts without exposing the underlying data. The law requires the office not to request more than they require.

Insurance. Your employer issued you a benefits credential through the same protocol. Your insurer verified it. It sits in Veridian next to your state endorsement. You share your coverage details. Same tap.

Records. This is the part that used to take six weeks and thirteen phone calls. Your previous doctor holds your records. You authorize the transfer — right now, from your phone — by issuing a credential that grants this specific office access to your specific record types for a specific duration. It's not a form you signed that someone will fax. It's a cryptographic authorization, verifiable by your previous provider, traceable to your identifier, expiring when you say it expires.

Your previous provider's system verifies three things without calling anyone:

  • Is this request from a legitimate medical practice? (The new doctor holds a credential chain back to their licensing board.)

  • Did the patient actually consent? (Your authorization credential is right there, signed by your identifier.)

  • Are the records intact? (Each record is a self-certifying container. Tamper with a byte and verification fails.)

The records transfer. You're seen on time. One wallet. One tap for each exchange.

  

11:30 AM — Signing a Regulatory Filing

You're the CFO of a mid-size company. The quarterly filing is due. You open your laptop and review the document your team prepared. Time to sign.

Your company holds a vLEI — a verifiable Legal Entity Identifier — issued under the system run by GLEIF, the global foundation that assigns legal entity codes to every organization in international finance. The vLEI is an ISO standard. But a company identifier alone doesn't sign documents. People do. And the vLEI system is precise about which people can do what.

You hold two credentials in Veridian that make this possible:

An OOR — Official Organizational Role — credential that attests you hold the position of Chief Financial Officer. This credential didn't come from your company alone. Your company's authorized representatives issued an OOR Authorization credential to a Qualified vLEI Issuer (QVI), saying: "We authorize you to issue an OOR credential for this person, for this role." The QVI then verified you independently and issued the OOR. Two parties had to agree before the credential existed. The chain was created when GLEIF authorized the QVI, the QVI verified the company, the company designated you, and the QVI confirmed you. Every link was created by an identifier controlled by those individuals following the KERI protocol. Every link is an ACDC credential, and every link is independently verifiable.

You also hold an ECR — Engagement Context Role — credential that binds you to a specific functional context: "Authorized XBRL Report Signer." Where the OOR captures your position in the corporate hierarchy (CFO -- a role defined in articles of incorporation, carrying fiduciary obligations), the ECR captures what you're actually authorized to *do* in a specific operational domain. A company might have three vice presidents (three OORs), but only one of them holds the ECR for signing regulatory filings. The ECR maps organizational authority to domain-specific constraints.

When you sign the quarterly filing, the signature chains through both credentials. The regulator who receives it can verify not just that you signed it, but that you hold the position (OOR: CFO) and the domain authorization (ECR: XBRL Report Signer) that makes the signature meaningful. The chain of trust runs from your signature to your role to your company to the QVI to GLEIF. Every step is cryptographically verified with no intermediary trusted on faith.

This same vLEI credential chain is what the GSMA uses for Open Verifiable Calling. The dentist's office that called you this morning? Their organizational identity was verified through the same system. The dossier that proved "this call is really from Bright Smile Dental" and the credential chain that proves "this filing is really from your company's CFO" are built from the same protocol suite, the same credential format, the same trust infrastructure.

One protocol suite. Telecom and finance, connected not by a platform, but by a shared grammar of trust.

  

2:15 PM — Your Phone is Stolen

You left your phone at a coffee shop. Someone took it. They have your device, your Veridian app, your biometrics are bypassed (let's assume the worst). They have your active signing keys.

In any other system, this is catastrophic. Your identity is gone. Someone calls a certificate authority, revokes your old credential, and you start over — new identifiers, new credentials, weeks of re-verification. Or worse: the attacker uses your credentials before you notice.

Not here. Because of pre-rotation.

When you first created your identifier in Veridian — maybe years ago — the app generated two sets of cryptographic keys. The first set became your active signing keys, the ones you've been using all day. The second set, your rotation keys, was locked away — on a hardware key in your desk drawer, in a secure backup, split between trusted family members, or however you configured it. The actual rotation keys were never stored on your phone. But a cryptographic commitment to them — a one-way hash that proves they were chosen in advance -- was baked into your identifier from the very first moment it existed.

The thief has your active keys. They can try to sign things as you. But here's what they cannot do: they cannot rotate your identifier to any keys they control. You have the authority to rotate from the keys committed at the time of your identifier’s creation to keys the thief has never seen, that were never on the device they stole, and that cannot be derived from anything they possess.

You get home. You pull out your hardware key. You execute a rotation from your laptop. Your pre-committed rotation keys are revealed and become the new active keys. A fresh commitment to the next set of rotation keys is recorded. The stolen keys are dead. Your identifier survives. Every credential you hold -- Utah's endorsement, your insurance, your OOR as CFO, your ECR for regulatory signing, your medical authorizations -- remains valid because they're bound to your identifier, not to any particular set of keys.

No third-party (such as a certificate authority) had to intervene. No government office had to reissue anything. No blockchain had to vote. You recovered your own identity because the math was set up from day one to let you do exactly that.

And because each set of rotation keys is used exactly once and hidden behind quantum-resistant hash functions until the moment they're needed, this protection holds even against an attacker with a future quantum computer. The keys they'd need to forge are protected by assumptions that don't break, and you maintain control of your identity indefinitely,

Instead of a nightmare, your Tuesday simply resumes.

 
Why This Works: The Trust Spanning Layer

Everything that happened today — answering a verified call, checking in at a doctor's office, signing a regulatory filing, recovering from a stolen phone — used the same identifier, the same wallet, the same protocol suite. This isn't an accident of adoption. It's the result of an architectural decision.

The Trust over IP Project organizes digital trust into a layered stack, mirroring how the internet itself was built. At the bottom: transport protocols that move data. At the top: applications that serve users. And in the middle, a single narrow waist — a **trust spanning layer** — that connects everything above to everything below.

The original internet has IP (Internet Protocol) as its spanning layer. Every application -- web, email, video, messaging -- converges on IP, and IP runs over every physical network -- fiber, wireless, satellite. That architectural bottleneck is why the internet works: build one thing that spans, and everything else composes on top of it.

KERI is the spanning layer for trust. Every credential format, every governance framework, every verification protocol converges on KERI's key management and ACDC's credential containers. They run over every transport. The same credential that travels with a phone call can be presented over Bluetooth at a doctor's office or attached to a regulatory filing submitted over HTTPS.

But a spanning layer for trust needs something the internet's spanning layer never did: governance. TCP/IP doesn't care who you are. A trust layer has to. The question is: who writes the rules?

 
The Governance That Governs Itself

ToIP's answer is the Ecosystem Governance Framework (EGF) — a standardized template for any community that needs to define its own trust rules. An EGF specifies who can issue credentials, what roles exist, how participants are vetted, how disputes are resolved, and how the framework itself evolves. Its governance as infrastructure, not governance as bureaucracy.

The exemplary instance — the one that proves the model works at scale — is GLEIF's vLEI Ecosystem Governance Framework (EGF). It defines the full credential chain you used at 11:30 this morning: how QVIs are qualified, how Legal Entity credentials are issued, how OOR and ECR authorizations work, how revocation propagates, how annual reviews are conducted. It's currently in its fourth major version, with a Trust Assurance Framework covering security, privacy, and confidentiality policies.

But here's the beautiful thing: GLEIF's EGF is one instance of the meta-model. Healthcare could publish its own EGF — different credential schemas, different vetting requirements, different roles — and it would interoperate with GLEIF's at the spanning layer. Utah's SEDI framework is, in effect, another instance. The GSMA's OVC governance is another. Each ecosystem defines its own rules. None needs permission from the others. But because they all converge on the same spanning layer, credentials flow between them.

This is the decentralized trust graph. Not a single pyramid with a single root of trust, but a network of independent ecosystems, each with its own governance, connected by a shared protocol. The dossier that verified your dentist's phone call this morning aggregated credentials from three independent roots of trust — a legal entity registry, a telecom authority, a trademark steward — into one verifiable evidence bundle. No single authority governed all three. The dossier protocol let them compose.

The vLEI EGF proves this works for global finance. OVC proves it works for telecom. Utah's SEDI proves it works for government. The Vital Initiative is building this for healthcare. The spanning layer is what makes them the same story.

What Just Happened at Linux Foundation Decentralized Trust

On January 21, 2026, Trust over IP formally approved KERI, ACDC, and CESR as ratified specifications. This wasn't a product launch. The technology was already running. vLEIs were already ISO-standardized. OVC was already live at Mobile World Congress. Utah's law was already passed.

What happened was that the specifications found their permanent institutional home — under the same foundation that stewards Linux, Kubernetes, and the infrastructure the internet runs on. The spanning layer became a standard. The governance meta-model became a template anyone can adopt.

Four industries touched your Tuesday: telecom, government, healthcare, finance. Each adopted this technology independently, for their own reasons, on their own timeline. None needed permission from the others. But because they chose the same open protocol suite — and because that protocol suite is now anchored at a foundation built to outlast any single company or government — they composed a coherent experience without anyone having to build that integration.

No vendor lock-in. No platform toll. No single point of failure. No permission required. Just one wallet, one identifier, and a Tuesday that works.

Resources

AI Disclosure: This post used artificial intelligence tools for research, structural assistance, graphic creation, or grammatical refinement. The final content was reviewed, edited, and validated by human contributors to LF Decentralized Trust to ensure accuracy and alignment with our community standards. We remain committed to transparency in the use of generative technologies within the open source ecosystem.

Back to all blog posts