From Chaos to Compatibility
Consent is dead. How can ecosystems be held to account for personal data rights?
Welcome back! In my first post in this “consent is dead” series, I challenged our core beliefs about digital consent:
We can’t – right now, anyway – force data-hungry companies to ingest data in tiny sips.
We can’t – using today’s methods – prevent identity correlation.
And we can’t empower people by asking them pretty much anything at the point of service.
In the second post, I introduced a new belief that helps us reframe the solutions that will make a difference…
Individuals Have the Right to Determine Their Relationship Status
…and talked about how the Me2B lifecycle model and personal data licensing could help us live up to that belief.
Today, we’re diving into a second new belief that focuses on the “sell side” vs. the “buy side,” as it were.
Permissions About Digital Assets Should Be Interoperable
How can we expect the connected world to treat people’s wishes as first-class objects without interoperability?
If you wanted to map out the interactions of services that give you online experiences and (try to) sell to you, it would look like a gigantic transport schematic map. Actually, we don’t have to imagine it, because LiveRamp has helpfully illustrated the “rails” it operates for feeding marketing systems with personal data.
GDPR doesn’t allow data controllers – services with primary responsibility for personal data usage decisions – to give away their liability for what happens as a result. But these inter-service interactions are a confusing mess and they hide a multitude of data sins, as illustrated in post #1.
Even the European Commission itself, in its recent second report on GDPR results, is calling for more efficiency, consistency, enforcement, and unification to improve access. Meanwhile, various new EU laws, like the Data Act, promote enhanced business data sharing.
To enable better outcomes than the current consent regime has delivered, we need to standardize more of the back-end interactions and artifacts around data rights and user permissions.
What could this look like? It turns out there are several efforts that could be useful to boost near-term outcomes in our existing consent-based ecosystem.
Solution 1: The Consent Name System (CNS)
In the chaos, a business needs to know exactly what data rights it has:
At this moment…
for this purpose…
given the relevant legal jurisdiction(s)…
and the relevant business agreements…
for this person and their individually provided permissions.
It’s a tall order. Luckily, we can look to the Consent Name System (CNS) to help answer exactly these types of questions.
Innovated by an organization called the Privacy Co-op, the CNS is a clever way to get you – as a business stakeholder – a clear and unambiguous answer that you can take to the bank…and to court if necessary.
Solution 2: Consent Receipts
In post #2, I put on my fake-lawyer hat and described the weaknesses of consent as a legal construct. One of its weaknesses is that there’s no official record of what it was the person agreed to, unlike with consent-to-contract and right-to-use licensing (it’s the contract or license itself!).
Luckily, the Kantara Initiative has been working diligently on a standard that can capture what was agreed to, in a group called ANCR: Anchored Notice and Consent Receipts. (More background is here.)
Think of Consent Receipts as the digital equivalent of shopping receipts, documenting the who, what, when, and why of every consent interaction. These receipts can be easily referenced and audited, providing users and organizations with a clear, verifiable record of all consent transactions.
The Financial Data Exchange in 2019 agreed to build on Consent Receipts for its financial industry standards efforts, and Consent Receipts have also been imported into ISO/IEC 27560 – The Consent Record Information Structure.
It’s transparency at its finest – no more “he said, she said” in the realm of digital permissions.
Solution 3: Standardized Do-Not-Sell Signal
If a data processor bears ultimate responsibility for correctness of personal data processing, and it involves tens or hundreds of third parties in that processing, shouldn’t it have some way to tell all those partners when someone’s data is not to be further shared or sold?
Individuals currently can’t make their data step off the train before it traverses the entire railway network. This seems like a significant gap in the ability to enforce GDPR and similar laws.
On the recent Identerati Office Hours session, we discussed an intriguing possibility for standardizing how the network of services could pass along such a signal: the Shared Signals Framework (SSF). A profile of SSF could be just right to enable data processors to send an out-of-band consent on/off signal to data processors and for them to pass it along to other third parties.
It’s long been known that – just like in the railroad world – interoperability standards have an outsized role in making digital identity successful. In exploring the belief that Permissions About Digital Assets Should Be Interoperable, it seems embracing interop for user-centric permissions is not just a noble pursuit – it’s a necessity.
I bet you have more ideas that could help us live up to our privacy and consent ambitions, and hope you’ll share them in the comments. I just heard an idea yesterday coming from my Internet Safety Labs pals about drawing a more aggressive – albeit natural – definitional line around what a data controller is. It’s easy to imagine using all of these ideas in concert to make material improvements to today’s consent landscape.
In the final post, I’ll delve into a third belief that could propel us toward greater success in reimagining digital consent. Stay tuned!