Uniting Login & Wallet Ecosystems for Trusted Digital Government (eGov) and Trusted Digital ID

Verifiable Digital Credentials (VDC) like mDL are rolling out, Wallets are being deployed. Simultaneously, global Governments are deploying eGov Login systems. Can these work together? Does trust combine across them?

If you do not have a paid Medium account, use this link.

Please note that VDC includes mDL, EU PID, Mobile ID, mdoc, & W3C VCs. Digital Identity refers to the login account. Digital ID refers to wallet creds.

This article expands on Trust Management to combine Federation & Wallet architectures into a single Ecosystem with common Trust Conventions.

Business Across Contexts

Meet your Customer where they want to see You

People doing business with commercial entities or engaging with their government expect to be the same person and have access to their same accounts and services across contexts: in-person transactions, web interactive, mobile app-based instant access and purchase.

The companies that do this well are providing a level of service that inspires loyalty because it makes it simpler for customers to do something as soon as they think about it and to fit transactional business into life. Accomplishing a partial interaction to complete later in a different context helps the user.

An Example of Cross-Context Service

I’ll use the example of Amazon with Whole Foods. While cooking, with hands too dirty to write, I tell Alexa to add shopping items to my list. Then when I’m disengaged from a work video conference (no, no, rarely) or multitasking, I can search each item to add to my cart using the big screen at my desk. At night watching TV, I complete my cart on my iPad, check out and schedule a pickup time for the next morning. Grab my app to tell Whole Foods I’m on my way, click the app when I arrive, and they meet me in the parking lot with filled bags. If I’ve forgotten anything, I can run in, grab it, scan at self-checkout, hover my palm above the reader (on which I bet I could tap mDL) and it’s added to my card-on-file and receipts list.

PS: For my price sensitivity and feeding teenage boys, there’s still Costco. :)

Whole Foods / Amazon met me where I already am, including my health and price sensitivities, and consequently have earned more of my wallet than expected. What makes this work? Across contexts I am still in control.

Wallets Next to eGov Login for Cross-Context Service Delivery

As we gravitate with momentum to Digital Wallets, why would the expectation of the delivery of Government Service be any different? Or the delivery of commercial services where a government ID is required? Government Digital ID increases convenience and privacy/control for the user. This can be true across the deployment and service delivery contexts.

My question is whether the wallet gets pulled into convenient workflows or the convenient workflow platforms pull VDCs — connected or derived from mDL and its global counterparts — into their platforms? We shall see.

You can mix Open ID Login accounts with Wallet apps from the same Government Issuer for max flexibility

I believe you will see the delivery of cross-context government service in two channels and three models:

• In-app Delivery of government services when the app is published by the government entity (e.g., renew my Driver’s License in my mID app). In these instances, eGov Login can be used to access the mID app.
• Web Delivery of government services for Residents facilitated by high-assurance User Authentication from an Open ID (e.g., SPiD in Italy)
• Web Delivery of government services for Visitors who present their Digital ID (from their own government) using a Wallet (e.g., 18013–7)

Henceforth in this article, I’ll refer to Wallet = State Wallet = Mobile ID app

In the Government Identity and Digital ID Space

In many instances of US State Governments, different agencies have responsibility for physical cards versus online identity login. These siloes are breaking. The State CIO (who may own state-wide identity/login) and the State DMV (who owns identity proofing responsibility) should work together to ensure that wallet credentials and login accounts operate at the same level of assurance AND prevent tracking user’s private transactions.

California’s Digital ID Framework pulls together numerous State Agencies to collaborate on cross-context service delivery while keeping strict adherence with California Privacy Law (CCPA amended by CPRA). Pulling together these technologies gives users better control, allows cross-context interactions, and unifies the protection of privacy rights. It’s just simpler for end-users also because they expect login to work with credentials.

What the Wallet + Login Model Looks Like

The Government Issuer, along with their counterpart Government Agency that owns login digital identity, can deploy a paired

Combined Government Login Provider under same umbrella as Government Wallet Connector & Wallet

Deployed as pictured above, the Wallet and the Login account work together. The End-User has control over what they share across contexts and their consent grants are consistent across web and in-person contexts in which they present ID. If the eGov Login Provider is granted access to the attribute store of the ID Issuer, ID data can be released as OIDC Claims.

Functionality Unlocked By This Model

• The Wallet/mID app uses the eGov Login account to Unlock the Wallet and as part of the Initial Identity Verification for provisioning the mDL/VDC into the app (followed by biometrics)
• 2FA, Second Factor Authentication using the Wallet rather than redirectable SMS. Better than 2FA, a Fido Passkey usable across contexts - Web and mobile Wallet (and 3rd party sites)
• (Don’t forget, the above Passkey is “proof of proven ID” without data)
• State-Agency Websites accept the eGov Login when providing services to State residents, permitting SSO across agencies as convenience
• Proofed Attributes through the IDP Claims, including signed JWT aligned with ISO/IEC 18013–5:2021 data model
• Receipts and Consent Logs in the Wallet allow Residents to Manage All Their State Services and revoke consent or fix data quality
• Multiple State Agency Credentials in the State Wallet utilizing the same login-to-start provisioning credentials at the Wallet Connector UI
• State-Agency Websites accept Wallet Credentials as a form-fill and application for services when the Wallet user is not a State Resident (e.g., I apply for my new ID or a temp visa with my current State Wallet)

For Commercial Verifiers (Relying Parties)

The key fact for the deployment of the Government Wallet + Login Model is that credentials from the wallet are cryptographically signed by the Issuer. In addition, with a proper deployment, Claims released by the eGov Open ID Provider (IDP or OP) can also be cryptographically signed and verified by the same root IACA public key (see ISO/IEC 18013–5:2021 OIDC flows). This verification can happen even if the wallet doesn’t OIDC data retrieval.

Login services with Attributes/Claims with Presentation from the Wallet apps

Remember, the Relying Party deploying cross-context services is the beneficiary of combining Wallet + Login Models. While this primarily enhances Government Services delivery, there are numerous Commercial entities that deliver services where a Government ID is required, by law, policy, or regulation. That requirement comes through the signature.

Let’s look at how Commercial Relying Parties could implement their acceptance of Government Digital ID in these Wallet + Login States.

Presentation of Digital ID from Wallet

When a User is logged into the RP website with the existing Commercial RP’s chosen IDP (their own or 3rd party), the User can be presented with an ISO/IEC 18013–7 QR Code to initiate a request for Digital ID from the Wallet. The Wallet application scans the QR and initiates the request-response of the requested identity attributes pushed directly to the RP web services from the wallet.

Demonstration of the QR Code read by Wallets to present Government Digital ID (courtesy Oneproof.com)

Note as well that this functions when the wallet holds credentials from a different government issuer and even when the Wallet Provider (entity that published the app) is not a government entity. OEM Wallets and Consumer Wallet apps can present credentials through the same standards. The Wallet Holder (User) has control over the attributes shared during consent and is protected from malicious website RPs by “Reader ID Certificates”.

Login with eGov IDP (including Anonymously)

This setup will be mainly be useful for logging in to Government Agency websites within the same jurisdiction as the Wallet application. Consistent use of a login account across all State services provides simpler account management for the Resident or service recipient, which reduces support headaches and calls.

The RP Website chooses in advance to allow login with a eGov Login account (IDP) that is configured at the identity and authentication assurance levels that it requires. Preferably that IDP can also release claims (attributes) or scopes (sets of attributes) after user consent to the RP, including cryptographically signed claims in JWT formats. When the eGov Login Account IDP is appropriately configured with claims gathering from the proven attribute repository, the data released by the User in this situation is exactly the same as that released from a Wallet application.

It is also possible NOT to release any claims to the RP website for purely anonymous login. In this instance, the RP website knows only that their user has authenticated and can unlock their account information within the RP. Releasing only an Over18 claim is also possible. Given the client registration processes (dynamic or static) of Open ID, the RP will know that the user has been proofed by the Government but will not know the identity. Given key rotations and pairwise identifiers in Open ID Connect, this can retain anonymity if requires by the User or the situation.

Presentation of Government Digital ID through Secondary Login

The concept is that the RP website continues their current association with their Login IDP to identify their user’s accounts. However, at the point in time when a government ID is required for delivery of services, the RP Website links to a known Government Login IDP for the user to additionally “log in”, not to identify their RP account, but merely to initiate the transfer of claims attributes from the eGov Login IDP to complete the use case. Traditional claims consent mechanisms of the IDP provide user control. It is possible for the RP to store a derived version of these attributes (see below) at the risk of them becoming obsolete or outdated.

Deriving an Internal ID based on Government Digital ID

When utilizing any of the above methods for website users to present Government Digital ID, RPs have the option to derive their own internal ID from the received attributes. More on doing this is written elsewhere.

The advantages of deriving an ID or issuing an internal verifiable digital credential (VDC) is that the RP can add attributes to the credential relevant to their own ecosystem

For instance, a Healthcare Ecosystem Operator may take a few attributes from the Government Digital ID and add the attributes like medical number, insurance carrier, etc. to their derived VDC. This can retain anonymity while still providing the ability for each caregiver situation to match (including biometrically) the care recipient to their account and ID.

Conclusion: A Powerful Combination

Government Digital ID in a Wallet application paired with an eGov Login account provides the capacity for the quality of service delivery we expect from commercial providers.

Why hasn’t this taken off yet? A few factors:

• Wallet architects have come from the mobile space and feel resistance to the more centralized architecture inferred by an eGov Login IDP
• The largest Wallet and Login Providers think that they cannot bridge the gap between commercial, privacy-enhancing social login with the higher assurance eGov Login and prefer holding receipt logs
• Identity people from the Open ID space or from the Wallet space have come from two different deployment worlds
• Pushback from decentralized architecture proponents against server-side implementations is loud (yet eGov Login deployment continues)

Governments around the world will continue deploying eGov Login to enhance service delivery and allow residents to interact with them securely online while lowering queues at their physical office points of service.

Combining these with Wallet architectures is possible and opens the world of cross-context service delivery. For more information, to provide comments, or give feedback, you can reach me here on Medium.