Why This Matters
Remote account opening often relies on guesswork. With digital document forgeries up 244% and biometric verification fraud increasing, the need for secure identity verification is urgent. A cryptographically signed mobile driver's license (mDL) offers a verified solution, shifting from interpretation to proof.
Three key elements now align to support mDL acceptance. NIST SP 1800-42A outlines a tested mDL architecture for account opening. The OpenID Foundation's Identity Proofing Extension details proofing rigor. FinCEN, alongside federal agencies, confirmed that government-issued digital credentials can qualify as identification under 31 C.F.R. § 1020.220. This guide integrates these components.
What You Need Before Starting
- Compliance Authority: Someone to amend the Customer Identification Program (CIP) to permit mDLs.
- Verifier Component: A system to handle ISO/IEC 18013-5 mDL presentations, including remote flows.
- Issuer Trust List Access: Use AAMVA's Digital Trust Service in North America or Austroads' in Australia and New Zealand.
- Proofing-Assurance Policy: Map product risk tiers to proofing levels, referencing NIST SP 800-63-4 and ETSI TS 119 461.
- Fraud/Decisioning Engine: Capable of processing structured claims.
- Fallback Path: Maintain existing document-and-selfie verification for customers without mDLs.
Step-by-Step Implementation
1. Amend the Written CIP.
Ensure your CIP includes conditions for mDL acceptance: unexpired, government-issued, and containing a photograph. Specify permitted channels like in-person or remote.
2. Set Up Issuer Verification.
Regularly update and verify the VICAL or Austroads list. Store issuer certificates separately from TLS roots. Reject presentations not linked to trusted issuers.
3. Build the Verification Pipeline.
Validate each presentation by checking issuer signature, certificate chain, credential validity, device binding, and required data elements. Log any failures.
4. Capture Proofing Assurance as Structured Data.
Separate issuer-asserted proofing metadata from verifier-asserted data. Maintain a clear audit trail.
5. Map Assurance to Risk Tiers.
Create a decision table linking products to proofing levels. Route credentials lacking necessary claims to step-up verification.
6. Wire the Decision Layer.
Integrate identity attributes and proofing evidence into your decisioning engine. Ensure records reflect both identity and verification strength.
7. Protect the Session.
Bind the application session to the transaction to prevent replay attacks. Use Phishing-Resistant Authentication (FIDO2) for secure enrollment.
Validation: How to Verify It Works
- Negative Testing: Test with expired credentials, tampered signatures, and untrusted issuers. Ensure failures are logged correctly.
- Trust List Failure Modes: Simulate VICAL issues and confirm policy compliance.
- Interoperability Testing: Test across different wallet implementations and jurisdictions.
- Compliance Walkthrough: Ensure compliance can trace account openings from CIP to evidence.
- Tier Routing: Confirm low-assurance credentials are stepped up for high-risk products.
Ongoing Maintenance
- Trust List Refresh: Monitor updates and signature validations.
- Certificate Lifecycle: Track expirations and revocations.
- Policy Review: Update assurance-to-tier mappings as proofing practices change.
- Draft Tracking: Follow SP 1800-42A developments and adjust as needed.
- Fraud Feedback Loop: Adjust tier thresholds based on fraud cases.
- Community Input: Share findings with the eKYC & IDA Working Group.
By integrating these standards and practices, your team can securely implement mDLs in financial services, enhancing identity verification and reducing fraud risks.
