OpenID4VP 1.0: mit jelent a szabványváltás a DÁP-csatlakozó szervezetek számára?

1. Mi történt, és miért kötelező lépni?

A 2024/2977 EU végrehajtási rendelet és az EUDI Wallet keretrendszer egységes, tagállamok közötti interoperabilitást ír elő. Ennek feltétele, hogy minden szereplő a végleges szabványokat kövesse: a magyar megoldásnak az OpenID4VP 1.0 specifikációt és a kapcsolódó EU-s profilokat kell követnie. A draft 22 — mint minden draft státuszú specifikáció — átmeneti állapot volt: éles, hosszú távon üzemeltetett szolgáltatásban nem tartható fenn.

A gyakorlati következmény: a DÁP oldalán egylépéses átállás („hard switch”) várható. Ez azt jelenti, hogy egy adott naptól a rendszer kizárólag az 1.0-s szabvány szerinti üzeneteket fogadja el. Aki addig nem készül fel, annak az eAzonosítás-integrációja azon a napon leáll. A konkrét dátumok még nem véglegesek — de a felkészülési munka mérete miatt éppen ez a legjobb érv arra, hogy a tervezést ne a dátum kihirdetése után kezdje el egy szervezet.

2. Miért nem kétnapos feladat?

A két verzió több ponton sem kompatibilis visszafelé. Ez nem verziószám-átírás, hanem az integráció több rétegét érintő átalakítás. Néhány példa, üzleti nyelvre fordítva:

1. 1

   Kicserélődik a lekérdezési nyelv

   Az eddigi Presentation Exchange formátumot a DCQL váltja. A kérések felépítését, a válaszok feldolgozását és a kapcsolódó üzleti logikát át kell írni, majd újratesztelni.

2. 2

   Megváltozik a szervezet digitális azonosítása

   A verifier-azonosítás új, tanúsítvány-hash alapú sémára (x509_hash) áll át. Ez a kérések összeállítását és a válaszok ellenőrzését is érinti.

3. 3

   Átalakul a válaszszerkezet és a hibakezelés

   A korábbi összerendelési mechanizmus megszűnik, és mintegy 25 új hibakód jelenik meg. Ezeket a naplózásban és az üzleti folyamatokban is kezelni kell.

4. 4

   Migrációs stratégiát kell választani

   Vagy egy alkalmazás támogatja párhuzamosan mindkét verziót, vagy két külön implementáció fut, és az átállás napján történik a forgalomátirányítás.

Mindez fejlesztést, átfogó újratesztelést és megfelelőségi ellenőrzést igényel — miközben a régi verziónak a hard switch napjáig hibátlanul üzemelnie kell. Egyik migrációs stratégia sem triviális, és mindkettő érdemi tervezést, fejlesztői kapacitást és üzemeltetési felkészülést igényel.

3. Várhatóan nem ez az utolsó változás

Az EUDI-ökoszisztéma EU-szinten fejlődik, és a mostani migrációs dokumentáció már nevesíti a következő változásokat: a visszavonás-ellenőrzés jelenlegi mechanizmusát a jövőben az IETF Token Status List válthatja fel, a bizalmi listák terén pedig új formátum bevezetése van folyamatban.

Ez a felismerés a kulcs a stratégiai döntéshez.

4. Egyedi fejlesztés vagy kész megoldás?

Sok szervezetnél érthető a reakció: „az integráció már fut vagy elkészült, nem akarjuk újranyitni a projektet.” A kérdés azonban nem az, hogy újra kell-e nyitni — a szabványváltás miatt mindenképpen hozzá kell nyúlni. A valódi kérdés az, hogy kinél legyen a következő években a karbantartás terhe.

5. A megtérülés legfontosabb szempontjai

A döntést érdemes több évre számított TCO alapon meghozni, és nem csak a mostani migráció egyszeri költsége alapján.

A döntési logika egyszerű: az egyedi fejlesztés ára nem a mostani projekt, hanem a mostani projekt szorozva a jövőbeni szabványváltások számával, plusz a folyamatos készenlét költsége. Egy szűk, gyorsan változó szakterületen ez jellemzően csak akkor éri meg, ha a digitális identitás a szervezet alaptevékenysége.

6. Kérdések, amelyeket most érdemes feltenni

Akár házon belül készült az integráció, akár külső fejlesztő szállította, az alábbi kérdések gyorsan megmutatják, hol tart a szervezet:

7. Készüljön fel időben az átállásra

A TrustID Solutions kész, folyamatosan karbantartott megoldást kínál a DÁP eAzonosítás és a HAASZ adatszolgáltatás integrációkhoz, amelyekben a szabványkövetés — beleértve a mostani OpenID4VP 1.0 átállást — a termék része.