DACS-2 · Vet · vLEI recipe
vLEI Verifier
Demos acts as a relying party: it reads a KERI/ACDC vLEI credential chain natively, walks it to the pinned GLEIF root, checks delegation, revocation and authority scope, then distils the verdict into a signed, digest-only attestation and anchors it on-chain — resolvable by anyone. It meters per verification and never re-issues or wraps the credentials.
At a glance
Role
A relying party / verifier — consumes vLEI, emits a verdict. Not an issuer, not a wallet.
Privacy
Digest-only. Legal names, roles, authority scope never leave the KERI layer — only hashes are signed & anchored.
Trust anchor
Schema SAIDs are pinned; the chain root must be the GLEIF root AID. Nothing off-catalogue is trusted.
Fail-closed
Unresolvable, revoked, off-root, or out-of-scope → FAIL. Silence is never a pass.
How verification works — the five-step flow
Each verification talks to KERIA over the network (OOBI resolution, key-state, TEL status, IPEX presentation, schema resolution) — it is not a pure function over local data.
0
Presentation & key-control
The holder presents the chain over IPEX. An agent proves live control of its delegated key over a fresh challenge, bound to the exact transaction — so a captured proof can't be replayed.
keri/util.ts · challenge.ts
1
Key & schema retrieval
KERIA resolves OOBIs, pulls each issuer's Key Event Log (KEL), and fetches the vLEI schemas from the GLEIF schema server, pinning each by SAID.
keyStates() · OOBI resolve
2
Key-state & delegation
Records an auditable key-state digest per issuer. For an agent, confirms the agent AID is a delegated identifier whose delegator (di) is the issuing entity.
verify.ts
3
ACDC chain walk
Breadth-first walk of the e.* edges to the root. Schema SAIDs pinned; each credential's own SAID + issuer↔issuee lineage authenticated (I2I) or exempted (NI2I).
verify.ts · schemas.ts
4
Revocation (TEL)
Checks each credential's Transaction Event Log status at time-of-use. Anything but status=0 (issued) fails closed.
verify.ts
5
Verdict
Evaluates the proposed transaction against the credential's machine-readable authorityScope and emits a signed record with a recordDigest — digest only, ready to anchor.
verify.ts
Step 3
Trust chain
Flow 2 — chained through an accountable officer. Authority flows left-to-right from the GLEIF root down to the delegated agent. Each card is one credential; the label under the arrow is the ACDC edge that links it to its parent.
Step 5
Verification verdict
The same verifier, run over a valid presentation and three tampered ones. Every negative fails closed.
DACS-1 & DACS-2
Attestation & anchor
The verdict becomes an on-substrate primitive: a signed, digest-only CCI claim, anchored as a Storage Program and exposed to the DACS pipeline as a standard VerifyResult.
Signed attestation — DACS-1, digest-only
🔒
No credential contents (legal names, authority scope, roles) ever enter the attestation. A relying party re-presents the chain and recomputes recordDigest / chainDigest to correlate; the anchor itself leaks nothing.
Anchor & DACS-2 VerifyResult
AttestationRef §7.5.2
VerifyResult §7.5
Wire it in
Integration
The verifier lives in the SDK (@kynesyslabs/demosdk/identity/vlei) and takes no KERI-client dependency — it reads through an injected source, so you plug in any KERI transport.
The injection seam
Implement one interface (the POC adapts a signify-ts client in ~10 lines) and call verifyChain.
interface VleiCredentialSource {
getCredential(said): Promise<VleiCredential>
getKeyState(aid): Promise<VleiKeyState>
}
// then, transport-agnostic:
await verifyChain(source, leafSaid, gleifRoot, opts)
Two sanctioned grant flows
Flow 1 direct
entity ─e.le▶ LE vLEI
The Legal Entity grants the agent-authority credential directly to the delegated agent.
Flow 2 via officer
agent ─e.ecr (NI2I)▶ officer ECR
Chained through an accountable officer's ECR — the accountable human sits in the chain.
Deployment — the local KERI stack
| Container | Ports | Role | Source |
|---|---|---|---|
| keria | 3901 / 3903 | The agent every client talks to — resolves OOBIs, holds each client's store. | public (weboftrust) |
| witness-demo | 5642–5644 | Demo witnesses — sign/receipt KEL events. | public (weboftrust) |
| vlei-server | 7723 | GLEIF vLEI schema + OOBI server (QVI/LE/ECR/OOR schemas). | public (GLEIF) |
| agent-schema-server | 7724 | Serves our agent-authority schema to KERIA (agent flows only). | this repo |
| verifier-app | 8080 | This page + the /api/run live-verification endpoint. | this repo |
Do I need sandbox keys? No — it works fully, standalone, today.
The local stack is built entirely from public images — GLEIF's vLEI schema server and the weboftrust KERIA/witness images. There is no partner auth anywhere.
- The client's only credential is a locally-generated passcode (randomPasscode(), 21 chars) that seeds its own KERIA agent — not a partner-issued API key.
- All endpoints are docker-internal service names plus the KERIA admin/boot ports.
- Sandbox keys matter only to verify real-world credentials on a partner's hosted KERI network. That is an env-URL swap (KERIA_ADMIN_URL, KERIA_BOOT_URL, VLEI_SERVER_URL) — a config change, not a code change — gated on the partnership agreement, never a functional dependency.
Deploy
# the whole stack — KERI + schema server + app — is one docker compose
docker compose up -d --build
# then open the app and press “Run live verification”: a real KERIA
# mint → present → verify → revoke runs against the co-located stack (~60s).
Reference
Status & glossary
Status
✓Verifier — 5-step flow, both grant flows, delegation + scope + replay-proof.
✓DACS-1 attestation — build / sign / verify + tamper & negative coverage.
✓Anchor & resolve — SR-2 Storage-Program shape + owner check.
✓DACS-2 VerifyResult — mapped + conformance-checked against the goldens.
✓Live & hosted — 41 SDK unit tests, 3 live KERIA flows, on-chain anchor round-trip, one-command docker compose.
◔Officer OOR/ECR — independently validate the accountable officer (validated in-chain in Flow 2 today).
◔Live on-chain anchoring — wire the SR-2 backend to a running node RPC (shape done, unit-tested).
◔Partner sandbox endpoints — point at a real hosted network (config swap, gated on agreement).
Glossary
SAID — self-addressing identifier: a content hash that names a credential or schema.
ACDC — Authentic Chained Data Container: the verifiable credential format.
KEL / TEL — Key / Transaction Event Log: an AID's key history / a credential's issue-revoke log.
OOBI — Out-Of-Band Introduction: a URL to discover and validate an AID or schema.
IPEX — Issuance & Presentation Exchange: the grant/admit protocol for handing over a credential.
I2I / NI2I — edge operators: issuer-to-issuee (lineage enforced) / not-issuer-to-issuee (third-party reference).
QVI / LE — Qualified vLEI Issuer / Legal Entity credentials in the vLEI chain.
ECR / OOR — Engagement Context Role / Official Organizational Role — a person's credential under an LE.
di — a delegated AID's delegator; must equal the issuing entity for the agent to be valid.
recordDigest — hash of the full verdict — the only link back to the chain that gets anchored.