Live Demo

Verifier asks. miTch filters. You decide.

Four concrete scenarios — same mechanics. Click through each step and see exactly what is shared, what is blocked, and why.

Request

Analysis

Proof

Result

① Verifier Request

ExampleAds GmbH wants to verify you

🎯 ExampleAds GmbH Trust 91/100

did:mitch:exampleads-gmbh-at · OID4VP 1.0 · Registered AT-DSA

Was wird angefragt?

age_threshold≥ 18🟢 Predicate

region_matchEU / EEA🟢 Predicate

humanity_proofverified🟢 Predicate

frequency_cap5 / day🟢 Rate Limit

This request is transmitted as an OID4VP Presentation Request. No direct data access is possible.

② miTch Analysis

What does the verifier get — and what not?

Shared attributes (minimal proof)

age ≥ 18true/false, no age🟢 Low

region: EUyes/no, no country🟢 Low

humanityverified🟢 Low

Structurally not shareable

Last Name, First NameNOT IN PREDICATE

Date of BirthNOT IN PREDICATE

IP-AdresseSTRUCTURAL IMPOSSIBILITY

Browsing HistorySTRUCTURAL IMPOSSIBILITY

⚠ Inference-Risiko: 🟡 Medium

With Age ≥ 18 + Region EU + timestamp, the verifier can form a rough demographic cluster. Your exact age, country, or profile remains unknown. The budget signal is quantized into 1,920 slots — no continuous fingerprinting is possible.

Your Ad-Preferences (remain local)

Max. Impressions/Tag	5
Quiet Period	22:00–07:00
Blocked Categories	IAB-7 (Health), IAB-14 (Religion)

③ Proof Generation

Nullifier + Budget signal are generated

The nullifier is deterministic: SHA-256(user_seed ‖ verifier_did ‖ scope_id). Two verifiers with the same scope receive different nullifiers — no cross-verifier tracking is possible.

— Not yet generated —

④ Result

What does the verifier see — vs. what does the user see?

🔴 Verifier sees

age_gte_18:true

region_eu:true

humanity:verified

nullifier:H(…4f2a)

budget_slot:847 / 1920

name:—

dob:—

ip_address:impossible

🟢 You see (Wallet)

Verifier:ExampleAds GmbH

Time:—

Shared:3 predicates

Blocked:4 fields

Budget:4 / 5 remaining

Basis:GDPR Art. 6(1)(a)

Receipt:consent-…3c9f

Sybil Prevention: The same nullifier for ExampleAds + campaign-summer25 can only be used once per frequency window. 100 fake accounts → 100 different nullifiers, but each is tracked by the verifier and blocked once the limit is reached.

1 / 4

Request

Analysis

Proof

Overreach

① Verifier Request

IVB Innsbruck asks: Are you a student?

🚌 IVB Innsbruck — Studententicket Trust 88/100

did:mitch:ivb-innsbruck · Registered AT-DSA · Tirol

Was wird angefragt?

student_statusis_student: true/false🟢 Boolean

valid_untilSemesterende🟢 Date

② miTch Analysis

Risk Analysis: 🟢 Low — safe to share

What is shared (minimal proof)

student_statustrue🟢 Low

valid_untilSemesterende 23:59🟢 Low

Structurally not shareable (not in request)

Name, VornameNOT REQUESTED

Matriculation NumberNOT REQUESTED

Date of BirthNOT REQUESTED

UniversityNOT REQUESTED

Field of StudyNOT REQUESTED

ℹ Inference-Risiko: 🟢 Low

Student boolean + semester end date do not allow any conclusions about identity. IVB only learns: This wallet user is a valid student. No profiling possible.

③ Ephemeral Credential

Short-term credential is issued

The credential is valid only for this session and expires automatically at midnight. The university confirms the status — IVB never learns which university.

— Not yet confirmed —

④ Overreach-Demo

What happens when a vendor asks for too much?

IVB+ (pilot program) makes an extended request — in addition to student verification, the vendor wants the matriculation number and university name.

Request from IVB+

student_status✓ OK

valid_until✓ OK

matriculation_number⛔ BLOCKED

university_name⛔ BLOCKED

423 students have already reported IVB+ as overreaching. From 500 reports, the vendor is automatically reported to the AT-DSA.

1 / 4

Request

Risk

Consent

Post-Session

① Verifier Request

UKH Innsbruck — Hospital Admission

🏥 UKH Innsbruck — Hospital Trust 97/100

did:mitch:ukh-innsbruck · ELGA-zertifiziert · Art. 9 GDPR Basis

Was wird angefragt?

allergiesList🟡 Medium

blood_groupABO+Rh🟢 Low

insurance_statusPublic/Private🟢 Low

Legal basis: GDPR Art. 9(2)(c) — vital interests. Ephemeral credential, automatically deleted at session end.

② Risk Analysis

Per-Attribute Assessment

allergiesPenicillin, Latex🟡 Medium — medically necessary

blood_groupA+🟢 Low

insurance_statusPublic — active🟢 Low

Not requested — not shareable

Diagnosis HistoryNOT REQUESTED

Medication ListNOT REQUESTED

Mental Health DataNOT REQUESTABLE — Art. 9(1) GDPR

Genomic DataNOT REQUESTABLE — Art. 9(1) GDPR

ℹ Inference-Risiko: 🟢 Low

Allergies + blood group + insurance do not allow the hospital to draw further conclusions about identity, place of residence, or diagnoses. The combination is medically necessary and legally covered.

③ Consent & Ephemeral Proof

Release + Session Key Generation

After release, an ephemeral session key is generated. The data is encrypted with this key — at the end of the session, the key is automatically deleted (crypto-shredding).

— Waiting for release —

④ Post-Session

Data cryptographically deleted — Consent receipt issued

Consent Receipt (stored in your wallet)

VerifierUKH Innsbruck — Notaufnahme

Time—

Sharedallergies, blood_group, insurance

BasisGDPR Art. 9(2)(c)

Session Key🗑 deleted

Data available❌ no — shredded

1 / 4

Request

Deny

Break-Glass

① Verifier Request

MedUni Vienna — Research Request

🔬 MedUni Vienna — Research Dept. Trust 74/100

did:mitch:meduni-vienna-research · no HDAB certificate detected

Was wird angefragt?

health_data_pseudonymizedDiabetes Study 2025🔴 High

diagnosis_codesICD-10 subset🔴 High

medication_historylast 24 months🔴 High

Detected: Secondary use of health data (EHDS Art. 33). Verifier has no HDAB certificate.

② Policy: DENY

Request automatically denied

What must MedUni Vienna do instead?
1. Apply to the Austrian HDAB (GÖG / ELGA GmbH)
2. Submit ethics vote + data protection impact assessment
3. Data access via HDAB portal — not via individual wallets

This request was automatically logged. For repeated patterns: Report to data protection authority (DSB) possible.

③ Break-Glass Override

Emergency Override: Doctor overwrites Policy

In real emergencies, an authorized doctor can overwrite the policy. Every override is permanently stored in the audit trail — no possibility to act unnoticed.

— No override yet —

⚠ Break-glass only applies to immediate emergency treatment. Secondary use for research is not permitted even via break-glass — this flow is for treatment emergencies (Art. 9(2)(c) GDPR).

1 / 3

🏛️ Issuer (National ID System) e.g. ID Austria / EUDI Wallet

Your government issues a credential via the national eID system (ID Austria, Smart-eID, EUDI Wallet, etc.). miTch receives only signed predicates — raw PII is crypto-shredded and never stored.

⚖️ Policy Engine miTch Core

⚖️Waiting for verification request...

📱 Wallet (Your Device) User-Controlled

📱Issue a credential first

🏪 Verifier CoolShop.at

🏪Waiting for presentation...

👁️ Network Observer Adversary

👁️Monitoring traffic...

💰 Cost Comparison Real-World Estimates

💰Costs appear as you interact

🔥 Crypto-Shredding (GDPR Art. 17) Provable Deletion

🔥Issue a credential to see crypto-shredding in action

🔄 Revocation (StatusList2021) Privacy-Preserving

Issuer publishes a compressed bitstring. Verifier downloads the entire list and checks locally. Issuer cannot tell which credential was checked.

Why Your CTO Should Care

🏢 Enterprise Perspective

"The cheapest data to protect is the data you never store."
— Zero Data Architecture Principle

1. Total Cost of Ownership (Annual)

Active Users per Year 100.000

Traditional Identity Stack

User Onboarding (ID Scan)€ 150.000

PII Database (RDS+KMS+Backups)€ 36.000

GDPR Compliance Mgmt

Data Breach Reserve (Pro-rata)€ 89.000

Löschpflicht Art. 17 (2%)€ 30.000

Total/Year € 329.000

miTch Stack

eID Authentication€ 15.000

Credential Signing (HSM)€ 1.000

StatusList CDN€ 30

PII Database€ 0

Löschanfragen / Breach Risk€ 0

Total/Year € 16.030

JÄHRLICHE ERSPARNIS

€ 312.970 (95%)

📎 IBM Cost of Data Breach 2024 📎 AWS Pricing Pricing 📎 A-Trust Pricing 📎 DLA Piper GDPR Survey

2. Datenpanne im Vergleich (Data Breach)

Was passiert, wenn der Worst-Case eintritt?

Traditional IT

miTch Architecture

3. Art. 17 DSGVO — Recht auf Löschung

Traditional

miTch

PII gespeichert in

8-14 DB-Tabellen, Backups, Logs, CDN-Cache

Nirgends

Löschaufwand pro Anfrage

~€ 15 (manuell/semi-automatisch)

€ 0 (nichts da)

Zeitaufwand

3-30 Tage

0 Sekunden

Risiko unvollst. Löschung

Hoch (Backup-Fragmente, Logs)

Unmöglich

Audit-Nachweis

Manueller Report

Automatisch (Crypto-Shredding = Löschbeweis)

📋 Audit & Compliance GDPR Ready

🔗 Audit Chain

📝 Consent Log

📋 DPIA (Art. 35)

🔗Audit entries appear as you interact

Data Protection Impact Assessment — GDPR Article 35

Where We're Going

Your data life, reviewed daily.
Like a bank statement — for your privacy.

Every transaction that touches your wallet is logged — what was shared, what was withheld, what was forgotten. At the end of the day, you review your complete data flow and claims lifecycle. No pressure. No decision. Just clarity.

📅 Monday, 9 March 2026 — 4 interactions 3 clean 1 watch 1 danger

Rewe Supermarkt — Age Verification

✓ Age confirmed ✗ Name not shared ✗ Address not shared ✗ National ID not shared

Session ended · All data forgotten · Consent receipt saved

09:14

Apotheke Innsbruck — Prescription Validation

✓ Medication confirmed ✓ Dosage confirmed ✗ Diagnosis not shared ✗ Insurance ID not shared ✗ Genetic data not shared

Session ended · All data forgotten · Consent receipt saved

12:31

CoolShop.at — Age + Address Requested

✓ Age confirmed ⚠ Address: shared (you approved) ✗ National ID not shared

⚠ Address was requested beyond what age verification requires. You chose to approve.

15:47

dataportal.io — Full Identity Requested

✗ Transaction blocked Verifier not in trusted registry

🔴 Danger detected: An unverified service requested your full name, address, and national ID number without a declared legal basis. This request was blocked.

What you can do:

18:22

This is a concept preview. The daily review is on the roadmap — see below.

Why Now

The regulatory window is open.

A wave of EU legislation is creating legal rights for individuals to access their data — and compliance obligations for institutions that process it. miTch is built exactly at this intersection.

Active Now

GDPR

In force since 2018

Data minimisation. Institutions must collect only what is strictly necessary. miTch is the technical implementation of Art. 5(1)(c) and Art. 17 (right to erasure).

Active Now

PSD2 Open Banking

EU-wide since 2019

Your bank data is portable. EU banks must expose standardised APIs. You have the right to your own transaction history — in machine-readable form.

August 2025

EU AI Act

High-risk AI enforcement begins

Right to explanation. If a bank, insurer, or employer uses AI to make decisions about you, you can request a meaningful explanation of the logic involved.

September 2025

EU Data Act

IoT data portability rights

Your device data is yours. Data generated by connected devices — car, smart home, wearables — must be accessible to you. No negotiation with manufacturers needed.

2025 – 2027

EHDS

European Health Data Space

Your health records, accessible. EU regulation mandating electronic access to personal health data across all member states. Austria (Elga) is already ahead of schedule.

The Vision

Three layers. One principle:
your data belongs to you.

miTch is built in three layers, each extending user control one step further — from what you share, to what you see, to what you can prove.

Layer 1 — Built

🔐

The Forgetting Layer

Control exactly what leaves your wallet at every transaction. Everything else is cryptographically destroyed.

Selective disclosure — share only what's needed
Crypto-shredding — session keys destroyed after use
Pairwise DIDs — unlinkable across verifiers
Signed consent receipts — portable evidence
Fail-closed policy engine — deny by default

Layer 2 — Next

👁️

The Visibility Layer

See what institutions see about you. Your data, your picture — running locally on your device, never uploaded.

Daily review — your data life, timestamped
Danger levels — 🟢 clean / 🟡 watch / 🔴 block
Escalation path — DPA, lawyers, specialists
Local insight — same models institutions use
Longitudinal picture — trends over time

Layer 3 — Horizon

🔭

The Proof Layer

Prove things about yourself without revealing the underlying data. The conclusion, without the exposure.

Range proofs — "income ≥ X" without showing income
Predicate proofs — "A1c below threshold" without medical record
No raw data ever leaves the device
Verifiable by any party, privacy preserved

miTch — The Forgetting Layer

Privacy middleware for the digital identity layer.
Built for EUDI Wallet, ID Austria, eIDAS 2.0, and every national eID system that follows.
We never see your data. That's the point.

Under the Hood

27 Packages. Built for Zero-Trust.

miTch is modular by design. Our monorepo is divided into five specialized layers, each rigorously tested and hardened against modern threats.

Core (4)

State machines, base cryptographic primitives, and memory-safe utilities.

Protocol (6)

Handling mdoc (ISO 18013-5), OpenID4VP, and SD-JWT verifiable credentials securely.

Storage & Security (7)

Including the new phase0-security package and robust PQC (Post-Quantum) readiness modules.

Identity & Compliance (4)

Managing policy engines, consent tracking, and regulatory audit chains.

Demo & Testing (6)

End-to-end simulation harnesses and testing environments including the data-flow visualization package.

📋 Data Protection Impact Assessment

GDPR Article 35 — miTch Identity Verification Infrastructure

1. Description of Processing

1.1 What We Do

miTch is a privacy middleware layer for national digital identity systems (EUDI Wallet, ID Austria, Smart-eID, GOV.UK Wallet, France Identité, Swiss E-ID, Nordic eIDs, and all future eIDAS 2.0 wallets). It enables users to prove attributes (e.g., "I am over 18") without revealing raw personal data — acting as a policy engine and forgetting layer between government-issued credentials and the services that request them.

miTch does not replace national ID systems. It uses their signed credentials and adds: selective disclosure, consent management, crypto-shredding, unlinkability (pairwise DIDs), and a tamper-evident audit chain.

1.2 Roles

Role	Entity	Responsibility
Data Subject	User (Holder)	Controls all disclosure decisions via wallet
Data Controller	Verifier (e.g., shop)	Requests specific claims, processes result
Data Processor	miTch Infrastructure	Facilitates verification without accessing personal data
Issuer	State Provider	Signs credentials based on verified identity

1.3 Processing Flow

Step 1 — Issuance: Raw PII encrypted with ephemeral key, predicates derived, credential signed, key destroyed. Raw PII is mathematically irrecoverable.

Step 2 — Presentation: User selects which claims to disclose. Only selected claims sent as SD-JWT proof.

Step 3 — Verification: Verifier validates proof. Receives only disclosed predicates. Issuer is never contacted.

2. Necessity & Proportionality

Traditional Approach	miTch Approach
Upload photo ID → name, birthdate, address collected	Prove `over_18: true` → one boolean, nothing else
Data stored in verifier's database → breach risk	No data stored → nothing to breach
Identity provider tracks every verification	Issuer doesn't know when/where credentials are used
Delete request = hope they actually delete	Crypto-shredding = mathematical guarantee

3. Risk Assessment

Risk	Severity	Likelihood	Mitigation	Residual
Verifier correlation across sessions	Medium	Medium	Pairwise DIDs, timing jitter, response padding	Low
Device compromise	High	Low	Secure enclave, biometric unlock, credential expiry	Low
Issuer tracking	Medium	Low	Pre-issued credentials, issuer never contacted	Low
Network traffic analysis	Medium	Medium	Response padding (4KB), timing jitter (50-200ms)	Low
Credential replay	High	Low	Nonce binding, holder key binding, expiry	Low

4. Technical Safeguards

🔐 Cryptographic

SD-JWT Selective Disclosure: Only chosen claims revealed
Crypto-Shredding: Ephemeral keys encrypt PII → key destruction = provable data destruction
StatusList2021: Privacy-preserving revocation — issuer can't identify which credential was checked
Pairwise Ephemeral DIDs: Fresh DID per interaction — unlinkable across verifiers

🛡️ Metadata Minimization

Response Padding: All responses padded to 4KB
Timing Jitter: 50-200ms random delay
Per-Session Identifiers: HMAC-derived, unlinkable across verifiers

5. GDPR Compliance Matrix

Article	Requirement	Status	Implementation
Art. 5(1)(c)	Data minimization	✅	Selective disclosure — only requested predicates
Art. 5(1)(e)	Storage limitation	✅	Crypto-shredding — data self-destructs
Art. 7	Consent conditions	✅	Informed, specific, freely given, withdrawable
Art. 17	Right to erasure	✅✅	Crypto-shredding provides mathematical proof of destruction
Art. 25	Privacy by design	✅✅	Core architecture — not an add-on
Art. 30	Processing records	✅	ROPA with aggregate counts, no PII
Art. 35	DPIA	✅	This document

6. What miTch Structurally Cannot Do

These are architectural guarantees, not policy promises:

🚫 Cannot store raw PII — ephemeral keys destroyed after issuance
🚫 Cannot track credential usage — issuer never contacted during verification
🚫 Cannot see what users share — selective disclosure happens on-device
🚫 Cannot correlate users across verifiers — pairwise ephemeral DIDs
🚫 Cannot recover shredded data — encryption key no longer exists

"miTch works not because it knows everything — but because it structurally cannot know anything."

miTch — The Forgetting Layer

DPIA Version 1.0 — March 2026

🔒 miTch — The Forgetting Layer

Your data builds a picture of you.
You're the only one who can't see it.

How It Works

1. Issuer

2. Wallet

3. Policy Engine

4. Verifier

Verifier asks. miTch filters. You decide.

Traditional ID Verification

miTch Verification

🏢 Enterprise Perspective

1. Total Cost of Ownership (Annual)

Traditional Identity Stack

miTch Stack

2. Datenpanne im Vergleich (Data Breach)

Traditional IT

miTch Architecture

3. Art. 17 DSGVO — Recht auf Löschung

Your data life, reviewed daily.
Like a bank statement — for your privacy.

The regulatory window is open.

Three layers. One principle:
your data belongs to you.

27 Packages. Built for Zero-Trust.

📋 Data Protection Impact Assessment

1. Description of Processing

1.1 What We Do

1.2 Roles

1.3 Processing Flow

2. Necessity & Proportionality

3. Risk Assessment

4. Technical Safeguards

🔐 Cryptographic

🛡️ Metadata Minimization

5. GDPR Compliance Matrix

6. What miTch Structurally Cannot Do

🔒 miTch — The Forgetting Layer

Your data builds a picture of you.You're the only one who can't see it.

How It Works

1. Issuer

2. Wallet

3. Policy Engine

4. Verifier

Verifier asks. miTch filters. You decide.

Traditional ID Verification

miTch Verification

🏢 Enterprise Perspective

1. Total Cost of Ownership (Annual)

Traditional Identity Stack

miTch Stack

2. Datenpanne im Vergleich (Data Breach)

Traditional IT

miTch Architecture

3. Art. 17 DSGVO — Recht auf Löschung

Your data life, reviewed daily.Like a bank statement — for your privacy.

The regulatory window is open.

Three layers. One principle:your data belongs to you.

27 Packages. Built for Zero-Trust.

Verification Complete — Data Forgotten

📋 Data Protection Impact Assessment

1. Description of Processing

1.1 What We Do

1.2 Roles

1.3 Processing Flow

2. Necessity & Proportionality

3. Risk Assessment

4. Technical Safeguards

🔐 Cryptographic

🛡️ Metadata Minimization

5. GDPR Compliance Matrix

6. What miTch Structurally Cannot Do

Your data builds a picture of you.
You're the only one who can't see it.

Your data life, reviewed daily.
Like a bank statement — for your privacy.

Three layers. One principle:
your data belongs to you.