Moving the Digital Identity Demo into Production: Testing, Threat Modeling, and a Roadmap for Standardization

The fact that a prototype works does not mean it is ready for production. This distinction is particularly important in the field of digital identity, because failure is not merely a technical error—it can lead to identity theft, unauthorized data sharing, or citizens being unable to access the service.

In the final installment of this series, I analyze the local digital identity lab in terms of test results, threat modeling, privacy implications, and compliance with standards. The goal is not to produce a “checklist,” but to clarify the assumptions under which the prototype operates and identify which engineering layers need to be added for it to transition into a production system.

Test strategy: Verify behavior, not the screen

A green checkmark is not enough. The current revision runs 22 Node.js tests, all passing locally and in an isolated Docker environment connected to SoftHSM. The table below lists the foundational areas; the new institution and template checks are detailed later.

• Signed proof of age — The presentation is signed, has a minimum field count, and is tied to the institution and nonce; it cannot be reused.
• Under-18 Scenario — The result of the condition is generated correctly; different institutions receive different pairwise identifiers.
• Document lifecycle — A revoked certificate cannot be presented; it becomes usable again after reissuance.
• Entity policy — Undefined organizations and unauthorized scenarios are rejected.
• Expiration — An expired request cannot be submitted and is marked as "expired."
• Mobile Workflow — The transaction code and link are resolved to the same request; a closed request cannot be reopened.
• Field minimization — Only selected and authorized address/family fields are included in the proof.
• Device signature — The signature depends on the nonce, the subject, and the selected fields; any mismatch is rejected.
• Targeted notification — Pairing tokens associated with the wrong person, the wrong QR code, or another request are not accepted.
• Wallet Discovery — The opaque code is single-use; it generates a session tied to the institution and a single request.
• TTL — The pairing code and connection session expire at the end of the time limit.

These tests demonstrate that the behaviors defined in the prototype are reproducible. They do not prove that the cryptographic design has been verified by independent experts, that the mobile app is attack-resistant, or that it complies with regulations.

Privacy Analysis

Positive Design Decisions

• The institutional portal does not include a citizen list or Turkish ID number search.
• Wallet discovery is performed using an opaque, short-lived, and single-use code.
• The verifier only retrieves the fields permitted by the scenario and selected by the user.
• Different pairwise identifiers are generated for different institutions.
• The lock screen notification does not display sensitive field values.
• The camera feed is processed on the device and is not uploaded to the server.
• A rejected transaction is also acknowledged with a receipt stating “no information was shared.”

Intentional prototype limitation: online issuer model

During the demo, the wallet connects to the issuer service while presenting the document. The issuer verifies the document, retrieves the selected fields, and signs a new proof tied to the verifier and nonce. This approach is simple from a development and explanatory standpoint; however, the issuer can view every transaction.

In the production design, depending on the use case, SD-JWT VC, ISO mdoc, or another suitable selector description format may be evaluated. The goal is to enable the verifier to validate the required fields and the holder binding without requiring the wallet to bring the publisher online for every presentation.

Trust Boundaries

The web wallet makes the prototype workflow visible; in production, roles and trust domains must operate in separate services. Screenshot from the initial revision.

Signing now runs in a separate SoftHSM service; issuer/verifier business logic and verification remain in the central API. Institutions, password hashes, field grants and template revisions persist in SQLite. Requests, connections, device registrations and receipts remain in memory. Institution roles use authenticated sessions, while wallet person selection remains a synthetic-demo mechanism.

These are not hidden flaws, but rather the lab’s explicit assumptions. In the production architecture, at least the following trust domains must be separated:

1. Issuer: Authorized registration source, credential issuance policy, and signature keys protected by an HSM.
2. Wallet: Device-bound keys, user session, consent screen, secure recovery, and device loss process.
3. Verifier: Organization identity, registered request purposes, requested field policy, and verification records.
4. Trust infrastructure: Trusted issuer/verifier registries, certificate chains, status, and revocation services.
5. Audit: Tamper-resistant audit logs that do not unnecessarily store personal data.

Key Management

The hosted issuer key is generated in a persistent SoftHSM token with PKCS#11 export disabled. Production requires appropriate hardware protection, separation of duties, controlled rotation and recovery. Key identifiers and trusted public keys must be managed so that earlier signatures remain verifiable.

On the device side, the Secure Enclave P-256 key is used for genuine iPhones. However, in production, it is not sufficient for the key to simply be present in the hardware. It must be determined which citizen wallet the key is linked to and through which registration process, how it is revoked upon device replacement, and at what trust level credentials are reissued to the new device.

Authentication and Wallet Registration

In the prototype, person: "adult" there is a demo selection option. This selection merely facilitates a synthetic workflow. In production, wallet registration must be performed via e-ID, NFC, PIN, in-person verification, or other high-security channels approved by regulations.

If the initial registration is weak, the Secure Enclave protects the wallet—even if it belongs to the wrong person—in a highly secure manner. Therefore, onboarding, device binding, and credential issuance must be designed as a single chain of trust.

Roadmap for Transition to Standards

The prototype uses its own small JSON and API contracts. To ensure interoperability in production, a transition from a custom protocol to standard profiles is required.

1. Credential Data Model and Format

The W3C Verifiable Credentials Data Model 2.0 defines the issuer-holder-verifier ecosystem and the credential structure. Additionally, formats such as SD-JWT VC or ISO mdoc can be selected based on the usage context. The choice of format affects not only the data structure but also decisions regarding selective disclosure, holder binding, offline verification, and mobile performance.

2. Credential Issuance

OpenID for Verifiable Credential Issuance 1.0 defines an OAuth-protected API for credential issuance and became a Final Specification in September 2025. The /api/credential must be adapted to the OID4VCI flow, where users are authenticated and authorized in a real-world system.

3. Credential Presentation

OpenID for Verifiable Presentations 1.0 defines the standard flow for the verifier to request a credential and for the wallet to present it. The audience and nonce links in the demo illustrate the correct security concept; in production, the request object, verifier identity, response mode, presentation format, and error flows must be implemented in accordance with the standard.

4. Trust registries and verifier policy

Institution field grants and request purposes are no longer limited to a hard-coded list: the demo uses administrator-approved records and versioned templates. Production still needs real institution verification, signed trust registries, credential schemas and certificate lifecycle management.

5. Status and Revocation

In the demo revoked flag is stored in memory. In production, the credential status mechanism must ensure a balance between timeliness, performance, and privacy. Each status query must be prevented from providing the issuer with the information “the citizen is currently at this organization.”

Operational Resilience

The production wallet must be reliable not only during normal operations but also during errors and crises:

• How will the old wallet unit be suspended if the device is lost?
• What alternative channel will a citizen without a phone use?
• If the issuer or status service goes down, will low-risk offline verification be possible?
• In the event of a suspected key leak, which credentials and trust lists will be updated?
• How will users and audit units be notified if data is sent to the wrong institution?
• How will accessibility requirements and proxy/representation scenarios be addressed?

Why does family information require separate analysis?

The demo includes scenarios for household summaries and detailed family members. These fields concern not only the wallet owner but also third parties. The fact that a user can technically select a field does not mean they are legally authorized to share that information.

In real-world applications, custody, guardianship, power of attorney, transaction purpose, and the data subject’s rights require separate policy layers. Furthermore, in high-stakes decisions such as social assistance, wallet data should not be transformed into an automated and non-appealable decision-making mechanism.

Recommended Development Phases

1. Protocol profile: Determine the VC/mdoc format to be used, as well as the OpenID4VCI and OpenID4VP profiles.
2. Synthetic sandbox: Run the issuer, wallet, and verifier as separate services; set up a test PKI and trust registry.
3. Device registration: Add robust onboarding, attestation, Secure Enclave/StrongBox key management, and re-registration processes.
4. Lifecycle: Implement issuance, renewal, suspension, revocation, key rotation, and lost device scenarios.
5. Privacy assessment: Conduct a DPIA for connectivity, telemetry, logs, status queries, and third-party data.
6. Negative tests: Expand tests for replay, incorrect audience, incorrect nonce, QR code swapping, malicious verifier, and corrupted credentials.
7. Independent review: Conduct an external assessment of cryptography, mobile security, backend, HSM policies, and accessibility.
8. Limited pilot: Start with a low-risk, measurable use case that preserves a physical alternative.

Latest validation: 22 tests and implemented security boundaries

For the 20 October 2026 revision, all 22 Node.js tests passed locally and in an isolated Docker environment connected to the real SoftHSM signer. Live HTTPS checks also exercised institution login, the two-QR flow, an iPhone-format P-256 device signature and an ES256 result signature. The result was verified independently with the public key rather than relying only on the API’s success flag.

• Institution isolation — A market account cannot use a hospital connection, read its result or verify its proof through that account.
• Required approvals — Pending institutions and unapproved templates cannot send requests; institutions cannot approve their own grants.
• Field constraints — Unknown, type-inappropriate or ungranted fields are rejected.
• Revision pinning — Approving a newer revision does not change an existing request’s fields or requirements.
• Persistence — Institution accounts, grants and template history survive application restart.
• Password storage — SQLite stores salted scrypt hashes, not plaintext institution passwords.
• Signer outage — Signing and health checks fail; the application does not fall back to a development key.

Deployment validation also tested key continuity across signer restart and rejection of private-key reads. These are version-specific behavior checks, not certification or an independent penetration test.

What persists and what remains temporary?

• Issuer private key — SoftHSM token volume, not mounted into the API container
• Institutions, password hashes, grants, template revisions — Persistent SQLite database
• Pairwise HMAC secret — Persistent API-accessible file; not yet in the HSM
• Requests, sessions, device registrations, receipts — API memory; reset on restart
• Signing events — Metadata log, not WORM or immutable against a host administrator

Remaining production work

• Hardware HSM protection, key rotation, dual control, backup and disaster recovery.
• Real person and legal-entity enrollment, enterprise SSO/MFA, lost-device response and secure reenrollment.
• Require device signatures consistently across appropriate production presentation channels. Native iPhone flows use them, but the current API still supports unsigned legacy web-demo presentations.
• Durable request, device, revocation and audit records, plus concurrency design for multiple API instances.
• Standard credential/presentation profiles, independent verifier implementations and privacy-preserving status checks.
• Tighter business authorization around signing: a non-extractable key alone cannot prevent misuse by a service permitted to request signatures.

TestFlight distribution has been prepared around private invitations. Notifications are local while the app is open; background APNs notifications are not implemented. AI-assisted request explanations and excessive-field detection remain proposed future work, not an implemented module.

Conclusion

This demo seeks to answer the question “What do the parties trust?” rather than “What does a digital identity wallet look like?” Wallet discovery and transaction binding are separated using two QR codes; the user makes decisions on a per-domain basis; device selection is signed; the presentation verifier and nonce are linked; and pairwise identifiers are used instead of a shared ID number across organizations.

The path to production involves replacing proprietary demo APIs with standard protocols, separating trust domains, tying keys to HSM and device security, implementing robust registration and recovery processes, and undergoing an independent security assessment.

Sources

• W3C — Verifiable Credentials Data Model v2.0
• OpenID Foundation — OpenID for Verifiable Credential Issuance 1.0
• OpenID Foundation — OpenID for Verifiable Presentations 1.0
• European Commission — EUDI Wallet Architecture and Reference Framework