How Should Turkey’s Digital ID Wallet Be Designed?

The success of a digital identity wallet depends on its trust model rather than the appearance of the mobile app. A poorly designed wallet can become a static QR code, a centralized tracking system, or simply another copy of personal data. Proper design, on the other hand, ensures that citizens share only the necessary attributes and that the institution verifies those attributes from an authorized source.

This article addresses the issuer–wallet–verifier architecture, QR workflow, selective data sharing, key security, and development roadmap for a digital identity wallet applicable to Turkey.

Key Actors

Issuer — the institution that publishes identity information

The issuer is the authorized source of specific information. The Directorate General of Population and Citizenship Affairs can issue basic personal identity; a university or the Council of Higher Education (YÖK) can issue diplomas; the Social Security Institution (SGK) can issue eligibility information; and an authorized professional organization can issue professional qualifications.

Each institution should only sign the type of credential for which it is authorized. A university should not be able to issue residency information, nor should an e-commerce site be able to issue a driver’s license.

Holder and wallet — citizen and wallet

The wallet stores credentials on behalf of the citizen or accesses them as needed. It displays the information requested by the institution in a clear format, obtains user consent, and generates a verifiable presentation using the minimum required fields.

Verifier — the institution requesting verification

A bank, hospital, employer, or e-commerce site can act as a verifier. However, the verifier must also prove its own identity and authority. The wallet must verify that the request truly originates from the specified institution and that the institution is authorized to request the desired data category.

Trust registry — trust list

The trust registry specifies which organization can issue which credentials and which verifier can request which information. The registry must be digitally signed, versioned, and able to be securely updated by wallets.

Status and revocation service

A credential may expire, be revoked, or be reissued. The verifier must be able to check the status of the information provided. This check must be designed with privacy protections so that the issuing authority does not reveal the citizen’s every place of use.

Credential Lifecycle

Kayıt ve güçlü kimlik doğrulama
        ↓
Credential yayınlama
        ↓
Cihaz ve kullanıcıya kriptografik bağlama
        ↓
Sunum ve seçici paylaşım
        ↓
Durum / geçerlilik kontrolü
        ↓
Yenileme, askıya alma veya iptal

The initial issuance of a credential is one of the most critical stages. If the initial identity verification is weak, all subsequent digital signatures will reliably represent the wrong person. During the registration process, e-Government, the Turkish ID card, in-person verification, or other methods meeting the appropriate trust level may be used in combination.

Sample Structure of Identity Information

The following structure is a conceptual example:

{
  "type": ["VerifiableCredential", "PersonIdentityCredential"],
  "issuer": "did:gov:tr:nvi",
  "validFrom": "2026-10-17T09:00:00Z",
  "validUntil": "2027-10-17T09:00:00Z",
  "credentialSubject": {
    "given_name": "Örnek",
    "family_name": "Kullanıcı",
    "age_over_18": true,
    "nationality": "TR"
  }
}

In the actual system, it is not required for all fields to be included in a single credential. For data minimization and to accommodate different usage periods, proof of age, address, driver’s license, and basic identity can be issued as separate credentials.

Dynamic QR Code Flow

The Turkish ID number or personal data should not be included in the QR code. The verifier generates a one-time request:

{
  "request_uri": "https://bank.example/request/8f7a...",
  "client_id": "bank-example",
  "nonce": "128-bit-rastgele-deger",
  "purpose": "customer_onboarding",
  "requested_claims": [
    "identity_verified",
    "legal_name",
    "over_18"
  ],
  "expires_in": 90
}

1. The verifier creates a signed, short-lived request.
2. The citizen scans the QR code using a digital wallet.
3. The wallet verifies the verifier’s certificate and its authorization in the trust list.
4. The required fields and the purpose of the transaction are displayed to the citizen.
5. The citizen authorizes the transaction using a PIN or device biometrics.
6. The wallet generates a message containing only the selected fields, along with a nonce and a reference to the Verifier.
7. The verifier validates the issuer’s signature, the target institution’s information, the validity period, the nonce, and the credential status.
8. The same QR code cannot be used a second time.
9. A transaction receipt is issued to the citizen.

Selective data sharing

Selective disclosure allows the wallet to prove only the desired field rather than revealing the entire credential. For example, it is possible to demonstrate that the 18-year-old age limit has been exceeded without sharing the date of birth.

For this purpose, SD-JWT VC, ISO mdoc, or appropriate zero-knowledge proof techniques can be used. Not every use case requires the same complex cryptographic method. The solution should be selected based on a balance of security, performance, auditability, and interoperability.

Organization-Specific Pseudonymous Identifier

To maintain a continuous customer relationship, the organization may need to recognize the individual in subsequent transactions. Instead of using the same national ID number across all organizations, a pairwise pseudonymous identifier can be generated:

PPID = HMAC(
  government_secret,
  internal_person_id || verifier_id
)

This is merely a conceptual framework. In actual implementation, key rotation, domain separation, versioning, and HSM policies must be designed. The same individual receives a different PPID across different organizations; organizations cannot directly merge data via a shared identifier.

Online and Offline Verification

Online model

The verifier or wallet connects to the government service during the transaction. The current status and authorization are verified in real time. Conversely, the central service can view the transaction context, and a service outage may halt verification.

Offline model

The credential, signed by the issuer, is stored in the wallet. The verifier validates the signature locally. The issuer is not notified of every use. However, the timeliness of revocation information and the offline validity period must be limited.

The hybrid model is more suitable for Turkey: low-risk credentials can be presented offline or without showing usage information to the issuer; online status checks can be performed for high-risk bank/KYC or critical public transactions.

Key Security

Issuer signature keys must be generated and used within an HSM. While an HSM prevents the key from being extracted, it does not prevent the issuance of incorrect credentials; authorization and business rules must also be safeguarded.

The citizen’s device key must be stored in a Secure Enclave, Android StrongBox, or an equivalent hardware-backed secure area. The key should not be extracted from the device if possible, and user authentication must be mandatory for critical operations.

Lost Device and Recovery

Copying the private key to a standard cloud backup is an easy but risky method. A more secure approach:

1. The wallet unit on the lost device is suspended.
2. On the new device, the citizen is re-authenticated at a high security level.
3. A new key pair is generated for the new device.
4. Credentials are reissued to the new device.
5. The old device and credential links are revoked.

The recovery process must be designed in a way that prevents attackers from taking over the account through the call center or SIM swap.

Transaction Receipt and Audit

The citizen should be able to view the following information:

• Which agency made the request?
• What was the purpose of the transaction?
• Which fields were requested?
• Which fields were shared?
• When and on which device was the transaction performed?
• Was online central verification used?

Audit logs are also personal data. They must not contain raw Turkish ID numbers; access must be restricted, their integrity must be protected using digital signatures or a hash chain, and they must be deleted after a specified period.

Standards

• Credential data model — W3C Verifiable Credentials 2.0
• Credential Issuance — OpenID for Verifiable Credential Issuance
• Credential presentation — OpenID for Verifiable Presentations
• Mobile Credential — ISO/IEC 18013-5 mdoc approach
• JSON Signature/Encryption — JOSE, JWS, JWE
• CBOR-based protection — COSE
• Web authentication — WebAuthn and passkey
• Key protection — HSM and device secure element

Blockchain is not required. A national PKI, signed trust lists, and publisher keys protected by HSMs can establish a sufficient trust model. Personal data or identity usage history should not be written to an immutable blockchain.

Reference development components

The first open-source reference implementation may consist of four parts:

1. Demo Issuer: Issues age and basic identity credentials to synthetic citizens.
2. Mobile Wallet: Stores credentials, reads QR codes, and generates selective presentations.
3. Verifier Portal: Generates requests for age or identity verification.
4. Trust/Status Service: Manages revocation status using issuer and verifier certificates.

The prototype should not use real citizen data. It should operate with synthetic identities, test root certificates, and an open threat model.

Development Roadmap

Phase 1 — Governance and Data Dictionary

Credential types, authorized issuers, verifier permissions, trust levels, retention policies, and citizen rights are defined.

Phase 2 — 18+ verification prototype

A use case requiring minimal data and clearly demonstrating the benefits of selective disclosure is developed.

Phase 3 — Diplomas and Professional Certificates

Testing of verifiable document issuance in collaboration with universities and professional organizations is conducted.

Phase 4 — Bank and Hospital Sandbox

KYC, patient registration, lost device, cancellation, malicious verifier, and offline verification scenarios are tested using synthetic data.

Phase 5 — Independent Security Assessment

Cryptographic review, mobile app testing, privacy impact assessment, accessibility testing, and red team exercises are conducted.

Phase 6 — Voluntary Limited Pilot

A pilot is launched at specific universities, municipalities, or public services while maintaining a physical alternative.

Designs to Avoid

• Placing personal data in the QR code,
• Using the same fixed digital identity across all organizations,
• Tracking every transaction centrally,
• Developing a closed protocol dependent on a single vendor,
• Storing private keys in standard cloud backups,
• Relying solely on user consent as the legal basis,
• Excluding citizens without smartphones from services,
• Writing personal data to the blockchain.

Trust and governance implemented in the reference demo

The October 2026 implementation includes an HTTPS portal, institution-bound sessions, the short-lived two-QR flow, iPhone device signatures and an isolated SoftHSM service. Issuer and verifier business logic still runs in the central API; signing is a separate service. Describing three roles does not make them three independent trust authorities.

Dynamic institutions and field grants

An institution registers a name, type and separate account, then waits for approval. The administrator selects appropriate grants from the institution type’s allowed field catalogue. An institution cannot expand its own grants or read and continue another institution’s requests.

Versioned request templates

A template records the transaction title, explicit purpose, catalogue fields, a justification for each field and whether it is required or optional. New revisions require separate review. Existing requests retain their original fields and requirements, and the signed result includes the template identifier and version.

Institutions, grants, salted scrypt account-password hashes and template revisions persist in SQLite. This local governance registry is not a signed national trust list, enterprise SSO, certificate lifecycle system or real legal-entity verification service. New accounts support application sessions; they do not automatically provision accounts at the existing outer web gateway.

The issuer key is held in SoftHSM and the real iPhone’s device key in Secure Enclave. Moving from software protection to a hardware HSM requires vendor integration, key policies, rotation, backup and continued verification of earlier signatures.

Conclusion

Turkey’s digital identity wallet is a project focused on open standards, privacy, key management, and strong governance—even before the mobile app. The system should ensure the minimal and verifiable sharing of identity attributes rather than simply digitizing the identity number.

Next article in the series: Real-world use cases for the digital identity wallet—from hospitals to banks.

Official sources

• W3C Verifiable Credentials Data Model 2.0
• OpenID for Verifiable Presentations 1.0
• OpenID for Verifiable Credential Issuance 1.0
• EUDI Wallet Architecture and Reference Framework
• TÜBİTAK BİLGEM — Electronic Identity Verification System

The sample data structures are conceptual; they do not replace a production protocol or security profile.