
I’m thinking out loud here about how to get development rolling for MyTerms. I see three pieces required for a proof of concept:
- Browser plugin
- Web server plugin
- Data storage and retrieval
When we first thought about this at ProjectVRM in the late ’00s, we saw a browser header that looked like this:


The ⊂ and the ⊃ are for the personal and website sides of potential or actual MyTerms agreements. Popdown menus next to both could detail choices or states, including states in which relationships beyond a first MyTerms agreement have been developed. One might even see these as a VRM + CRM dashboard, or a portal into one.
Browser and web server plugins are easy to imagine and develop. Today there are:
- ~112,000 extensions for Chrome (see here and here)
- ~74,000 add-ons for Firefox (see here)
- Doubtless thousands for Safari (all come through the Apple Store, which is not a useful source for that one)
- ~60,000 WordPress and 5400 Code Canyon plugins (see here, here, and here)
Data storage and retrieval are harder. Here is what I have thus far. Please help me (or anyone) improve on it or replace it.
First, adtech “consent strings” described in IAB Europe’s Transparency & Consent Framework (TCF). These seem optimized to capture preferences, store them locally and broadcast them to vendors. They create a “TC String” and record storage/access details, but they are not designed as a mutually signed/identical contract record between the individual and the site, which MyTerms requires. They do, however, provide compact and interoperable encoding and widespread use of tooling. So they at least point in the right direction.
Second, consent receipt / consent record standards:
- Kantara Consent Receipt frames a “receipt” as a record given to the individual, in standard JSON.
- ISO/IEC TS 27560:2023 describes an interoperable information structure for consent records/receipts. This includes support for exchange between systems and giving the individual a record.
- W3C DPV (Data Privacy Vocabulary) is cited in MyTerms (IEEE P7012) and is good for indicating privacy preferences and maintaining records. It also has guidance for implementing ISO 27560 using the DPV.
What we have in the world so far, however, is framed around consent to processing, not reciprocal agreement to contractual terms. We still need bitwise-identical records on both sides. That’s what MyTerms requires.
Third, we might want to create a model that looks like receipt + contersigned agreement artifact + lightweight state token.
For that combination, we might define a canonical MyTerms Agreement Record, or MAR. Note that this is something I just made up. So, rather than taking it with a grain (or a larger measure) of salt, help us by replacing or improving that label, and anything I’m saying here.
Some possible fields:
- Agreement ID (UUID, for Universal Unique IDentifier)
- Parties (site identity + individual agent identity/pseudonymous key) Important: MyTerms should not be dependent on a universal identity system. All that matters is that both parties have a record of agreement with each other. That means all they need to know is how to remember each other. That’s it.
- Terms pointer(s): roster ID + exact version/hash (so “same terms” is provable)
- Context: site origin, date/time, version of a given term agreed to
- Decision: accept / refuse / counter-offer choice (Note that the MyTerms standard is not about negotiation. It’s about choice, and that one is provided by the individual as the first party. At the person’s discretion, they can provide the second party—a site or service—with a first and second choice of agreement, but no more than that.
- Signatures: individual agent and site/agent countersigned signatures.
I think the MAR (or whatever we call it) might be canonical JSON (or CBOR) so both sides can compute the same bytes, then sign the same digest, which I think will make identical records concrete. But I am sure there are other ways.
We can borrow structuring ideas from ISO 27560 / Kantara receipts (timestamps, identifiers, machine readability) while changing semantics from “consent to processing” to “contractual privacy terms” (which still address processing, which is what the GDPR cares most about).
Then, rather than store the MAR in a cookie, store a state token for performance/processing and UX. These can be “myterms_agreement_id,” or “myterms_agreement_hash,” or maybe a status flag, so the browser and the site server can quickly recall state, leaving an authoritative record in each side’s database and turning the likes of ⊂ and ⊃ into meaningful UI elements.
The MAR also needs to record refusals. These might be something like “decision=refuse” or “counter-offer-rejected.” (Note that ignoring a MyTerms signal is a refusal.)
We should also have additional annotations (e.g. reasons for refusal, if the counterparty gives any), and perhaps some kind of signature from the site certifying the refusal.
On the WordPress side, plugins can store MARs in a custom table with records indexed by “agreement_id,” origin, the other party’s pseudonymous key, “terms_hash,” timestamps”… plus “active agreements,” “export/audit trail,” refusals, and other variables, including endpoints for choosing and retrieving the agreement by ID for audits and disputes.
As for where records live, at least on the individual’s side, digital wallets make sense. There are many approaches to wallets today, including the Solid Project‘s pods. (More here.)
As for who productizes any of this, we have—
- Browsers (either as a built-in feature or with a plugin)
- Password managers (which already store structured secrets + metadata, and use both browser extensions and standalone apps)
- “Identity / verifiable credential wallet” vendors (with which “countersigned agreement receipts,” which are forms of credentials)
- Personal data store projects (e.g. Solid pods)
A thought: If we want compliance auditing to have teeth without a regulator in the loop, how about an “append-only transparency log” that is conceptually similar to certificate transparency. So “I agreed / you agreed disputes become easy, and refusal logs can be corroborated without revealing private details, how about—
- Both sides submit the agreement hash (not the full agreement) to a public/neutral log. (Possibly a blockchain. I add that to attract developers who are fond of those.)
- The log returns a proof.
I am sure experts in ODR (online dispute resolution), a well-developed field, will want to weigh in here.
That’s all I have for now. I’ll add more (and perhaps subtract some as well) as folks respond to what I have so far. Thanks.
Bonus links:



