Az EU életkor-igazoló tanúsítvány integrálása: fejlesztői útmutató az eu.europa.ec.av.1 névtérhez

Ha az EU megoldásával szemben integrálsz életkor-ellenőrzést, egy string fog megjelenni a kódodban gyakrabban, mint bármelyik másik: eu.europa.ec.av.1. Ez az „életkor-igazolás” (Proof of Age) tanúsítvány névtere, és annak megértése, hogy mi ez — és mi az, ami szándékosan nem —, a helyes integráció alapja.

Ez az útmutató az EU életkor-ellenőrző alkalmazás koncepcionális bemutatásának gyakorlati párja. Itt a protokoll és az adatmodell szintjén maradunk: a credential-formátum, a kibocsátási folyamat, és hogyan kösd a kódodat az élő referencia-kibocsátóhoz.

A tanúsítvány, pontosan

Az EU hivatalos életkor-ellenőrzési kibocsátója egy (Q)EAA-szolgáltató — (minősített) elektronikus attribútumtanúsítványok szolgáltatója, az eIDAS 2.0 értelmében. Megvalósítja az életkor-ellenőrzési specifikációt, és egy „életkor-igazolás” (Proof of Age) tanúsítványt bocsát ki a következő meghatározó tulajdonságokkal:

• Formátum: mso_mdoc — az ISO/IEC 18013-5 mobildokumentum-formátum, ugyanaz a család, amelyet a mobil vezetői engedélyek és az EUDI Tárca PID-je is használ. Ha elolvastad a Hogyan működik az eIDAS-verifikáció cikket, ez az alatta lévő credential-formátum.
• Névtér: eu.europa.ec.av.1. A tanúsítvány minden claimjét ez a névtér minősíti. A verzió magába a névtérbe van beégetve — a záró .1 —, így egy jövőbeli, törést okozó változás eu.europa.ec.av.2 lesz, és a kódod ágazhat rá.
• Szemantika: megerősíti, hogy a birtokos egy adott életkori küszöb fölött van, anélkül hogy felfedné a születési dátumot. Ez a teljes lényeg. A tanúsítvány azt válaszolja meg, hogy „elmúlt-e ez a személy N éves?”, és semmi mást.

eIDAS-fogalmakkal ez a rendelet 3. cikk (44) bekezdése szerinti elektronikus attribútumtanúsítvány. Ez a jogi keretezés nem dísz — ez teszi lehetővé, hogy egy életkor-igazoló prezentáció jogi súlyt hordozzon a határokon át, ugyanúgy, ahogy az identitás határon átnyúló verifikációja teszi.

Miért névtér, és nem egyszerűen „életkor ≥ 18”

Az újoncok gyakran kérdezik, miért csomagolta az EU valami olyan egyszerűt, mint egy 18-on-túli logikai érték, egy formális mdoc-névtérbe. Három ok, mindegyik munkát spórol neked később:

1. Több küszöb, egy modell. Az életkori kapuk nem mind 18-asok. Az alkohol, a szerencsejáték, bizonyos tartalmak és a „gyermekeknek szóló szolgáltatás” szabályai a 16-ot, 18-at, 21-et és másokat használnak. Egy névterezett tanúsítvány a küszöb-claimeket egységesen tudja kifejezni, ahelyett hogy minden ellenőrző felet arra kényszerítene, hogy kitalálja a saját kódolását.
2. Ellenőrizhető eredet. Mivel a claim egy aláírt mdoc-on belül helyezkedik el, a verifiered egy aláírást és egy bizalmi láncot ellenőriz — nem egy önbevallott értéket. Az aláírás az, ami alapvetően mássá teszi ezt, mint az életkori jelölőnégyzet, amelyet levált.
3. Konstrukcióból fakadó összekapcsolhatatlanság. A szabványos tanúsítvány egyszer használatos és kötegekben bocsátják ki, kifejezetten azért, hogy az ismételt prezentációkat ne lehessen profillá összekapcsolni. Erre lentebb visszatérünk, mert ez a rendszer leggyakrabban túlállított tulajdonsága.

Kibocsátás: OpenID4VCI

A kibocsátó az OpenID for Verifiable Credential Issuance (OpenID4VCI) protokollt követi. Ha a csapatod dolgozott már az OpenID4VP-vel a prezentációhoz, a VCI annak kibocsátás-oldali testvére: ahol a VP az, ahogyan egy credentialt bemutatnak neked, ott a VCI az, ahogyan az egyáltalán bekerül a tárcába.

A folyamat azon a szinten, amelyen érvelned kell róla:

1. Egy felhasználó onboardol az életkor-ellenőrző alkalmazásba vagy tárcába, egyszer igazolva az életkorát egy megbízható forráson keresztül (egy eID, vagy — a blueprint v2 óta — egy útlevél vagy nemzeti személyazonosító igazolvány).
2. A tárca OpenID4VCI-cserét futtat a kibocsátóval, hogy egy köteg életkor-igazoló tanúsítványt szerezzen.
3. A kötegben minden tanúsítvány egyszer használatos. Ahogy a felhasználó idővel igazolásokat mutat be, a tárca leapasztja a köteget, és szükség szerint frissít.

Integráló ellenőrző félként általában nem te üzemelteted a kibocsátási oldalt — az a (Q)EAA-szolgáltató feladata. De ennek megértése megmagyarázza azokat a tulajdonságokat, amelyeket a prezentáció idején megfigyelsz: rövid életű, egyszer használatos igazolások, stabil azonosító nélkül, amelyre kulcsolhatnál.

Az élő referencia-kibocsátó — és a kikötés, ami számít

Az EU közzétesz egy működő referenciaimplementációt. A kibocsátó háttérrendszere (av-srv-web-issuing-avw-py) nyílt forráskódú a hivatalos EU Digital Identity Wallet GitHub-szervezet alatt, az Európai Bizottság szerzői jogával, és van egy élő, nyilvánosan hosztolt referencia-kibocsátó, amelyet a fejlesztés során gyakorolhatsz.

Ezt olvasd el figyelmesen: ez egy referencia- és tesztimplementáció. Kifejezetten nem éles-kész, polgári minőségű kibocsátó. Használd az integrációd, a credential-elemzésed és a prezentációs folyamatod validálására. Ne építs olyan indítási tervet, amely feltételezi, hogy ez az éles végpont, amelyet a valódi felhasználóid el fognak érni — az a végpont a nemzeti életkor-ellenőrző alkalmazások és tárcák lesznek, amelyeket az éllovas tagállamok vezetnek be. Kezeld a referencia-kibocsátót úgy, ahogyan bármelyik sandboxot kezelnéd: felbecsülhetetlen az építéshez, de nem éles függőség.

A magánéletvédelmi állítás, pontosan megfogalmazva

Itt válnak el a gondos mérnökök a marketingszövegtől. Olvasni fogod, hogy az EU életkor-ellenőrzési megoldása zero-knowledge bizonyításokat (ZKP-t) használ, hogy egy ellenőrző fél csak egy igen/nem választ tudjon meg, az összekapcsolás bármilyen lehetősége nélkül. Légy pontos:

• Ami szilárd: a szabványos mdoc-tanúsítvány egyszer használatos és kötegekben kibocsátott, kifejezetten az összekapcsolhatóság megakadályozására. Az igazolás a küszöbön túli státuszt fedi fel, nem a születési dátumot vagy az identitást. Ez valódi, leszállított magánéletvédelmi tulajdonság.
• Amivel óvatosnak kell lenni: a ZKP-t a verifier-útmutatóban támogatott, preferált bizonyítástípusként írják le — nem mint univerzálisan leszállított, teljesen összekapcsolhatatlan garanciát, amelyet valamelyik melléklet specifikál. Ne írj olyan dokumentációt, amely azt állítja, hogy „a rendszer zero-knowledge, ezért az összekapcsolás lehetetlen”. Írd ezt: „az összekapcsolhatatlanságot egyszer használatos, kötegekben kibocsátott igazolások biztosítják; a ZKP fokozott bizonyítástípusként támogatott.”

Ez nem szőrszálhasogatás. Ha a megfelelőségi narratívád olyan kriptográfiai garanciát állít, amelyet a bevetett rendszer még nem nyújt egységesen, akkor ez az az állítás, amelyen egy auditor rángat majd. Az őszinte verzió így is kiváló magánéletvédelmi narratíva — lásd a Magánélet-első életkor-ellenőrzés cikket arról, hogyan keretezzük.

Egy minimális integrációs ellenőrzőlista

A 6. lépés visszaköti ezt a fejlesztői feladatot az ellenőrző felek regisztrációja és a WRPAC kötelezettségekhez. Az az ellenőrző fél, amely csak életkor-igazolásra regisztrál, szerkezetileg képtelen túlkérdezni — ami a lehető legtisztább válasz egy adatvédelmi szabályozónak.

A lényeg

Az eu.europa.ec.av.1 névtér méretében kicsi, következményeiben nagy. Ez egy mso_mdoc, 3. cikk (44) bekezdés szerinti tanúsítvány, OpenID4VCI fölött kibocsátva, amely egy életkori küszöböt igazol, és semmi mást. Építs az élő referencia-kibocsátóval szemben, hogy az elemzésed és a prezentációs folyamatod helyes legyen — de kezeld sandboxként, ne élesként. És amikor a magánéletvédelmi tulajdonságokat dokumentálod, azt írd le, ami leszállított (egyszer használatos, kötegekben kibocsátott, csak küszöb), nem azt, ami vágyott (univerzális ZKP). Csináld jól ezt a kettőt, és az integrációd túléli a valódi tárcákkal és a valódi auditorokkal való találkozást is.

Ez a bejegyzés az EU életkor-ellenőrzési specifikációjának és referenciaimplementációjának 2026 júniusi állapotát tükrözi. A referencia-kibocsátó tesztimplementáció, nem éles. Ellenőrizd a credential-sémát a hivatalos kibocsátói repozitóriummal szemben, mielőtt építenél.