{"id":875,"date":"2026-05-05T21:28:08","date_gmt":"2026-05-05T21:28:08","guid":{"rendered":"https:\/\/ont.io\/news\/?p=875"},"modified":"2026-05-05T21:28:11","modified_gmt":"2026-05-05T21:28:11","slug":"from-ownership-to-consent-audit-and-revocation","status":"publish","type":"post","link":"https:\/\/ont.io\/news\/from-ownership-to-consent-audit-and-revocation\/","title":{"rendered":"From ownership to consent, audit and revocation"},"content":{"rendered":"\n

On the recent Ontology Privacy Hour<\/a>, buried inside Nick Ris\u2019s response to a question about why people want privacy at all, was the line that quietly recasts the whole conversation. \u201cWe talk a lot about data ownership,\u201d he said, \u201cand I think that\u2019s the wrong lens to look at this. It\u2019s not necessarily about owning the data. It\u2019s about consenting to its use. It\u2019s about auditing where it\u2019s being used. Frankly, it\u2019s about revoking permission to its use.\u201d<\/p>\n\n\n\n

That sentence pivots the entire argument. The data ownership conversation has been running for at least two decades, and it has produced very little in the way of working primitives. People still cannot meaningfully say where their data has gone, who is using it now, or how to call it back. The reason is not a lack of effort. It is that the underlying metaphor is wrong.<\/p>\n\n\n\n

This is the fourth in our series expanding on themes from the Privacy Hour. The pillar promised a follow-up on each section. The previous piece argued the bucket model of data security is finished, and that the answer is to distribute data and bind it to the entity authorised to use it. This piece picks up the question that immediately follows: once the bucket is gone, what is the right vocabulary for individual control over personal data? Nick\u2019s answer, and ours, is consent, audit, and revocation.<\/p>\n\n\n\n

Why ownership is the wrong frame<\/h2>\n\n\n\n

Ownership is borrowed from physical property. A chair has one custodian. If two people both want it, the chair has to be in two places at once, which it cannot. Possession and control sit together. Ownership of a chair is roughly synonymous with the right to keep it, sell it, lend it, or destroy it.<\/p>\n\n\n\n

Data does not work that way. It is non-rival, infinitely copyable, and almost always derivative. The personal data that an organisation holds about you is rarely a clean record you handed over. It is a synthesis of what you typed, what you clicked, what your phone reported, and what was inferred about you by a model. Asking who owns this is the wrong question. The answer is normally that several parties have produced it together, that there are dozens of copies and derivatives, and that none of them maps to the single-custodian model the word ownership implies.<\/p>\n\n\n\n

What people actually want, when they say they want to own their data, is something more practical. They want to know who is using it. They want to be able to say no, in advance and with consequence. And they want to be able to change their mind, with effect. Those three behaviours are consent, audit, and revocation. They are operations, not assets.<\/p>\n\n\n\n

Consent that actually means something<\/h2>\n\n\n\n

The legal definition of consent in the UK and EU has been consistent for years. Consent must be freely given, specific, informed, unambiguous, and as easy to withdraw as it is to give. The UK\u00a0Information Commissioner\u2019s Office<\/a>\u00a0is explicit on each of those points, and the European Data Protection Board\u2019s consent guidelines<\/a>\u00a0reinforce them across the bloc.<\/p>\n\n\n\n

In practice, almost none of the consent flows people meet on a daily basis pass that bar. Cookie banners default to acceptance. Terms of service bundle a hundred decisions into a single click. Withdrawal requires emailing a generic mailbox and waiting on goodwill. The legal definition is right; the implementation surface is broken.<\/p>\n\n\n\n

What is missing is a primitive: a way to grant a specific, scoped, time-bounded permission to a specific party for a specific purpose, in a form that both sides can verify and the holder can revoke. The W3C Verifiable Credentials Data Model<\/a> and the Decentralised Identifiers specification<\/a> provide most of those properties already. A verifiable credential carries a signed, narrowly scoped claim. A decentralised identifier lets the holder present it without a platform sitting in the middle. A consent record built on those primitives is granular by default, not by user diligence.<\/p>\n\n\n\n

Audit, in a form the subject can actually use<\/h2>\n\n\n\n

Today\u2019s audit story is mostly internal. Organisations write logs; regulators ask for them on the way in; the data subject hears about a breach through a notification email weeks after the fact. Accountability is asserted by the controller and trusted by everyone downstream.<\/p>\n\n\n\n

The ICO\u2019s Accountability Framework<\/a> is clear that organisations must be able to demonstrate compliance, not just claim it. The frame is correct. The mechanism, in most organisations, is documents and policies, not a usable record the data subject can interrogate themselves.<\/p>\n\n\n\n

What is needed is the inverse: a verifiable trail of permissioned access events that the subject can read directly. Every time a credential is presented, every time consent is granted or expires, every time a derived dataset is produced, the event is signed and recorded against the holder\u2019s identifier. The records do not need to live on a public chain in plaintext. They need to be cryptographically verifiable, append only, and queryable by the holder. That is a tractable engineering problem on top of decentralised identity rails. It is an unsolvable problem on top of trust the controller\u2019s database.<\/p>\n\n\n\n

Revocation that actually sticks<\/h2>\n\n\n\n

The right to erasure under UK GDPR Article 17<\/a> is well established as a legal right. It is much harder to enforce as a technical operation. By the time a subject asks for their data to be removed, it has typically been replicated to a warehouse, joined to a derived table, and used to train a model. Deleting the original record is necessary; it is rarely sufficient.<\/p>\n\n\n\n

The credential layer offers a partial but meaningful answer. The W3C\u2019s Bitstring Status List<\/a> specification defines a privacy-preserving way for an issuer or holder to mark a credential as revoked or suspended, such that any future verification fails. Combined with time-bound consent and signed access logs, this shifts the burden. Instead of relying on a controller to run a deletion job inside their own infrastructure, every system that wants to use the data has to first check the status of the permission that authorised it. Revocation propagates by design.<\/p>\n\n\n\n

This does not unwind a model that has already trained on the data, and the piece should not pretend otherwise. It does change the default for every future use, which is where most of the harm sits. A revocation that is enforced for the next ten years of inference is not nothing.<\/p>\n\n\n\n

The architecture this slots into<\/h2>\n\n\n\n

The previous piece in this series argued for distributing data away from concentrated honeypots and binding each piece to the authorised principal. Consent, audit, and revocation are the operations that make those bindings live, rather than ornamental. Without them, distribution is structural. With them, it is behavioural.<\/p>\n\n\n\n

This is the architecture Ontology has been building toward. ONT ID provides the decentralised identifiers and credential infrastructure that the consent, audit, and revocation primitives sit on top of. ONTO Wallet is where the holder actually exercises them: granting a scoped permission to a specific counterparty, watching the audit trail of subsequent access events, and revoking when the relationship changes. The protocol surface is independent of any single platform, which is the point. If the wallet a person uses for consent is also the largest holder of their data, the model collapses back into the bucket it was meant to replace.<\/p>\n\n\n\n

The conversation regulators are starting to have<\/h2>\n\n\n\n

The European Union\u2019s Digital Identity Wallet programme<\/a>, legislated under eIDAS 2, is built around exactly these primitives. Citizens hold credentials; relying parties verify; the wallet is the locus of consent. ENISA\u2019s work on self-sovereign identity<\/a> describes the same shape from a security perspective. The vocabulary of ownership is quietly being retired across these documents in favour of control, consent, and verifiable status.<\/p>\n\n\n\n

This is not a coincidence and it is not a marketing trend. It is what happens when a class of problem is studied long enough that the metaphors get rebuilt. The open question is which infrastructure providers are ready to ship the primitives the new vocabulary requires.<\/p>\n\n\n\n

Where this goes<\/h2>\n\n\n\n

Once consent, audit, and revocation are real operations on real identifiers, a second question follows immediately. What is the data actually worth? The answer turns out not to live in the bytes. It lives in who attributed them, how they were produced, and what other signals corroborate them.<\/p>\n\n\n\n

The next piece in this series picks up that thread, the Bloomberg Signal: attribution as the asset. Concentrated data was valuable because it was scarce and hard to replicate. In a network where the bytes are commodity but the provenance is not, the value moves to the credentials that attest to it. That is the same primitive set, used to build a market.<\/p>\n\n\n\n

This article is part of a series expanding on themes from the Ontology Privacy Hour: Privacy, Data and the Future of AI Data<\/a>. Watch the full episode on YouTube<\/a>.<\/p>\n\n\n\n

\ufeff<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

On the recent Ontology Privacy Hour, buried inside Nick Ris\u2019s response to a question about why people want privacy at all, was the line that quietly recasts the whole conversation. \u201cWe talk a lot about data ownership,\u201d he said, \u201cand I think that\u2019s the wrong lens to look at this. It\u2019s not necessarily about owning the<\/p>\n","protected":false},"author":5,"featured_media":876,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[113,13],"tags":[28,44,67,72,116,117,164,165,166,167,168,169],"class_list":["post-875","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data","category-did-and-privacy","tag-self-sovereign-identity","tag-onto-wallet","tag-ont-id","tag-verifiable-credentials","tag-data-ownership","tag-decentralised-identity","tag-consent","tag-audit","tag-revocation","tag-uk-gdpr","tag-eidas-2","tag-ontology-privacy-hour"],"_links":{"self":[{"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/posts\/875","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/comments?post=875"}],"version-history":[{"count":1,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/posts\/875\/revisions"}],"predecessor-version":[{"id":877,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/posts\/875\/revisions\/877"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/media\/876"}],"wp:attachment":[{"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/media?parent=875"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/categories?post=875"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ont.io\/news\/wp-json\/wp\/v2\/tags?post=875"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}