State Digital Identity Rollouts: A Reference for Architects

Scope

This guide focuses on the technical and policy decisions you'll face when deploying a state-level digital identity scheme. It's designed for IAM architects evaluating standardized frameworks, FIDO2 integration points, and credential lifecycle management at scale.

You won't find vendor comparisons or procurement advice here. Instead, you'll get the requirement categories, integration patterns, and security controls that define a production-ready state identity system.

Key Concepts and Definitions

Digital Identity Scheme: A government-operated system for issuing and verifying credentials that allow residents to prove attributes like age, residency, and licensure without physical documents.

FIDO2: The standard for phishing-resistant authentication combining WebAuthn (browser API) and CTAP2 (authenticator protocol). It's essential for credential binding.

Relying Party (RP): Any service accepting your state's digital credentials, including state agencies, municipal services, and authorized third-party integrators.

Trust Fabric: The policy layer connecting your credential authority, attribute providers, and relying parties. It defines what each entity can assert, verify, and consume.

Requirements Breakdown

Identity Proofing (NIST SP 800-63A)

Your scheme needs a documented path to Identity Assurance Level 2 (IAL2) minimum. This includes:

• Evidence validation (checking document authenticity and integrity)
• Evidence verification (confirming the document belongs to the applicant)
• Address confirmation through independent records
• Biometric comparison when the evidence includes a photo

If you're targeting IAL3 for high-value transactions, add supervised remote or in-person proofing. Plan for this from the start, as it significantly alters the evidence collection workflow.

Authenticator Binding (NIST SP 800-63B)

FIDO2 authenticators meet Authenticator Assurance Level 2 (AAL2) and AAL3 requirements when properly implemented. Your binding ceremony must:

• Generate and store the credential on a Multi-Factor Cryptographic Device
• Verify user presence through a physical gesture
• Confirm user verification through biometric or PIN for AAL3
• Record the authenticator's attestation statement for your device inventory

Avoid SMS-based One-Time Passwords; they don't meet AAL2 and create unnecessary support overhead.

Federation Architecture (NIST SP 800-63C)

Your relying parties will use OAuth 2.0 with Authorization Code Flow and Proof Key for Code Exchange. Structure your claims to include:

• Core identifier (persistent, pairwise per RP to prevent correlation)
• Verified attributes (name, date of birth, address) with assertion metadata
• Derived attributes (age_over_21, in_state_resident) calculated at assertion time
• Credential strength indicator (AAL achieved, proofing level, authenticator type)

Don't overload a single token. High-sensitivity attributes should require step-up authentication and separate consent.

Credential Lifecycle

Plan for these states from the beginning:

• Issued: Resident completed proofing and bound authenticator
• Active: Credential valid for assertions
• Suspended: Temporary hold (fraud investigation, address verification pending)
• Revoked: Permanent invalidation (reported lost, duplicate detected, resident request)
• Expired: Passed validity period without renewal

Your Policy Decision Point needs real-time access to revocation status. Cached credential checks create windows where revoked credentials still work.

Implementation Guidance

Start with Birthright Access Mapping

Before issuing any credentials, document what access every resident gets automatically. This is your Birthright Entitlement Catalog:

• Driver's license renewal
• Vital records requests
• Professional license verification
• Public records access

Everything else requires explicit entitlement grants and should trigger a Certification Campaign before go-live.

Design for Entitlement Drift

Residents change addresses, turn 18, earn professional licenses, and update legal names. Your identity enrichment pipeline must:

• Pull authoritative changes from source systems (DMV, vital records, professional boards)
• Recalculate derived attributes when inputs change
• Notify relying parties of material changes that affect access decisions
• Log every enrichment event for compliance reporting

Implement Back-Channel Communication for Logout

Front-channel logout (browser redirects) fails when users close tabs or lose connectivity. Use [OpenID Connect Back-Channel Logout](https://openid.net/specs/openid-connect-Back-Channel Communication-1_0.html) to notify relying parties directly. Your session broker needs to track every active session and send logout notifications to all RPs when:

• The resident initiates logout
• You detect suspicious activity
• The credential enters suspended or revoked state
• Session lifetime expires

Common Pitfalls

Treating proofing as one-time: Residents lose devices, change authenticators, and need to re-establish trust. Build a streamlined re-proofing flow that uses your existing record without starting from scratch.

Ignoring authenticator inventory: Maintain a registry of every bound authenticator with its attestation format, AAGUID, and credential ID. When a vulnerability affects specific authenticator models, you'll need to identify and rotate affected credentials quickly.

Skipping the Toxic Access Combination analysis: Some attribute combinations create unacceptable risk. Define these patterns before launch and enforce separation through your Policy Administrator.

Underestimating reconciliation load: Your nightly reconciliation job will find mismatches between your identity store and authoritative sources. Plan for 2-5% variance initially. Every mismatch needs investigation; you can't auto-resolve discrepancies in legal names or addresses.

Quick Reference Table

Component	Standard	Key Requirement	Common Gap
Identity Proofing	NIST SP 800-63A IAL2	Evidence validation + verification	Missing address confirmation workflow
Authentication	FIDO2	Phishing-resistant, hardware-bound	Allowing SMS OTP as fallback
Federation	OAuth 2.0 + PKCE	Authorization Code Flow only	Implicit flow still enabled
Attribute Assertion	OpenID Connect	Pairwise identifiers per RP	Using global persistent ID
Session Management	OIDC Back-Channel Logout	Direct RP notification	Relying on front-channel only
Revocation	Real-time status check	Sub-second PDP lookup	Daily batch updates
Lifecycle	Documented state model	Suspend before revoke	Direct transition to revoked
Audit	Compliance Reporting	Immutable event log	Logs without correlation IDs

Your state digital identity scheme will evolve. Build the tools to measure what's working. Track proofing abandonment rates, authenticator registration failures, and RP integration errors. The data will guide your next steps.