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

Insights · Rights and consent

Consent as infrastructure

Consent that lives in a policy document is decoration. Consent that lives in the protocol — scoped, purposed, expiring, revocable, auditable — is infrastructure. The difference decides who your data works for.

Identity.org.au editorial · Last updated 3 August 2026

Everyone who uses the internet has performed the ritual: scroll, tick "I agree", continue. What was agreed to, nobody knows — the document was written to be enforceable, not readable, and the choice was fictional because the alternative was exclusion. This is consent as decoration: legally load-bearing, practically meaningless, and structurally incapable of restraining anything, because the system it decorates would work identically without it.

There is another way to build it. Consent becomes infrastructure when it is enforced by the same machinery that moves the data — when a processing request without a valid, matching, unexpired consent does not merely breach a policy but simply does not execute. That is the design standard the VirtEngine consent framework implements, and it changes what consent is.

The anatomy of a real consent

For consent to be enforceable by machinery, it has to be specific enough for machinery to check. In the wallet's framework, every consent is an on-chain record with structure:

  • A scope — the data category it covers: biometric data (veid.biometric), document data (veid.document), basic details (veid.basic), verification history, trust score, and so on. Scopes are consented separately; agreeing to one grants nothing about another.
  • A purpose — stated in the request and shown to you in plain language before you approve. A consent granted for age verification does not authorise marketing analysis.
  • An optional service binding — consent can be granted to one specific service rather than generally, so removing one service's access does not disturb the rest.
  • An expiry — consents can be time-limited and lapse on their own; nothing is forever by default.
  • A revocation path — every grant can be withdrawn at any time, and revocation stops all future processing for that scope.

Auditability closes the loop

Infrastructure-grade consent leaves evidence. Every grant and every revocation is recorded with a timestamp in an auditable history — so "was this processing permitted at that moment?" has a checkable answer, and a dispute is a lookup rather than a memory contest. Your wallet shows you the full history; services see only their own grants. The revoking consent guide walks through what the record looks like from your side.

Honesty requires stating the limits too. Revocation stops future processing; it does not un-ring bells. A service that lawfully received an answer while consent stood keeps that historical answer. And some records — those under legal retention rules — enter a deletion schedule rather than vanishing instantly. Systems that promise instant universal erasure are describing physics that does not exist; what a well-built system promises is that revocation is immediate in effect, recorded in evidence, and honoured in every future request.

A consent you cannot revoke is not consent — it is a signature on a surrender. Revocability is what separates permission from resignation.

Why services should want this

Counterintuitively, infrastructure-grade consent is a gift to honest services. It converts compliance from an interpretive exercise into a protocol property: the service can demonstrate, from records it does not control and cannot alter, exactly what it was permitted to process and when. The rules a verifier signs up to — stated purposes, minimum necessary data, respected revocation — are published in the verifier onboarding path, and they price honest behaviour lower than dishonest behaviour, which is the only kind of rule that reliably holds.

For individuals, the practical experience is the one shown throughout how it works: every request names the asker, the data and the purpose; you approve or decline; approvals expire; and the whole ledger of your decisions is yours to inspect. Consent as infrastructure does not make data sharing rare — it makes it deliberate.

The bigger claim

Data systems inherit the values of their plumbing. When consent is decoration, data flows by default and permission is retrofitted; when consent is infrastructure, permission is the pipe and everything else is a request. Building the second kind is slower and harder, which is why it is rare — and why the constitution of the foundation stewarding this service treats autonomy as a design requirement rather than a settings page.