The ET Deep Dive: Five big concerns about credential tracking and privacy

Hi everyone, thanks for coming back to Customer Futures.

Each week I unpack the disruptive shifts around Empowerment Tech, digital wallets, Personal AI and digital customer relationships.

If you haven’t yet signed up, why not subscribe:

Subscribed

Hi folks ??

This is a special extra edition of Customer Futures for you. A deep dive.

Why?

Because lately I’ve been getting more and more specific questions about Empowerment Tech. About commercial models. About user experiences. And about how the tech will work.

I also get questions about the impacts of ET on certain sectors. Like healthcare, travel, banking and government. Other groups ask me about payments. About KYC. And that thorny topic of ‘digital identity’.

And many, many people are keen to know more about the EU Digital ID Wallet. About identity standards and schemes. And what’s really happening on the ground.

So it’s time to dig a little deeper. To peel back the onion on a few ET topics.

So welcome to the first in a series of Empowerment Tech Deep Dives.

Over the next few months, we’ll be sharing guest posts from a number of leading thinkers and experts on specific topics around ET.

This week’s Deep Dive is by Andy Tobin. One of the region’s authorities on the EU Digital Identity Wallet. And he knows his stuff, having helped devise and set up the European Wallet Consortium (EWC), one of the four EU ‘Large Scale Pilots’ for the new ID regulations.

More specifically, he’s an expert on how digital wallets and credentials work, not just what they can do. And he cares deeply about things like privacy. About security. And about user experience.

So this week’s post dives into one of the most important, but hidden, features of digital wallets and verifiable credentials:

Credential revocation.

‘Revocation’ is when a business or government needs to fix an error in some data, or change the status of an entitlement, that’s already been given to an individual.

A number of EU groups are currently wrestling with this exact topic. So what better time to dive into what revocation is, how it works, and what governments are planning to do about it within the EU Digital ID Wallet.

Helpfully, Andy has read the latest eIDAS ‘Architectural Reference Framework’ (ARF) so you don’t have to.

And in today’s special edition newsletter, he takes a detailed look at:

• Europe's transformation opportunity with the digital wallet
• The EU’s ‘Architecture Reference Framework’ - how the wallet will actually work
• The thorny problem of credential revocation
• Five Things To Watch on eIDAS revocation
• What about tracking and profiling?
• Leaving privacy to regulation rather than tech

Health warning: this post is part technical, part regulation goodness. It’s detailed stuff. But critical to ET. If that makes you dizzy, don’t worry, there will be another regular Customer Futures post coming soon.

Ready? Great. Grab that morning brew and a comfy chair.

And Let’s Go.

Europe's transformation opportunity with the digital wallet

In Europe, new legislation mandates that every EU government must provide at least one digital wallet for citizens. And issue into that wallet a "golden credential" - a legally valid digital identity, for any citizen that wants one.

This wallet will also be able to contain credentials about other things. Such as flight tickets, payment cards, employee identification, education credentials and so on.

Not only that, it will also allow a citizen to sign legally binding contracts, such as buying a house, and allow citizens to log into any service that supports it.

Adoption by businesses is mandated in law as well, with any large social platforms or any organisation that relies on regulatory identity verification (like banks, telcos etc.) having to accept transactions from these wallets.

Needless to say, this is a comprehensive programme across the entirety of the EU. With timescales laid down in law (end of 2026 for wallet availability, end of 2027 for businesses to accept them).

The opportunity is to transform Europe's digital economy.

Cumbersome manual processes will be streamlined. Things that have been too costly to digitise due to the burden of fraud or ID verification will become near-zero cost. Triggering a further wave of digitisation.

A common digital ID across 400M people that works the same way in Brussels as in Bratislava will bring huge changes for the better.

And that's before the opportunity for digital ID for organisations, which is also in scope. Cue highly efficient supply chain authentication and an end to fraudulent fake copycat businesses.

As usual, the devil is in the detail.

The EU’s ‘Architecture Reference Framework’ - how the wallet will actually work

The technical specification for how eIDAS works is contained in a document called the Architecture Reference Framework, or "ARF". This document details how everything works, and is being produced by an extremely talented team within the European Commission.

The responsibility of the ARF is to create the technical architecture to deliver the regulatory requirements laid down in the eIDAS legislation. This legislation is particularly strong on the topic of preventing citizens from being tracked and profiled as they use their digital wallets.

In the world of digital credentials, preventing tracking and profiling is a deep and gnarly problem. Understanding it requires knowledge of cryptography and complex data encoding techniques.

And one of the most difficult areas is also the most hidden.

Revoking credentials.

The thorny problem of credential revocation

If you get caught drinking and driving, your driving licence will be revoked. If it's a plastic card, you have to give it back. If it's a digital credential, it needs to be invalidated.

And therein lies a world of pain.

How do you invalidate a digital credential that is in someone else's wallet? In a way that doesn't result in everything they do becoming trackable and correlatable?

This is something that the ARF will need to specify.

So we need to look much more deeply at revocation. Specifically, at Five Big Concerns about how revocation is currently specified.

In this post, we’ll also look forward to what could be an answer.

Want to stay up to date with all things Empowerment Tech? Join over 3000 people signed up to the weekly newsletter:

Subscribed

Five Things To Watch on eIDAS revocation

Version 1.5 of the eIDAS Architecture Reference Framework ("ARF") has been released (link). This is shaping up to be an extremely comprehensive document, and great credit is due to the whole team that is working on it.

But does it contain answers to the key questions around tracking and profiling, now introduced by the need to revoke credentials?

In particular, how do you prevent the tracking and profiling of user activity through the exploitation of revocation metadata? This is deep down in the bowels of digital credential operations, but vitally important to close off loopholes for exploitation and avoid unintended consequences.

I have five concerns that are not yet addressed in the ARF v1.5, which confirms that status lists are still the go-to approach for handling the revocation of issued data. Bear with the terminology, and substitute "credential" or "data" for "attestation" if you want.

1. An attestation issuer could watch the URL of the revocation status list to look for queries, therefore possibly identifying relying parties where a user is using their data.
2. An attestation issuer could watch for queries on the specific status list part of the data about individual people, to track their activities across different relying parties.
3. A relying party (or anyone else who can access the status list URL if it is publicly accessible) could watch the status list daily for changes to known revocation bits belonging to people they know from previous data exchanges. Or they could cache the list daily for future use (e.g. "We see your driving license was revoked 24 months ago - why was that?").
4. A relying party downloading the entire status list is likely getting personally identifiable information (PII) about all those people on that list if a revocation status list bit is deemed to be PII. (should be fun watching the privacy lawyers argue about that!).
5. The revocation status list position (index) of a given attestation allows the relying party to find the relevant entry in the issuer's status list. That index is a unique tracking number shared every time an attestation is shared and allows relying parties or their intermediaries to profile user activity.

It would be good to see these concerns directly addressed in the ARF.

They aren't new. Some "brute force" methods could be used to lessen the impact, such as issuing batches of the same credential to an individual, all with different revocation index positions, but this is highly complex and inefficient at scale.

While there is some important new info in this version, it's also worth recapping the situation as the revocation approach remains largely unchanged.

Of particular interest is the detail in Annex 1 on the topic of revocation checking and how it is currently specified to work, confirming the use of the status list approach:

VCR_01

“A PID Provider, QEAA Provider, PuB-EAA Provider, or Wallet Provider SHALL use one of the following methods for revocation of a PID, QEAA, PuB-EAA, or WUA: Only issue short-lived attestations having a validity period of 24 hours or less, such that revocation will never be necessary, Use an Attestation Status List mechanism specified per VCR_11, or Use an Attestation Revocation List mechanism specified per VCR_11. Note: The 24-hour period originates from ETSI EN 319 411-1 V1.4.1, requirement REV-6.2.4-03A. This requires that the process of revocation must take at most 24 hours. Consequently, revocation may make no sense if the attestation is valid for less than 24 hours, because it may reach the end of its validity period before it is revoked.”

VCR-11

“The Commission SHALL create or reference technical specifications providing all necessary details for PID Providers, Attestation Providers, and Wallet Providers to implement an Attestation Status List mechanism or an Attestation Revocation List mechanism for the PIDs, attestations, and WUAs they issue. These technical specifications SHALL also contain all details necessary for Relying Party Instances, Relying Parties and Wallet Units interacting with other Wallet Units to use these mechanisms to verify the revocation status of PIDs, attestations, and WUAs. Note: 'Attestation Status List' and 'Attestation Revocation List' are specific mechanisms, defined in Annex 1. Attestation Revocation Lists are sometimes referred to as 'Identifier Lists'.”

This confirms the use of status lists to determine if a credential (an "attestation") is revoked or not. More detail is needed to understand how the five concerns I've raised can be addressed or mitigated.

We await the promised technical specifications with keen interest, and it looks like ARF 1.7 should contain further specifications on this.

What about tracking and profiling?

Further useful information can be found in 6.6.3.7 of the ARF:

“To allow revocation checking of a PID or attestation, the PID Provider or Attestation Provider includes revocation information in the PID or attestation, if it is valid for longer than 24 hours. This revocation information includes a URL indicating the location where a Relying Party can obtain a status list or revocation list, and an identifier or index for this specific certificate or attestation within that list.”

“Notes: For attestations with a validity period of less than 24 hours, including revocation information is not necessary.”

“A status list is a bit string or byte string in which each bit or group of bits denotes the current revocation status (valid or revoked) of one attestation. To get the status of the attestation it has received from the Wallet Unit, the Relying Party obtains the status list from the URL specified in the attestation and verifies the value encoded at the bit position given by the index value in the attestation.”

“A revocation list is a list of PID identifiers or attestations identifiers revoked by the PID Provider or Attestation Provider. To get the status of the PID or attestation it has received from the Wallet Unit, the Relying Party obtains the revocation list from the URL specified in the attestation and verifies whether the identifier included in the attestation is on the list or not.”

The current version implies that the five concerns listed above remain unaddressed. This doesn’t mean that they are not being worked on and thought about - absolutely to the contrary.

There is deep and meaningful activity on this right now. And there needs to be as this area is an obvious worry for anyone who values their privacy. The current situation doesn't, in my opinion, meet the requirements laid down in the legislation regarding the prevention of tracking and profiling.

However, the legislation also allows for relying parties who are tracking and/or profiling to be banned from participating in eIDAS i.e. their relying party registration can itself be revoked.?I imagine they could also be fined and sanctioned as an additional deterrent. Therefore it looks as though, at least initially, any technical holes will be plugged by recourse to the law.

This is not the worst thing in the world as a combination of tech+law can be very effective if correctly implemented. It would mean stringent auditing of relying parties and intermediary service providers though.

However, there is sunlight on the horizon! New in v1.5 is a section getting into more detail on the topic of profiling, linkability and tracking.

This is great news. It confirms that the ARF team are taking this topic extremely seriously (I had no doubt, but it's nice to see it in writing).

Leaving privacy to regulation rather than tech

The new section 7.4.3.5 confirms that the ARF team are looking in detail at zero-knowledge-proof (ZKP)-based solutions. While I advocated strongly for ZKPs in the past, the reality is that none of the existing solutions supported cryptographic algorithms permitted by standards bodies NIST and SOG-IS that US and EU governments rely on, so couldn't be used.

Recent developments are moving the game along rapidly.

7.4.3.5 Risks and mitigation measures related to User privacy

Attestation Provider linkability cannot be fully eliminated when using attestation formats based on salted hashes. The only viable mitigation is to adopt Zero-Knowledge Proofs (ZKPs) as a verification mechanism instead of relying on salted-attribute hashes.

However, the integration of ZKPs in the EUDI Wallet ecosystem is still under discussion and development due to the complexity of implementing ZKP solutions in secure hardware and the lack of support in currently available secure hardware (WSCDs). This topic will be further explored in the context of of the next major release od the ARF. As with Relying Party linkability, organizational and enforcement measures can help deter Attestation Providers from colluding and tracking Users.

Additionally, many Attestation Providers are subject to regular audits, making it easier to detect collusion and tracking compared to Relying Parties.

Zero-Knowledge Proof (ZKP) mechanisms for verifying personal information are highly promising and essential for ensuring privacy in various use-case scenarios. They enable Users to prove statements such as "I am over 18" without disclosing any personal data, offering a robust solution for privacy-preserving authentication and verification.

One key area of development is age verification, where the European Commission is actively exploring and testing ZKP-based solutions. The outcomes of this initiative could pave the way for the adoption of ZKPs within the EUDI Wallet ecosystem, further strengthening privacy protections in future implementations.

Now, will new technological ZKP approaches be ready in time for initial eIDAS wallet deployments? I suspect not.

Will it be very expensive for wallet developers and providers of issuer/verifier platforms to adapt? Yes it will.

This will leave a heavy reliance on legislation to prevent tracking.

And it’s going to result in a rather painful re-issuance of credentials - together with upgrades of wallet tech - as it comes to the fore.

I hope you found Andy’s post as interesting and important as I did.

Look out for more deep dives like this coming soon. With experts getting to the heart of big topics across Empowerment Tech. Like commercial models, user experience, and the impacts on different sectors.

Thanks for reading, and for being part of the Customer Futures network.

As ever, it’s all about understanding the future of being a digital customer.

Until next time,

Jamie

And that’s a wrap. Stay tuned for more Customer Futures soon, both here and over at LinkedIn.

And if you’re not yet signed up, why not Subscribe Now.