identity.org.au

Reference infrastructure

For services

Verify your users without holding their documents

Every identity document you store is liability: breach risk, compliance burden, and user distrust. Verification through the wallet gives you the assurance without the archive.

Talk to the foundation before building production dependencies. Engineering detail is in the protocol documentation.

Start here

Three paths into verification

Step by step Become a verifier The six-step operational path: understand tiers, register on the network, integrate requests, handle responses, meet consent obligations, go live. Plain-technical Integration overview Request and response concepts, zero-knowledge presentation verification, consent records — the architecture before the API reference. Compare approaches Verification solutions compared Document checks, authoritative checks, biometrics, video and reusable credentials — compared by strength, friction and what you end up storing.

What verifiers receive

Assurance without the archive

What services receive and never receive from a verification
You receive You never receive
The user's verification level (Unverified, Basic, Standard or Trusted) Identity document scans or images
A pass/fail verification result for your stated requirement Photos, facial templates, or any biometric data
Zero-knowledge proofs for attribute checks (for example, over 18) Date of birth, address or document numbers — unless the user explicitly consents to share a specific verified claim
Consented verified claims, where a user explicitly approves each one Anything from scopes the user did not consent to

Why this is good for you, not just users

Holding no documents means there are no documents to breach, no honeypot to defend, and a dramatically smaller privacy compliance surface. You get cryptographic assurance with none of the archive risk.

Where the checking happens

The network verifies. Your systems receive a result.

Proofs are checked against the identity network — not inside your product. You ask a structured question, the user consents, and a signed answer arrives. Documents never transit your stack, so there is no archive to protect.

Cooling equipment on the roof of a data centre.

Infrastructure behind the answers — where the verification work runs.

Integration, step by step

Five integration decisions

  1. Step 1 of 5: Decide what you actually need to know

    Most services need less than they collect today. An age check needs “over 18 — yes/no”. A trust gate needs a verification level. Start from the minimum: you cannot leak what you never receive.

  2. Step 2 of 5: Register as a verifier on the network

    Your service gets an on-chain identity that users' wallets display when you make requests — users always see exactly who is asking.

  3. Step 3 of 5: Request verification with a stated purpose

    Each request names the scope and the purpose (for example, verification level Standard, to open an account). The user's wallet presents this to them in plain language.

  4. Step 4 of 5: Receive the result — never the documents

    You receive the verification level and the answer you asked for: a pass/fail result or a zero-knowledge proof you can verify cryptographically. Raw documents and biometrics are not available to verifiers at any price.

  5. Step 5 of 5: Respect the consent lifecycle

    Consents can be time-limited and revoked. When consent expires or is revoked, fresh requests fail until the user re-approves — build your flows to handle that gracefully.

The operational detail for each step is in become a verifier. Engineering documentation — APIs, the consent framework specification and the x/veid module — is at docs.virtengine.com.

Choosing a required level

Ask for the lowest level that manages your risk

Over-asking erodes user trust and adds nothing.

Verification levels and appropriate use cases for services
Level Backed by Appropriate when
Unverified None — this is where every wallet starts. Browsing services that accept the wallet
Basic Basic identity details you enter yourself; A verification session that passes the network's early checks A specific offer's disclosed proof request, when the current service supports it
Standard Local document capture and OCR; the source images stay on your device; User-reviewed, minimum derived fields only if separately approved for submission; Any separately requested biometric scope follows its own consent notice Age and attribute proofs (for example, proving you are over 18)
Trusted Everything required for Standard; Fingerprint or iris capture through your phone's secure hardware; Device integrity attestation (Google Play Integrity or Apple App Attest); A history of successful verification over time Protocol roles or services with separately disclosed, supported proof requirements

The rules you agree to

Purpose-limited verification, enforced

  • State your purpose honestly. Requests carry a purpose string shown to the user; misleading purposes are grounds for removal as a verifier.
  • Ask for the minimum. Data minimisation is a design principle of the protocol, and requests are structured to enforce it.
  • Respect revocation. When a user revokes consent, you keep historical results you lawfully received but lose all future access.
  • No side-channel collection. Attempting to reconstruct or retain more than the user consented to violates the terms that govern verifiers.

Status

The wallet and verification pipeline are open-source reference infrastructure of the VirtEngine network. Talk to us before building production dependencies: hello@det.io.

For services

Stop storing the documents you never wanted to hold.

Verification through the wallet gives you a cryptographic result and nothing to breach. Talk to the foundation before you build.

Become a verifier Integration overview