identity.org.au

identity.org.au is not an Australian Government service. It is an open-source community service stewarded by the not-for-profit DETIO Foundation, currently in the process of applying for accreditation under the Digital ID Act 2024. How this service is different

How it works

Your phone holds the evidence. The network holds the proof.

The entire design follows one rule: the sensitive material stays with you, and everyone else gets answers. Here is the pipeline, in plain language.

Part one — on your device

  1. Capture happens on your phone

    Document scan (front and back), a selfie with active liveness challenges, and — for the highest level — fingerprint or iris through your phone's secure hardware.

  2. Reading and checking happen on your phone

    The document's text is read automatically (OCR) and quality checks run locally: edges, glare, face confidence, liveness gating. You review everything.

  3. Encryption happens on your phone

    Before anything is transmitted, the evidence is sealed with envelope encryption (X25519-XSalsa20-Poly1305). From this moment, your evidence is ciphertext everywhere except your device.

Part two — on the network

  1. Verification runs inside trusted processing units

    Your encrypted submission is opened only inside hardware-sealed enclaves — trusted processing units the chain checks by fingerprint before any data enters. Machine-learning models assess document authenticity, face match and liveness in an environment no operator can look into; raw data is destroyed when scoring ends.

  2. Results are recorded, evidence is not

    The network records the outcome: your verification level and pass/fail results, plus encrypted references. Your documents and biometrics are never written to the chain in readable form.

  3. Your level becomes usable everywhere

    Any participating service can now ask the network to confirm your identity — with your consent, per request — without any service ever holding your documents.

Why split it this way?

Conventional identity systems copy your documents into a central database — and central databases get breached. This design means there is nothing central to raid: your evidence exists in readable form only on your device, and the network holds tamper-proof results.

Inside the trusted processing unit

The step that deserves the closest look is the processing itself. Your encrypted evidence is opened only inside a hardware-sealed vault whose key is forged in the hardware and never exists outside it — and the chain checks the vault's exact fingerprint before any data enters.

1 · On your device Documents + biometrics Sealed before it moves Your keys never leave this phone Held in secure hardware — not exportable IN TRANSIT Unreadable to every network, carrier and server it crosses 2 · The trusted processing unit A hardware-sealed vault — AMD SEV-SNP · Intel SGX · AWS Nitro The attestation gate: the chain verifies the vault's exact measurement before any data enters The key is forged inside Derived from the hardware itself, sealed to this vault — it never exists anywhere outside it Verification runs Document checks, face match, liveness — scored in isolation Raw data is destroyed The vault keeps nothing: your documents and biometrics are destroyed when scoring ends No window · no console · no operator door — by design, not by policy Result only 3 · The chain Score + tier Pass / fail results Never documents, never biometrics OUTSIDE THE VAULT — NO ACCESS PATH EXISTS Operators Providers The foundation Designed so that no one — not operators, not providers, not the foundation — can open the processing environment The lock seals on your device · the gate checks the vault before data enters · the key never exists outside the hardware · only the result leaves
The lock and the key: sealed on your device, admitted through the attestation gate, processed and destroyed inside the vault — only the result reaches the chain.
Trusted processing, explained in full — how the vault works and when data is destroyed

When a service asks about you

Verification happens once. Sharing happens as often as you approve it — and only what you approve. Two screens do all the work:

Sharing request A service is asking to check your identity REQUESTED BY example-service.com.au They will see Verification level Standard Over 18 Yes / no only — not your date of birth They will never see Your documents Your photos or biometric data Your date of birth or address This consent expires automatically in 30 days. Approve Decline
The consent screen: who is asking, exactly what they will see, what they will never see, and when the consent expires. Nothing moves until you approve.
Share only what's needed Zero-knowledge proof Prove the answer — keep the data STAYS ON YOUR DEVICE — ENCRYPTED Full name Date of birth Address Document number SHARED WITH THE SERVICE Over 18 — yes One answer. Nothing else leaves. The service can verify the proof is genuine without ever seeing your information. Share proof
Zero-knowledge sharing: your data stays locked on the device; the service receives one verifiable answer — nothing else.

What each party ends up holding

What you, the network, and services each hold
Party Holds Never holds
You Everything — your evidence, your keys, your consent history —
The network Encrypted payloads, verification results, consent records Readable documents or biometrics
A service you approve Your verification level and the specific answer you approved Documents, photos, biometric data, unconsented scopes
Everyone else Nothing about you Everything

Want to go deeper?

The technology names every component, and verification levels details what evidence earns each level. Engineers can go straight to the protocol docs.