DC API, OpenID4VP, ZKP: a futásidejű fallback-mátrix, amelyet minden életkor-ellenőrző verifiernek implementálnia kell

Egyetlen tervezési döntés választja el azt az életkor-ellenőrző verifiert, amely mindenkinél működik, attól, amely a legtöbb embernél működik: hogyan tér vissza alternatívára (fallback). Az EU életkor-ellenőrzési verifier-útmutatója ezt nem bízza ízlésre. Egyértelműen kimondja, hogy egy verifiernek egynél több prezentációs mechanizmust kell támogatnia, és futásidőben a legjobb elérhető lehetőséget kell kiválasztania. Implementáld csak a boldog ösvényt, és csendben kizársz minden olyan felhasználót, akinek a böngészője vagy eszköze nem támogatja azt.

Ez a bejegyzés felvázolja a fallback-mátrixot, hogy miért létezik, és hogyan érvelj róla anélkül, hogy túlállítanád a verem tetején lévő magánéletvédelmi tulajdonságokat.

Két mechanizmus, két bizonyítástípus

A mátrixnak két tengelye van.

Prezentációs mechanizmus — hogyan jut el a kérés a tárcához, és hogyan jön vissza a válasz:

• DC API (Digital Credentials API) — egy böngészőbe integrált API. A böngésző közvetlenül közvetíti a credential-kérést, ami a legsimább felhasználói élményt adja. Ez az elsődleges módszer, és egyre inkább elérhető a modern operációs rendszerekben és böngészőkben.
• OpenID4VP (OpenID for Verifiable Presentations) — az OpenID-alapú protokoll ellenőrizhető prezentációk kérésére és fogadására. Ez a fallback, amelyet akkor használnak, amikor a felhasználó böngészője nem támogatja a DC API-t. Ha előbb a protokoll alapjaira vagy kíváncsi, kezdd az OpenID4VP protokoll megértése cikkel.

Bizonyítástípus — milyen kriptográfiai formát ölt a bizonyíték:

• Szabványos mdoc-tanúsítvány — az aláírt mso_mdoc életkor-igazolás, egyszer használatossá téve és kötegekben kibocsátva az összekapcsolhatóság korlátozására.
• ZKP (zero-knowledge bizonyítás) — egy fokozott bizonyítástípus, amely erősebb magánéletvédelmi tulajdonságokat kínál, és ahol elérhető, preferált lehetőségként kezelik.

Az útmutató ezt futásidejű preferenciasorrendként keretezi — a legerősebb magánélet + legjobb UX elöl, kecsesen leromolva:

A verifierednek a kombinációkat kell támogatnia, nem csak a kedvencét, és azt a legmagasabb prioritású lehetőséget kell választania, amelyet az adott eszköz ténylegesen ki tud elégíteni.

Miért nem opcionális a fallback

Csábító csak DC-API-t szállítani, és azt mondani a hosszú farok felhasználóinak, hogy frissítsék a böngészőjüket. Három ok, amiért ne:

1. Lefedettség. A DC API egyre inkább elérhető — ami pontosan az a megfogalmazás, amely azt jelenti, hogy még nem univerzálisan elérhető. Minden olyan felhasználó, akinek a böngészőjéből vagy operációs rendszeréből hiányzik, egy elbukott életkor-ellenőrzés, ha nincs fallbacked. Egy életkori kapunál az elbukott ellenőrzés nem leromlott élmény; egy blokkolt tranzakció.
2. Az útmutató megköveteli. A „a verifierednek minden kombinációt támogatnia kell” nem tanácsadó jellegű. Egy szabványkövető EU életkor-ellenőrző verifier implementálja a fallbacket.
3. A kecses leromlás megbízhatósági tulajdonság. Ugyanaz a fegyelem, amelyet bármely reziliens integrációra alkalmazunk — feltételezni, hogy a legjobb út elérhetetlen lehet, és rendelkezni egy tesztelt második úttal — itt is érvényes. Az OpenID4VP-fallback a te második utad.

A magánéletvédelmi sorrend, őszintén megfogalmazva

A ZKP-t az 1. prioritásra tenni helyes, de az, hogy hogyan írod le az érdekelteknek, az a pont, ahol a csapatok bajba kerülnek. Légy pontos azzal kapcsolatban, hogy mi a leszállított, és mi a preferált:

• Leszállított és valós: a szabványos mdoc-bizonyíték egyszer használatos és kötegekben kibocsátott, és csak a küszöbön túli státuszt fedi fel — nem a születési dátumot, nem az identitást. Ez önmagában meghiúsítja az „ugyanazt a credentialt kétszer bemutatták” naiv összekapcsolási támadását.
• Preferált, nem univerzális: a ZKP-t támogatott, preferált bizonyítástípusként sorolják fel. Ne dokumentáld a rendszeredet úgy, mint „zero-knowledge, ezért konstrukcióból összekapcsolhatatlan”, hacsak a konkrét bevetés, amellyel integrálsz, ténylegesen nem szállít ZKP-t a kérdéses tranzakcióra. A pontos mondat: „Ahol a ZKP elérhető, ott preferáljuk; egyébként az összekapcsolhatatlanság egyszer használatos, kötegekben kibocsátott mdoc-bizonyítékokon nyugszik.”

Ugyanezt a gondos megkülönböztetést tesszük az életkor-igazoló tanúsítványról szóló fejlesztői útmutatónkban és a Magánélet-első életkor-ellenőrzés cikkben. Azért számít, mert egy magánéletvédelmi állítás egy megfelelőségi állítás, és egy túlállított állítás felelősség.

A futásidejű kiválasztás implementálása

A logika, amelyet a verifiered minden tranzakción, fogalmilag, futtat:

1. Detektáld a DC API jelenlétét. Kínálja-e ez a böngésző? Ha igen, preferáld.
2. Egyezz meg a bizonyítástípusban. A DC API-n belül kérj ZKP-bizonyítékot; fogadj el szabványos mdoc-ot, ha a ZKP nem elérhető.
3. Térj vissza OpenID4VP-re, amikor a DC API hiányzik, szabványos mdoc-bizonyítékkal.
4. Validálj a hozzáférés megadása előtt. Úttól függetlenül a bemutatott bizonyítékot validálni kell az EU Age Verification Trusted Listtel szemben, mielőtt átengeded a felhasználót. Ez a validálási lépés saját téma — lásd társcikkünket az életkor-igazolásnak a megbízhatósági listával szembeni validálásáról.
5. Kezeld a bizonyítékot egyszer használatosként. Ne tárold, ne játszd vissza, ne vezess le belőle stabil azonosítót. Ha mégis, akkor visszahoznád pontosan azt az összekapcsolhatóságot, amelynek megakadályozására a kötegelt kialakítás létezik.

Figyeld meg, hogy az 1–3. lépés a tárca eléréséről szól, a 4–5. lépés pedig a válasz megbízásáról és kezeléséről. Egy helyes verifier mindkettőt elvégzi. Egy gyakori hibamód, amikor a csapatok eltalálják a kérésútvonalat, majd rosszul kezelik a bizonyítékot — eltárolják „auditra”, ami csendben egy magánéletvédő ellenőrzést egy követési rekorddá alakít.

Hogyan illeszkedik ez a nagyobb képbe

A fallback-mátrix annak a folyamatnak a verifier-oldali mechanikája, amely az ellenőrzőfél-identitás oldalán a WRPAC-regisztrációtól függ: a verifiered regisztrált ellenőrző félként hitelesíti magát, a kérést DC API-n vagy OpenID4VP-n keresztül intézi, bizonyítékot kap, validálja a megbízhatósági listával szemben, és megadja vagy megtagadja a hozzáférést. Annak teljesebb összehasonlításáért, hogy ez a verifier-modell miben különbözik a hagyományos identitás-ellenőrzésektől, az EUDI Tárca vs. KYC fejlesztői összehasonlításunk egymás mellé állítja a kettőt.

A lényeg

A verifier-útmutató ad neked egy preferenciasorrendet — DC API + ZKP, aztán DC API + mdoc, aztán OpenID4VP + mdoc — és egy utasítást: támogasd a kombinációkat, és válaszd a legjobbat futásidőben. A DC API adja az élményt; az OpenID4VP adja a lefedettséget; a bizonyítástípus-sorrend adja a magánéletet. Szállítsd csak a mátrix tetejét, és olyan életkori kaput szállítasz, amely pontosan azoknál a felhasználóknál bukik el, akik a legkevésbé valószínű, hogy a legmodernebb böngészőn vannak. Szállítsd az egész mátrixot, írd le a ZKP-tulajdonságot őszintén, és kezelj minden bizonyítékot egyszer használatosként — és olyan verifiered lesz, amely helyes, befogadó és védhető.

Ez a bejegyzés az EU életkor-ellenőrzési verifier-útmutatójának 2026 júniusi állapotát tükrözi. A futásidejű fallback és a bizonyítástípus-sorrend a hivatalos verifier-útmutatón nyugszik; ellenőrizd az aktuális specifikációval szemben, mielőtt implementálnál.