Az OpenID4VP megértése: az EU digitális személyazonosság-tárcái mögötti protokoll

Mi az az OpenID4VP?

Az OpenID for Verifiable Presentations (OpenID4VP) az a protokoll, amely lehetővé teszi, hogy az EU digitális személyazonosság-tárcái ellenőrzött attribútumokat osszanak meg a vállalkozásokkal, azaz az igénybe vevő felekkel (Relying Parties). Ez az eIDAS 2.0 alapú személyazonosság-ellenőrzési folyamat technikai gerince.

Amikor egy felhasználó a pénztárnál beszkennel egy QR-kódot, és a tárcája visszaküldi, hogy "ez a személy 18 évesnél idősebb", az az adatcsere OpenID4VP-n keresztül történik.

Az ellenőrzési folyamat

Az OpenID4VP folyamat négy szereplőt érint:

1. Kibocsátó: a kormányzati vagy megbízható hatóság, amely kiadta a hitelesítő adatot (például az osztrák állam nemzeti igazolványt ad ki)
2. Birtokos: az állampolgár, akinél az EUDI Tárca van a telefonján
3. Ellenőrző (Relying Party): a vállalkozás, amely az ellenőrzést kéri (webshop, KYC-rendszer stb.)
4. Bizalmi keretrendszer: az EU bizalmi listái, amelyek meghatározzák, mely kibocsátók és ellenőrzők tekinthetők legitimnek

A folyamat lépésről lépésre

1. Az ellenőrző létrehoz egy Authorization Requestet
   ↓
2. A kérés QR-kódba (vagy deep linkbe) kerül
   ↓
3. A birtokos az EUDI Tárcával beszkenneli a QR-kódot
   ↓
4. A tárca értelmezi a kérést, és megmutatja, mit kérnek
   ↓
5. A birtokos áttekinti, majd biometriával/PIN-nel jóváhagyja
   ↓
6. A tárca létrehoz egy Verifiable Presentationt (VP)
   ↓
7. A VP elküldésre kerül az ellenőrző válaszvégpontjára
   ↓
8. Az ellenőrző kriptográfiailag validálja a VP-t
   ↓
9. Az ellenőrzött attribútumok kinyerésre és felhasználásra kerülnek

Két hitelesítőformátum

Az EUDI Tárcák két hitelesítőformátumot támogatnak, eltérő kriptográfiai ellenőrzési útvonallal:

SD-JWT VC (Selective Disclosure JWT)

Távoli ellenőrzési folyamatoknál használják (online, több eszköz között). A hitelesítő adat egy JSON Web Token szelektív közzétételi képességekkel.

• Formátum: JSON-alapú
• Szelektív közzététel: hash-alapú sózás; a kibocsátó minden állítást aláír, de a birtokos csak a kiválasztottakat fedi fel
• Aláírás: JWS (JSON Web Signature) ES256-tal
• Ellenőrzés: JWT feldolgozása -> disclosure elemek újraépítése -> hash-ek ellenőrzése -> aláírás validálása -> a kibocsátó bizalmi láncának ellenőrzése

Header.Payload.Signature~Disclosure1~Disclosure2~KeyBindingJWT

mdoc / mDL (Mobile Document)

Közelségi ellenőrzési folyamatoknál használják (személyes jelenlét, NFC, BLE). Az ISO 18013-5 szabványra épül.

• Formátum: CBOR-alapú (bináris)
• Szelektív közzététel: az adatszerkezetbe építve, névterekkel és adatelemekkel
• Aláírás: COSE (CBOR Object Signing and Encryption)
• Ellenőrzés: CBOR dekódolás -> COSE-aláírás ellenőrzése -> eszközhitelesítés validálása -> a kibocsátó tanúsítványláncának ellenőrzése

Mindkét formátum ugyanazt a célt szolgálja: kriptográfiailag bizonyítani, hogy egy megbízható kibocsátó meghatározott állításokat tett a birtokosról, de technikailag eltérő módon.

WRPAC: az ellenőrző tanúsítványa

Az ellenőrzési kérés kibocsátásához az igénybe vevő félnek WRPAC-ra (Wallet Relying Party Access Certificate) van szüksége. Ezt az ETSI TS 119 475 definiálja, és:

• azonosítja az igénybe vevő felet a tárca számára
• meghatározza, mely attribútumokat kérheti az RP
• minősített bizalmi szolgáltató bocsátja ki
• az EU bizalmi listái alapján kell validálni

A tárca még a hozzájárulási képernyő megjelenítése előtt ellenőrzi a WRPAC-ot. Ha a tanúsítvány érvénytelen, lejárt vagy nincs a bizalmi listán, a tárca elutasítja a kérést.

EU bizalmi listák

Az EU hierarchikus bizalmi infrastruktúrát tart fenn:

EU List of Trusted Lists (LOTL)
  └── Country Trusted List (pl. Luxembourg)
       └── Trust Service Provider (pl. LuxTrust)
            └── Trust Service (pl. WRPAC-kibocsátás)
                 └── Certificate (az Ön WRPAC-ja)

Az SDK-nak végig kell járnia ezt a hierarchiát annak igazolására, hogy a WRPAC-tanúsítványt egy legitim szolgáltató bocsátotta ki egy elismert tagállamban. Ez a megvalósítás egyik legösszetettebb része: a bizalmi listák XML/JSON formátuma önálló feldolgozási szabályokat igényel, és a listákat az egyes tagállamok egymástól függetlenül frissítik.

Privacy by design

Az OpenID4VP protokollszinten érvényesíti az adatvédelmet:

• Szelektív közzététel: a birtokos pontosan megválasztja, mely attribútumokat osztja meg. Az age_over_18 kérése nem fedi fel a születési dátumot.
• Nincs korreláció: minden ellenőrzési munkamenet friss kriptográfiai anyagot használ, így az ellenőrzők nem tudják összekapcsolni a munkameneteket.
• Birtokosi hozzájárulás: minden attribútumkéréshez kifejezett felhasználói jóváhagyás kell az eszközön.
• Adatminimalizálás: a protokoll azt ösztönzi, hogy csak a szükséges adatokat kérjék. A tárca felülete láthatóvá teszi a túlzott adatbekérést.

Ez alapvetően különbözik a hagyományos KYC-tól, ahol a vállalkozások gyakran a szükségesnél több adatot kapnak, majd tárolnak.

Hogyan valósítja meg ezt az OpenEUDI

Az OpenEUDI SDK a protokoll összetettségét egy tiszta API mögé rejti:

import { createVerifier } from '@openeudi/core';

const verifier = createVerifier({
  mode: 'production',
  wrpac: {
    certificate: process.env.WRPAC_CERT,
    privateKey: process.env.WRPAC_KEY,
  },
  trustList: {
    lotlUrl: 'https://ec.europa.eu/tools/lotl/eu-lotl.xml',
    refreshInterval: 86400, // 24 óra
  },
});

Belsőleg az SDK:

1. létrehoz egy specifikációnak megfelelő Authorization Requestet
2. QR-kódba kódolja azt, testreszabható megjelenéssel
3. előkészít egy válaszvégpontot a tárca VP-jének fogadásához
4. validálja a VP-t a megfelelő formátumkezelővel (SD-JWT vagy mdoc)
5. ellenőrzi a kibocsátó tanúsítványát az EU bizalmi listái alapján
6. csak a kért attribútumokat emeli ki és adja vissza
7. törli a memóriából a kriptográfiai anyagokat

Mindez a verifier.createSession() és a session.onVerified() mögött történik.

Határokon átnyúló megfelelőség

Az EU tagállamai bizonyos mozgástérrel rendelkeznek abban, hogy mely attribútumok kérhetők és milyen feltételek mellett. Például:

• az életkor-küszöbök termékkategóriánként és országonként eltérnek
• egyes országok korlátozzák bizonyos attribútumok kiadását
• a nemzeti tárcamegvalósítások eltérő hitelesítési sémákat használhatnak

Az OpenEUDI egy géppel olvasható megfelelőségi térképet (JSON) tartalmaz mind a 27 tagállamhoz, így a fejlesztők az attribútumigénylés előtt ellenőrizhetik az elérhetőséget.

Mi jöhet ezután a protokollban

Az OpenID4VP specifikáció továbbra is fejlődik az OpenID Foundation munkacsoportjában. Az aktív fejlesztési területek közül néhány:

• Presentation Exchange 2.0: rugalmasabb módszerek a megfelelő hitelesítő adatok leírására
• Státuszállítások: a hitelesítő adatok visszavonásának valós idejű ellenőrzése
• Több eszközös folyamatok fejlesztése: jobb UX mobilról asztali gépre történő ellenőrzésnél
• Kötegelt ellenőrzés: több hitelesítő adat ellenőrzése egyetlen folyamatban

Az OpenEUDI verziózott protokolladapter-mintával fogja követni ezeket a változásokat, így a nyilvános API stabil marad, miközben a belső kezelők a specifikáció új verzióihoz igazodnak.

---

Az OpenEUDI az EUDI Tárca ökoszisztémához valósítja meg az OpenID4VP-t. Az SDK MIT licencű és ingyenesen használható. Az éles bevezetésekhez menedzselt WRPAC-tanúsítványokkal tekintse meg az eIDAS Pro menedzselt csomagjait.

Kapcsolódó cikkek

OpenEUDI SDK gyorsindító: az első ellenőrzése 5 perc alatt

Lépésről lépésre bemutató az OpenEUDI SDK telepítéséhez, egy ellenőrzési munkamenet létrehozásához és az eredmény kezeléséhez, mindez 5 percen belül DEMO módban.

6 perc olvasás

Hogyan működik az eIDAS-ellenőrzés: Technikai mélyelemzés

Átfogó technikai áttekintés az eIDAS ellenőrzési folyamatról a QR-kód generálástól az attribútum-validálásig, beleértve a protokollokat, biztonsági intézkedéseket és integrációs mintákat.

12 perc olvasás