Evolving Government to Citizen Shared Identity Services

The U.S. Federal Government has spent a considerable amount of time, treasure and energy admiring the problem of shared digital identity infrastructure that can be used by individuals in a privacy respecting manner, while improving cybersecurity and streamlining access to online services and benefits. It is time for it to occupy the room it owns instead of outsourcing solutions to private sector entities who do not have the public interest at heart.

The above graphic provides an easy to understand conceptual breakdown of the various components that make up a shared digital identity infrastructure.

I’ve updated some of the terminology to this decade, but the components and their relationships are taken directly from the U.S. Federal Identity, Credential and Access Management (FICAM) Program’s Trust Framework Solutions (TFS) Component Identity Terminology circa 2013.

Using the TFS terminology that provides separation of concerns and capabilities, the question now becomes who within the U.S. Federal Government is best able to manage and operate these services?

GSA’s Login.gov as the Authentication Provider

In the aftermath of the GSA IG report that “GSA Misled Customers on Login.gov’s Compliance with Digital Identity Standards”, and as I fully expected, there are a set of private sector identity service providers and their champions who have come out with variations of the narrative that “.gov should not be trusted to run a shared identity service” and should instead use their services, or that the “money that is allocated to Login.gov should be taken away” and re-programmed for other uses.

I am, oddly enough, here to make a case for why continued investment in and expansion of the Login.gov program is in the public interest. Odd because, I am on record as being Not-a-Fan of Login.gov’s remote identity proofing implementation because it was and is using data-broker transactional data instead of anything authoritative, and because of their weasel-worded support for NIST 800-63-3 Identity Assurance Levels (IALs).

My perspective on the GSA IG report is that it is a clear demonstration of exactly why .gov should run these types of services — because it demonstrates the independent checks and balances set up within Agencies working … and working well.

Can anyone point me to an example in the private sector where an Organization self-identified the problem, and corrected it with this high degree of transparency and accountability?

So let me stay on brand by noting that it is directly within the competency and capability of GSA and Login.gov to focus on Authentication (AAL) and Federation (FAL) Assurance Level’s and get out of the Identity Assurance Level (IAL) business.

In the near term, the conceptual picture of this could look something like this:

The Agency remains responsible for the remote identity proofing and can use its internal data or other data sources it has access to, in order to accomplish it, but its use of Login.gov as the Authentication provider eases the burdens that are placed on individuals interacting with the Agency’s services, which should be a priority of any Agency!

I am semi-amused to note that this would enable us to catch up, after many long years, to what the Canadian Federal Government have effectively been doing at population scale for a LONG time!

However, this is only the first step, as it is just as important to implement a shared identity validation service that can be utilized by Agencies to mitigate account opening fraud, benefits fraud, and synthetic identity fraud.

Say No to Match/No-Match

While supporting the intent of such services, I also believe that it is a REALLY BAD IDEA to implement these validation services using a “match/no-match” or “yes/no” architecture because it:

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

My linked article goes into the details and closed with a note that with the advances in understanding of the pitfalls of the private sector ecosystem as well as progress that has been made on global technical standards that ensure interoperability, security, privacy and choice, there is another way to implement this capability that can mitigate and/or eliminate the issues noted above.

Future » .gov W3C VC Broker for Authoritative Data Sources

That way is to enable an individual to have agency and control in interacting with authoritative sources that contain information about them, and giving them the capability to obtain and then present that information in a trustworthy and privacy respecting manner to entities they wish to interact with.

This will require the implementation of a shared service W3C Verifiable Credentials Broker Service that acts as the gateway to multiple authoritative sources within the Government. The individual directly interacts with those sources in order to obtain licenses, permits, credentials and attestations that they in turn can use in any online transactions – both with the Government and with the private sector!

The model for this would look like this:

What is important to understand about this model is that the “.gov Shared W3C VC Broker” is not by itself an authoritative issuer, but instead is a gateway/broker/UI implementation that acts as the front-end for multiple, independent authoritative issuers of W3C Verifiable Credentials.

Think that is too far out there?

I don’t believe it is, since I can point you to the multi-vendor, multi-issuer, multi-party interoperability implementation environment that is being operationally tested by the W3C Verifiable Credential and W3C Decentralized Identifier community to see a working example of this model:

What you see above is a gateway/broker that is a very light-weight facade over 6 different credential issuers, that an individual can interact with in order to obtain one or more W3C Verifiable Credentials.

The same approach can serve as a starting point for a .gov service; for a moment, swap out the credentials shown above with credentials that could be generated from the following authoritative data sources:

• Passport Information (State Department)
• Immigration/Employment Eligibility Status (USCIS)
• Tax Records (IRS)
• Social Benefit Eligibility (SSA)
• Birth/Death Records (State Vital Records Agency)
• Driver Eligibility and State Residency (State DMVs)
• Address of Record (USPS)
• …

Also consider that as the individual is directly interacting with the service, receiving a credential, and then they (and not the Government) are using it (as they already do now in the paper world) for a variety of interactions that the Government may not be party to, it is not triggering .gov considerations related to Government use of that data since the Government has no visibility or awareness of the use of that data by the individual i.e. no “phone home” issues!

As an aside, if you were to ask me who should operate such a W3C VC Broker service for the U.S. Government, my answer would be the U.S. Postal Service, for a variety of very good reasons! Hint: If you are a U.S. Citizen, how did you apply for the highest value citizen facing credential issued by the U.S. Federal Government?

Enable individuals, not databrokers!

I am not a believer or supporter of a Government issued identity card, but I do believe that Government has a role in standing behind and vouching for information it is authoritative for, when requested by an individual.

This architectural model provides the ability to do just that, while supporting individual agency, control and consent of the individual regarding their information, and puts digital identity within the U.S. Government on a path that can interoperate with other global jurisdictions.