Not better identity

By ANIL JOHN on 07 January, 2023 | Permalink

I no longer believe that match/no-match data validation services are the way to implement a public sector identity validation capability for use by the private sector.

Before I get into why I have changed my mind on how such a service should be implemented, it is important to note that I continue to believe that an identity validation service is a vital component of identity proofing, and has a critical role to play in mitigating account opening fraud, benefits fraud, and synthetic identity fraud.

The need for public sector identity validation services

Given the role that the public sector plays in the establishment of identity, I fully believe that the public sector should implement secure, privacy-respecting identity validation services that can be used by individuals in the private sector. This allows individuals, when participating in high value transactions that require proof of identity or benefit eligibility, to convey information about themselves in a manner that is vouched for by the Government.

Given the state of the technology at that time, and my understanding of the broader identity ecosystem, I also believed that the way to implement Identity Validation as a Public Sector Digital Service was to implement a match/no-match API, and had even thought about implementing Privacy Preserving Attribute Validation using XACML.

As you can see by the links above, I have been very vocal and public about the need for such services for a long time (as far back as 2011), and about how the public sector should implement this capability. In fact, in my prior job as the Technical Lead for the U.S. Government’s Federal Identity, Credential and Access Management (FICAM) Program, I actively advocated for this capability.

So, I was very gratified when the White House OMB finally released its M-19-17 Memo on “Enabling Mission Delivery through Improved Identity, Credential, and Access Management (PDF)” that contained the following directive to USG Agencies:

Agencies that are authoritative sources for attributes (e.g., SSN) utilized in identity proofing events, as selected by OMB and permissible by law, shall establish privacy enhanced data validation APIs for public and private sector identity proofing services to consume, providing a mechanism to improve the assurance of digital identity verification transactions based on consumer consent.
Enabling Mission Delivery through Improved Identity, Credential, and Access Management

However, I am very clear in my public writings and posts that “… as I interact with the community at large, and learn more about various topics, my thoughts and opinions are subject to change.” And that is exactly what happened!

What did I learn that changed my mind?

I learned more about the consequence of organizations implementing programs and services without considering its impact on individuals
I learned more about the consequences of organizations that are so focused on their specific business objectives that they refuse to look at the unhealthy market power dynamics that their actions and inaction encourage and enable
I learned more about the power and influence of platforms and technology vendors who seek to make themselves gatekeepers between government and its customers
I learned more about new technologies that can provide identity validation capabilities, while ensuring that individuals are at the center of the solution with awareness and control over what is happening with their data

This resulted in a re-examination of the of the match / no-match approach, and the conclusion that I came to is that a match/no-match data validation API that is fronting authoritative public sector sources:

Implements a “phone home” capability that can be abused
Limits the ability to collect informed consent from an individual about the use of their data
Can be abused by data brokers to enhance their targeting, profiling and segmentation of individuals

1. Implements a “phone home” capability that can be abused

In order to validate information, it requires a Relying Party (Verifier, Website, Organization) to call the match / no-match API, which then has real-time visibility into where that request is coming from. And if the service is malicious, curious, or lazy, that information will be stored and can be used to correlate activity of a specific person across space and time.

This service is designed to be an Application Programming Interface (API) that is used by the entity or organization seeking to validate the information of an individual and is not used directly by the individual. Every single one of these implementations that I’ve seen, when asked about how consent is implemented, defaults to some variation of “We got an attribute in the request from the Relying Party that said that the individual’s consent was provided.”

Folks, this is not the informed, knowing consent given by an individual but instead is the current we-got-consent-dance used by entities under various guises including “It was in our 20-page Terms of Service, that nobody read, that they clicked thru” or “Because they are using our service, they have given us ‘implicit consent’, so we are good to go!”.

Needless to say, an RP can also simply lie and the service would have no way of independently verifying if the consent truly was given!

3. Can be abused by data brokers to enhance their targeting, profiling and segmentation of individuals

If you look into the various lobbying groups that are all in on this, you will find a clear intersection between their membership and the data broker community. And the reason is very simple to understand.

Data brokers, without our knowledge and permission, ingest the transaction exhaust of our online lives and use analytics to triangulate on who we are, and then segment and profile our likes, dislikes, and behaviors and sell those insights as predictions of our future behavior.

By gaining access to an identity validation service they can query, they no longer have to triangulate digital exhaust to determine who we are – they can be assured of it! And given that assurance, they can then build even more detailed profiles of us and sell them to the entities that pay them!

Another way

The good thing about the current timeframe is that we finally have new approaches and standards that will allow an individual to be the entity that interacts with an identity validation service. They can then choose to share that information with relying parties with the full confidence that the public sector authoritative source of that data is standing behind them vouching for their information.

I believe that a public sector identity validation service should be implemented using standardized APIs an individual can interact with, to obtain their personal information as W3C Verifiable Credentials into their own digital wallet, which they can choose to use in their online interactions to obtain services and benefits.

What is different and important about this approach is that the individual is fully in the transaction flow, is aware of who is asking for what, and can selectively disclose the information at their discretion to obtain benefits or services. And the service provider they are interacting with can be assured that the information is being vouched for by an authoritative public sector entity with the full, informed consent of the person they are interacting with.

newRecently: Signal and noise

Why Signal won’t compromise on encryption - “Signal doesn’t just encrypt the message content. It is encrypting metadata. It did something which I consider fairly revolutionary with its new groups, methods, and infrastructure, which was figure out a way to prevent Signal from knowing who is in a group and who’s talking to whom. These things are huge, true, kind of scientific innovations that are also innovations in privacy, which is Signal trying as hard as we can to collect as little information about you, about who you talk to, as little meaningful information about what people are saying, who they’re saying it to, and who is using our service … “
The Signal App and the Danger of Privacy at All Costs - “What’s more, the company’s proposition that if anyone has access to data, then many unauthorized people probably will have access to that data is false. […] Small groups of technologists are developing and deploying applications of their technologies for explicitly ideological reasons, with those ideologies baked into the technologies. To use those technologies is to use a tool that comes with an ethical or political bent.”
Privacy Is OK - “So, let’s agree that Signal offers an upside and a downside. Up: Your privacy is protected from snoopers, be they maleficent governments or ordinary criminals. Down: It’s hard to wiretap the bad guys. So, can we remove the downside without doing damage? […] I’m sorry to be the bearer of bad news, but it’s simply not possible to address the downside without completely shattering the upside. Here are three reasons why.”
Meredith Whittaker (President of Signal) on the NYT op-ed - “OK let’s talk about That Op-ed. The one that insisted not only that privacy is dangerous, but that not affirmatively building surveillance into communication tools is a radical ideological position. […] The op-ed functions to create the appearance of a “debate” on a more or less settled issue. And this is a powerful function, bolstered by its placement in the NYT. Through this, it can serve as a “Potemkin citation,” providing a seemingly credible reference in support of bad privacy laws and platforms.”
Back into the Trenches of the Crypto Wars - “We built (Signal) from the ground up in a way that preserves privacy. Sitting here in the wake of data breach after data breach, terms of service change after terms of service change, I’m confident in saying that building systems that work to not collect data, like Signal, is the only meaningful way to protect privacy.”

cyberLinks: random and relevant

Demystifying DMARC - A guide to preventing email spoofing - “DMARC can stop spoofed spam and phishing from reaching you and your customers, protecting your information security and your brand. However, complexity and misconceptions deter many organizations from ever deploying it. Part mythbusting, part implementation guide, this post explains the shortcomings of SPF and DKIM, what DMARC is, how to deploy DMARC properly, and how to respond to DMARC reports – all without the need for an additional vendor, thanks to open source software!”
Open source DMARC report analyzer and visualizer - “parsedmarc is a Python module and CLI utility for parsing DMARC reports. When used with Elasticsearch and Kibana (or Splunk), it works as a self-hosted open source alternative to commercial DMARC report processing services such as Agari Brand Protection, Dmarcian, OnDMARC, ProofPoint Email Fraud Defense, and Valimail.”
Google Admin Toolbox Check MX - “Check MX is an easy to use DNS validation tool that looks for common MX record misconfigurations”
Google Admin Toolbox Dig - “Dig can be used as a web-based equivalent of the Unix dig command”