From the Hospital to the Bank: Real-World Use Cases for the Digital ID Wallet

The value of a digital ID wallet is measured not by the cryptographic algorithm it uses, but by the unnecessary data sharing it eliminates in real life. A good use case is not “showing your ID card on your phone”; it is proving the attribute required for a specific service with the minimum amount of data.

In this article, we examine scenarios in hospitals, banks, e-commerce, education, car rentals, hotels, public assistance, and corporate authorization—along with the data shared, technical workflows, and risks to be aware of.

1. Patient Registration at a Hospital

In the current process, a citizen can verbally provide their Turkish ID number or hand their ID card to a staff member. The number may be stored on a screen, in a call center, in a log, or in various hospital systems.

In the digital wallet model, the hospital may request the following:

• Has the identity been verified?
• Is health insurance active?
• Does it match the existing patient record at this hospital?
• Is there any critical information, pre-designated by the citizen, that can be accessed in an emergency?

{
  "identity_verified": true,
  "insurance_eligible": true,
  "hospital_patient_id": "HSP-A-72F91...",
  "assurance_level": "high"
}

A unique identifier specific to the institution or the healthcare sector may be used for the hospital. A careful balance must be struck between the continuity of health records across different institutions and the risk of cross-institutional traceability.

User consent may not be obtainable in an emergency. “Break glass” access must require separate authorization, justification, robust logging, subsequent notification to the citizen, and independent audit.

2. Customer Onboarding at Banks

Banks are required to verify identities at a high level of security due to customer identification and anti-financial crime obligations. A digital wallet does not eliminate these obligations; however, it can make the data collection and verification process more secure.

The bank may request the following credentials or proof:

• Basic identity verified,
• First and last name,
• Age requirement met,
• Residence information verified,
• ID document is valid,
• The wallet is linked to the device and the user,
• If required, the Turkish ID number was obtained via an authorized backchannel.

If regulations require the Turkish ID number to be obtained, the number cannot be completely eliminated. However, it is possible to prevent the citizen from entering the number into a web form, sending an image of the document via email, and having the data copied to multiple intermediate systems.

3. Age Verification in E-commerce

For products or services with age restrictions, the website often does not need to know the user’s full date of birth or Turkish ID number.

{
  "age_over_18": true,
  "issuer_trusted": true,
  "presentation_bound_to": "shop.example",
  "expires_in": 120
}

The verification is generated solely for the relevant site and is valid for a short period. It will not work if copied to another site. If user account continuity is required, a site-specific alias can be used.

4. Diplomas and Student Status

Instead of requesting a PDF diploma, an employer or scholarship provider can verify a credential signed by the university or the Higher Education Council (YÖK):

{
  "degree": "Bilgisayar Mühendisliği",
  "level": "Lisans",
  "graduation_verified": true,
  "issuer": "yetkili-universite",
  "status": "valid"
}

If the employer does not require the individual’s grade report, the transcript is not shared. For student discounts, only the “active student” status may be provided; the major or date of birth may not be disclosed.

5. Car Rental and Driver Eligibility

A car rental company can verify the following fields instead of a driver’s license image:

• The driver’s license is valid,
• The required vehicle class is available,
• The minimum age requirement is met,
• The license has not been suspended.

The company does not need to collect information unrelated to the transaction, such as address, place of birth, or ID card serial number. Signatures can be verified locally at offline pickup locations; the risk policy determines how up-to-date cancellation information must be.

6. Hotels and Accommodations

Hotels may be required by law to maintain certain records. The Wallet does not eliminate this legal obligation; however, instead of the receptionist photocopying the document or manually transcribing the information, it allows for the verified transfer of the required fields.

The user should be able to see on the sharing screen which fields are required by law and how long they will be retained.

7. Airlines and Travel

Airline or travel platform:

• Verification that the person on the reservation matches the document holder,
• The validity status of the travel document,
• The required duration for the destination country,
• and whether the document was issued by an authorized country

. International border control and passport presentation will continue; the benefit is to reduce unnecessary document copies in the reservation and support chain.

8. Public Assistance and Proof of Eligibility

Instead of requiring an individual to upload all income and family records to the application system, an assistance program can obtain the following information from authorized agencies:

{
  "program": "destek-programi-x",
  "eligibility_criteria_met": true,
  "valid_until": "2026-12-31"
}

The decision must be transparent. Citizens should be able to see which criteria were used, challenge incorrect information, and not be subject solely to an automated decision.

9. Corporate Representation Authority

The commercial registry or an authorized agency may issue a representation credential to an individual that includes a time period and transaction limits:

{
  "company": "Örnek A.Ş.",
  "role": "authorized_representative",
  "transaction_limit": "5000000 TRY",
  "valid_until": "2027-01-01",
  "status": "active"
}

The credential is revoked when an employee leaves or management decisions change. The bank, notary, or supplier verifies the current status rather than relying on an outdated PDF of the signature circular.

10. Public Buildings and Physical Access

The visitor QR code does not contain a Turkish ID number. The building system only verifies that the visit is approved, the time window is valid, and the inviting unit is correct.

To prevent the same credential from being reused in a different building or on a different date, the audience, nonce, and validity period must be used.

Use Case Design Template

The following table must be completed for each new usage scenario:

• What is the business purpose? — To verify the age limit of 18
• What is the minimum claim amount? — age_over_18=true
• Who is the issuer? — Authorized public identity service
• Who is the verifier? — Licensed e-commerce platform
• Is a persistent identifier required? — No, or a site-specific PPID
• Is online verification required? — Depending on the risk policy
• What is the processing time? — 90–120 seconds
• What records are kept? — Purpose, verifier, claim, and result
• What is the physical alternative? — Verification by an official using an ID card

Development example for the first pilot

The most straightforward pilot is the 18-year-old age verification.

Issuer service

1. Creates a synthetic citizen record.
2. Calculates the age.
3. age_over_18 Signs the claim by binding it to the wallet’s device key.
4. Publishes the credential status record.

Verifier application

1. Generates a nonce for the transaction.
2. Prepares a signed request age_over_18 the field.
3. Displays the request as a QR code.
4. Verifies the issuer’s signature, audience, nonce, and duration of the presentation received from the wallet.

The mobile wallet

1. reads the QR request.
2. It verifies that the verifier is trustworthy and authorized to request age information.
3. Displays the organization, purpose, and the single field to be shared to the user.
4. Obtains approval via device biometrics or a PIN.
5. Generates a presentation tied to the verifier and nonce.
6. Saves the transaction receipt.

Negative scenarios to be tested

• Reuse of the QR code screenshot,
• Redirecting the request to another verifier,
• An expired credential,
• A revoked device,
• Fake issuer certificate,
• An unauthorized verifier requesting health data,
• User’s refusal to share,
• Offline verifier and outdated status information,
• Lost phone recovery attack,
• Incorrect user consent in accessibility mode.

Consent and legal basis are not the same thing

The wallet obtaining transaction approval from the user is a good measure of transparency and security. However, this approval is not always explicit consent under the Personal Data Protection Law (KVKK). A bank, hospital, or public institution may base data processing on a legal obligation, the performance of a contract, or another valid processing condition.

The wallet should make the legal basis visible but should not reduce the regulatory decision to a single button on the user interface.

Success Metrics

The success of the pilot should be measured not by the number of app downloads, but by the following metrics:

• Number of Turkish ID numbers prevented from being collected,
• Number of document image copies prevented,
• Average number of claims disclosed per share,
• Successful and rejected fake verifier requests,
• Time to deactivate a lost device,
• Offline verification success rate,
• Accessibility and user comprehension rate,
• Amount of personal data exposed in the event of a data breach.

Use cases that currently run in the demo

The sector examples above describe target designs. The implemented application only shares synthetic demo information. Its separate journeys cover:

• Bank — Demo transaction: Account pre-application; Example fields: Verified-identity flag, name, age threshold and selected address fields
• Hospital — Demo transaction: Patient preregistration; Example fields: Name, date of birth, phone and insurance status
• Municipality — Demo transaction: Resident application; Example fields: Personal information and selected residence/address fields
• Market — Demo transaction: Age verification; Example fields: Only the over-18 result
• University — Demo transaction: Student benefit; Example fields: Active student status and university name
• Delivery — Demo transaction: Delivery information; Example fields: Recipient name, phone and address
• Mobility — Demo transaction: Driver precheck; Example fields: Name, age threshold, licence validity and class
• Social support — Demo transaction: Household summary; Example fields: Household size, dependent children and marital status

Example: Eren Baş University designs its own request

1. Create the institution and a separate account. The institution initially awaits approval.
2. Design a “Student registration application” template: name and phone may be required, while city is optional. Explain why each field is requested.
3. The administrator approves the institution’s field grants and then reviews the template revision.
4. Sign in with the institution account, select its approved scenario and redeem the student wallet’s temporary connection code.
5. The open iPhone app receives the request. The user scans the institution’s transaction QR, selects fields and confirms with the device.
6. After API validation, SoftHSM signs the result. The API verifies it with the public key and returns it to the institution.

This creates a verifier request template, not a new credential type or a diploma. If required fields are withheld, the result is incomplete. Receiving some information and receiving enough information to complete a transaction are separate outcomes.

A market account attempting to continue a hospital request receives HTTP 403 with an explanatory message. Editing a template also cannot expand the scope of an existing request. Both controls are enforced by the server as well as explained in the interface.

Conclusion

A digital identity wallet is not just a single application; it is a new data-sharing agreement between the public and private sectors. A hospital should not request a person’s full identity but rather their medical eligibility; an e-commerce site should not request a date of birth but rather an age threshold; and an employer should not request a copy of a diploma but rather verified graduation status.

A successful system is not one that collects more data from citizens, but one that can establish the same level of trust with less data.

Official Sources

• W3C Verifiable Credentials Data Model 2.0
• OpenID for Verifiable Presentations 1.0
• EU Digital Identity Wallet FAQ — Selective Disclosure
• NVI — Identity Sharing System
• Personal Data Protection Authority — Personal Data

This article is intended for general technical and legal evaluation; sector-specific data processing obligations should be examined separately.