The phrase "own your data" has been repeated so many times across policy white papers, startup pitch decks and privacy legislation that it has nearly lost meaning. In 2026, the core problem remains: nobody has defined what ownership requires at the technical layer. Consent toggles are not ownership. Portability APIs are not ownership. Even deletion rights, as robust as GDPR Article 17 attempts to make them, are not ownership.
Ownership, in any meaningful legal or economic sense, begins at origination. The entity that originates an asset controls its provenance, its lineage and its downstream derivations. The Personal Data Asset Origination System, or PDAOS, is the architectural answer to that premise. Dr. Patrick Fisher developed the PDAOS framework through Own Your Data Inc as the technical backbone of the MyDataKey initiative and as the engineering companion to The Invisible Data, Volume 6 of The Invisible Series.
This article breaks down the PDAOS model in technical terms, positions it against the four most influential competing frameworks and explains why origination control is the necessary precondition for digital sovereignty.
Why Access Control Is Not Ownership
Most privacy architectures today are access-control architectures. They ask: who is permitted to read this data, and for how long? OAuth 2.0, as defined in RFC 6749, is the canonical example. A user grants a token. A platform receives scoped permissions. The user can revoke the token. The data, at this point, already lives on the platform's infrastructure.
Revoking a token does not delete derived models. It does not eliminate behavioral profiles built from historical interactions. It does not touch the embeddings trained on a user's language patterns inside a large language model. Access control manages the door. It does not determine who built the house.
Origination control is structurally different. It means the data asset is created, signed and anchored by the individual before it enters any platform pipeline. The individual holds the cryptographic proof of creation. Every downstream use is a derivative of an asset whose provenance chain begins with the individual's key material. This is the distinction the PDAOS framework is built on.
The PDAOS Model: Origination as the Unit of Sovereignty
PDAOS defines a personal data asset as a structured, signed, timestamped data object whose origination event is cryptographically anchored to an identity controlled by the individual. Three technical commitments follow from that definition.
First: identity-bound provenance. Every data asset carries a provenance record that references a Decentralized Identifier (DID) conforming to the W3C DID Core specification. The DID is controlled by the individual, not by the platform receiving the data. Provenance is not a metadata tag appended by a platform. It is a cryptographic commitment made at the moment the asset is created.
Second: consent receipts as first-class objects. PDAOS treats consent as a machine-readable artifact that travels with the data, not as a checkbox event logged in a platform's database. The Kantara Initiative's Consent Receipt specification provides the schema baseline. Each consent receipt references the originating DID, the data asset identifier and the explicit purpose binding. When purpose changes, the consent receipt is invalidated and the asset must be re-released under a new consent event.
Third: derivation tracking. Any model, score, profile or inference derived from a PDAOS-originated asset inherits a provenance reference to the source asset. This is technically demanding. It requires platforms consuming PDAOS assets to implement derivation logging. But it is the only mechanism that closes the gap between "I own my raw data" and "I own the economic value extracted from my data."
Competing Frameworks: Property, Labor, Trusts, and Fiduciaries
Four frameworks have dominated academic and policy discourse around personal data rights. Each captures something real. Each also fails at the technical layer in a specific way. Understanding those failures explains why PDAOS takes the approach it does.
Data-as-property draws on Lockean labor theory: you create it, you own it. The legal problem is that property law as currently codified in most jurisdictions does not extend to data. The EU's Data Act, in force as of 2026, grants data access rights but explicitly stops short of recognizing data as personal property. Even if property rights were extended to data, property frameworks do not naturally handle non-rivalrous goods. Two people can hold the same dataset without either diminishing the other's copy. Classical property theory has no clean answer to this.
Data trusts propose that individuals pool their data under a trustee organization that negotiates access conditions on their behalf. The ODI has published extensively on data trust models. The accountability mechanism is real. The limitation is equally real: the individual transfers assets into a trust and loses direct custody. Sovereignty is delegated, not exercised. For many use cases, especially public-interest data sharing, trusts are the right tool. For individual digital sovereignty, they replicate the custodial problem at a different organizational level.
Data-as-Labor and the Weyl-Lanier Critique
The most intellectually provocative challenge to property-based frameworks comes from economist E. Glen Weyl and technologist Jaron Lanier, whose work argues for treating personal data as labor. Under their model, individuals are data workers whose continuous behavioral contributions to AI training pipelines constitute compensable work. Platforms should pay data dividends, much as streaming platforms pay micro-royalties.
The data-as-labor model correctly identifies the economic asymmetry. It correctly frames the individual as a producer, not just a consumer of digital services. Where it is technically incomplete is in the infrastructure it assumes. Labor compensation requires measurement. Measurement requires provenance. Provenance requires origination control. You cannot calculate a data dividend for a behavioral signal if that signal has no cryptographic lineage connecting it to the individual who produced it.
PDAOS does not contradict the data-as-labor economic argument. It provides the technical substrate that labor compensation would require to function. Without origination control at the asset layer, data-as-labor remains a compelling policy argument with no enforcement mechanism.
Lanier's framing, developed in "Who Owns the Future" and extended in subsequent work, also raises the ghost economy problem: most of the economic value of AI systems today is extracted from data whose original contributors receive nothing and cannot even identify themselves as contributors. PDAOS addresses this through the derivation tracking commitment described above. It does not fully solve the ghost economy problem in legacy systems. It does establish the architecture that prevents the problem from propagating into new systems.
Cryptographic Origination: How DIDs and Verifiable Credentials Enable PDAOS
The W3C Decentralized Identifier specification and the Verifiable Credentials Data Model together provide the cryptographic primitives that PDAOS requires. A DID is a URI that resolves to a DID Document containing public key material. The individual controls the corresponding private key. Anything signed with that key material carries a provenance trail back to that DID.
A PDAOS data asset is, at its core, a Verifiable Credential where the subject and the issuer are the same DID. The individual self-issues the asset, signs it with their key and presents it to platforms as a credential rather than as raw data. The platform receives a structured, verifiable artifact rather than unstructured data it can freely copy and repurpose.
Zero-knowledge proof constructions, particularly those following the BBS+ signature scheme now integrated into the W3C VC Data Integrity specification, allow selective disclosure. An individual can prove a property of their data (age above a threshold, income within a range, health status for a specific purpose) without revealing the underlying data value. This is not a theoretical capability in 2026. It is a deployable feature of the current VC ecosystem.
The IETF's ongoing work on Privacy Pass (RFC 9576 and associated documents) and the OpenID Foundation's work on the OpenID4VC profile provide the transport-layer standards that allow PDAOS credentials to move through existing web infrastructure. PDAOS is not proposing a parallel internet. It is proposing a provenance layer on top of existing infrastructure that shifts where origination is recorded.
Data Fiduciaries and Where PDAOS Diverges
Jack Balkin's data fiduciary model argues that platforms handling personal data should be held to fiduciary standards of loyalty and care, analogous to the duties owed by lawyers or doctors to their clients. The EU's AI Act and Digital Services Act both incorporate fiduciary-adjacent language around high-risk processors. India's Digital Personal Data Protection Act references similar duties.
The fiduciary model is a governance and liability framework. It does not specify how data assets are structured, signed or tracked at the technical layer. A platform can be held to fiduciary duties and still maintain the custodial architecture where all data lives in the platform's infrastructure and is only accessible to the individual through the platform's interface.
PDAOS is not opposed to fiduciary regulation. It operates at a different layer. Fiduciary duties constrain what a platform can do with data it holds. PDAOS determines the conditions under which data enters the platform at all. Both are necessary. A fiduciary duty without origination control leaves the individual dependent on the platform's good faith and legal liability. Origination control without fiduciary duties leaves the individual technically sovereign but without institutional accountability for platform behavior.
The cleanest implementation of digital sovereignty combines both: PDAOS at the data layer and fiduciary obligations at the institutional layer. Dr. Fisher's framing in The Invisible Data describes this as the difference between architectural rights and legal rights. You need both to have real rights.
Implementation Architecture: What a PDAOS Stack Actually Looks Like
For engineers building systems toward PDAOS compliance in 2026, the stack has four layers.
Layer 1: Identity infrastructure. The individual needs a DID with key management. The DID method matters. DID:web is operationally simple but requires trusting a DNS-resolvable domain. DID:key is fully self-sovereign but does not support key rotation. DID:ion (anchored on Bitcoin) and DID:cheqd (anchored on a purpose-built identity chain) provide rotation support with decentralized resolution. The choice depends on the threat model and recovery requirements of the deployment.
Layer 2: Asset creation and signing. Raw data objects are structured into Verifiable Credentials using the W3C data model. Each credential includes a credentialSubject block containing the data payload, a proof block containing the individual's cryptographic signature and an issuanceDate that establishes the origination timestamp. The NIST Privacy Framework's data minimization principle applies here: credentials should be scoped to the minimum data required for the declared purpose.
Layer 3: Consent receipt issuance. When an individual releases a PDAOS asset to a platform, the release event generates a consent receipt following the Kantara schema. The receipt is signed by both parties, creating a bilateral record. The receipt specifies the data asset identifier, the purpose, the retention period and the derivation policy. Platforms must store this receipt and reference it in any downstream data processing.
Layer 4: Derivation registry. This is the hardest layer to implement at scale. Any inference, model weight update, aggregate statistic or behavioral profile derived from PDAOS-originated assets must reference the originating asset identifiers in a derivation log. Privacy-preserving approaches using differential privacy (as specified in NIST SP 800-226) can satisfy this requirement without exposing individual asset contents in the registry. The registry does not need to be a blockchain. It needs to be auditable and tamper-evident. A merkle-tree-structured log with periodic public commitments is sufficient for most deployments.
The MyDataKey implementation, developed by Own Your Data Inc, provides a reference architecture for Layers 1 through 3. Layer 4 remains an active engineering challenge and an open research area that Own Your Data Inc is addressing in ongoing technical work.
Digital sovereignty is not a policy aspiration. It is an engineering requirement. The question is not whether individuals should own their data. The question is whether the technical infrastructure exists to make that ownership meaningful at the moment of data creation. PDAOS answers that question with a specific architecture, a specific set of standards and a specific claim: that ownership begins at origination or it does not begin at all.