JSON-LD elmagyarázva
A JSON-LD közönséges JSON egyetlen plusz sorral, amely megmondja, mit jelentenek a mezők. Ez a sor egy helyi mezőnevet globálisan definiálttá tesz, így egy rendszer, amely még sosem látta az adatait, mégis ki tudja következtetni, miről beszél. 2014 óta W3C-szabvány, így olvassák a keresőmotorok éppen ezt az oldalt, és erre épül a W3C adatmodellje az ellenőrizhető hitelesítő adatokhoz.
Az egyszerű JSON problémája
A JSON megmondja, hogyan írjuk le az adatokat. Arról semmit nem mond, hogy bármelyikük mit jelent. Egy name nevű mező lehet személy, cég vagy termék. Egy id nevű mező lehet ügyfélszám, útlevélszám vagy egy sor valakinek az adatbázisában. Két rendszer egyaránt kibocsáthat tökéletesen érvényes JSON-t, és mégis minden egyes mezőjén vitatkozhatnak.
A gyakorlatban ezt a rést megállapodás zárja be. A két fél leírja, mit jelentenek a mezők, és ehhez építi a szoftverét. Ez működik egy integrációnál, drágává válik tíznél, és teljesen megszűnik működni, amikor egy országban kiállított hitelesítő adatot egy másik ország ellenőrzőjének kell megértenie, akivel előzetesen senki nem beszélt.
Mit csinál a @context
A JSON-LD magán a dokumentumon belül zárja be ezt a rést. Egy @context minden rövid mezőnevet egy világszinten egyedi azonosítóhoz rendel, rendszerint egy URL-hez, amelyet az felügyel, aki a szótárat definiálta. A mező rövid és ember számára olvasható marad, a gép számára pedig egyértelművé válik.
Egyszerű JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Érvényes, olvasható és jelentés nélküli mindenkinek, akinek senki nem mondta el előre, mit kellene a mezőknek tartalmazniuk.
Ugyanazok az adatok JSON-LD-ként
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Minden mező most egy közzétett definícióra mutat, így egy rendszer, amely még sosem látta ezt a dokumentumot, mégis helyesen tudja olvasni.
- @context megnevezi azt a szótárat, amelyben a dokumentum minden mezője definiálva van.
- @type megmondja, milyen dolgot ír le a dokumentum, hogy abból a szótárból a helyes definíciók kerüljenek elő.
Magukban az adatokban semmi nem változik. Ugyanazok az értékek ugyanabban az alakban most mutatót hordoznak minden mező definíciójára. A fogadó rendszer, amely felismeri a szótárat, pontosan tudja, mit kapott, az pedig, amelyik nem, továbbra is közönséges JSON-ként olvashatja a dokumentumot, és figyelmen kívül hagyhatja a többit.
Ez a lényeg. A jelentés a dokumentummal együtt utazik, ahelyett hogy egy specifikációban lakna, amelyben a két félnek előre meg kellett egyeznie.
Hol bukkan fel az ellenőrizhető hitelesítő adatoknál
A W3C Verifiable Credentials Data Model 2.0, amely 2025. május 15. óta W3C Recommendation, JSON-LD-re épül. Minden hitelesítő adat egy @contexttel kezdődik, amelynek első értéke a közös hitelesítőadat-szótár, így azok a fogalmak, amelyek minden hitelesítő adatban közösek, a kibocsátó, az alany, az érvényességi dátumok és az állapotinformáció, mindenhol ugyanazt jelentik.
Minden ezen túli egy második szótárból jön. Egy egyetem a diplomamezőkhöz ad ki egyet, egy kereskedelmi kamara a cégbejegyzési mezőkhöz. Az ellenőrző, akit a diplomák érdekelnek, az elsőt tölti be, akit a cégadatok, a másodikat, és egyiküket sem kell módosítani, amikor a másik új mezőt vesz fel.
Ez teszi lehetővé, hogy egyetlen hitelesítőadat-formátum olyan adatokat vigyen, amelyekre a formátum megírásakor senki nem számított, és éppen erre a tulajdonságra van szüksége egy nyitott ökoszisztémának, egy zárt profilnak pedig nincs.
Összekapcsolt adatok aláírása
A hitelesítő adatot alá is kell írni, és az adatmodell ott szándékosan hagy választást. A burkoló bizonyíték a teljes hitelesítő adatot egy aláírás-tárolóba, például egy JWT-be csomagolja. A bájtokat pontosan úgy írja alá, ahogy vannak, így bármi, ami útközben átrendezi vagy újraformázza őket, elrontja az aláírást.
A beágyazott Data Integrity bizonyíték fordítva működik. A dokumentumot először kanonikus alakra hozzuk, amelyet az RDF Dataset Canonicalization határoz meg és amely 2024. május 21. óta W3C Recommendation, és az aláírás ezt az alakot fedi le, nem a bájtokat. Mivel a kanonikus alak nem függ a kulcsok sorrendjétől, a szóközöktől vagy attól, éppen milyen rövid neveket használ a @context, az aláírás túléli, ha a dokumentumot máshol újra leírják.
Hol illeszkedik az EUDI Walletbe
Nem ott, ahol a legtöbben feltételezik. Az Architecture and Reference Framework két hitelesítőadat-formátumot nevez meg az európai tárcához, az SD-JWT VC-t és az mdocot, és egyik sem JSON-LD. Az a szervezet, amely ma az EUDI Walletbe bocsát ki, útközben egyetlen @contexttel sem fog találkozni.
Az indok a megvalósíthatóság. Mindkét formátumnak rögzített szerkezete van, egyetlen aláírási mechanizmusa, és nincs olyan dokumentum, amelyet az ellenőrzőnek le kellene töltenie, mielőtt bármit ellenőrizhetne. Egy telefonon futó tárcának és egy ezredmásodpercek alatt válaszoló ellenőrzőnek ez többet ér, mint egy nyitott szótár.
A JSON-LD ott érdemli ki a helyét, ahol az adatoknak túl kell utazniuk azon az ökoszisztémán, amely meghatározta őket: termékútlevelek és ellátási lánc adatai, ágazatközi kísérleti projektek, és olyan hitelesítőadat-típusok, amelyeket egyetlen központi profil sem fog soha felsorolni. A két világ gyakrabban fedi egymást, mint ahányszor versenyez, és a mindkettőben dolgozó szervezetek rendszerint mindkettőt támogatják a végén.
A másik JSON-LD, amelyet már használt
Jóval a hitelesítő adatok előtt a JSON-LD lett az a mód, ahogyan egy webhely elmondja egy keresőmotornak, miről szól egy oldal. Egy ilyen blokk az oldal forrásában, a schema.org szótárával, az, ami egy oldalt felismert cikké, termékké, eseménnyé vagy szervezetté tesz. Ezen az oldalon is van egy.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD elmagyarázva",
"description": "Mit ad a JSON-LD az egyszerű JSON-hoz, hogyan ad egy @context minden mezőnek egy jelentést, és hol használják az ellenőrizhető hitelesítő adatok.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "hu",
"mainEntityOfPage": "https://www.credenco.com/hu/explained/json-ld",
"author": {
"@type": "Organization",
"name": "Credenco",
"url": "https://www.credenco.com/"
},
"publisher": {
"@type": "Organization",
"name": "Credenco",
"logo": {
"@type": "ImageObject",
"url": "https://www.credenco.com/logo.svg"
}
}
}Ugyanaz a formátum más szótárral, és ez a legvilágosabb módja annak, hogy meglássuk a lényeget. Itt senki nem egyezett meg semmiben egyetlen keresőmotorral sem. A @context a schema.orgra mutat, a keresőmotor már ismeri ezt a szótárat, és az oldalt olyan fél érti meg, amellyel soha nem beszélt. Egy határon átkelő hitelesítő adat pontosan ugyanezt teszi.
Mibe kerül ez Önnek
A kontextusnak elérhetőnek kell lennie. Az az ellenőrző, amelyik az ellenőrzés pillanatában tölti le, hálózati függőséget tett egy biztonsági döntésbe, és aki azt a dokumentumot kiszolgálja, megváltoztathatja, mit látszik mondani a hitelesítő adat. A valódi telepítések rögzítik az elfogadott kontextusokat és a szoftverrel együtt szállítják, ahelyett hogy élőben oldanák fel őket.
A kanonizálás is valódi munka. Aláírás előtt kanonikus adathalmazzá alakítani egy dokumentumot lényegesen több kód, mint bájtokat aláírni, és a hibamódjai finomak. A dokumentumok ráadásul nagyobbak, ami egy QR-kódon vagy egy NFC-érintésnél kezd számítani.
Ezek egyike sem teszi a JSON-LD-t rossz választássá. Választássá teszi: fizessen a nyitott szótárakért ott, ahol az adatoknak túl kell élniük az őket létrehozó megállapodást, és hagyja ki őket ott, ahol egy rögzített profil már mindent kimond, amire a két félnek szüksége van.
Mit jelent ez Önnek
Kibocsátó
Az EUDI Walletbe kibocsátani SD-JWT VC-t vagy mdocot jelent, és a JSON-LD soha nem kerül elő. Egy W3C-ökoszisztémába kibocsátani hosszú távú elkötelezettséggé teszi a @contextjét: ez a mezői nyilvános definíciója, és a módosítása minden ellenőrzőt elront, amely a régit gyorsítótárazta.
Ellenőrző
Döntse el, mely kontextusokat fogadja el, és szállítsa őket a szoftverével. Ha ellenőrzés közben tölt le egyet, azzal egy távoli kiszolgálót tesz a biztonsági döntése részévé, és hálózati hívást helyez a válaszideje közepébe.
Fejlesztő
Olvassa a JSON-LD dokumentumot közönséges JSON-ként, ha csak egy mezőre van szüksége, és csak ott nyúljon teljes feldolgozóhoz, ahol valóban kibont vagy kanonizál. Az a bonyolultság, amelyet az emberek a JSON-LD-nek tulajdonítanak, nagyrészt az aláírási úton ül, nem az olvasásin.
Kapcsolódó fogalmak
Gyakran ismételt kérdések
A JSON-LD továbbra is csak JSON?
Igen. Minden JSON-LD dokumentum érvényes JSON, és az a szoftver, amelynek csak egy mezőt kell kiolvasnia, így is kezelheti. A többletgépezet csak akkor lép életbe, amikor egy dokumentumot teljes alakjára bont ki, vagy aláíráshoz kanonizál, amit a hitelesítő adatot olvasó kód nagy része soha nem tesz meg.
Használ az EUDI Wallet JSON-LD-t?
Nem. Az Architecture and Reference Framework az SD-JWT VC és az mdoc formátumot nevezi meg hitelesítőadat-formátumként, és egyik sem használ JSON-LD-t. Az ellenőrizhető hitelesítő adatok W3C-ökoszisztémáiban, a termékútlevelekben és az ellátási lánc adataiban számít, nem magában az európai tárcában.
Minden alkalommal letölti az ellenőrző a @contextet?
Nem kellene. Ha ellenőrzés közben tölt le egy kontextust, azzal hálózati hívást tesz egy biztonsági döntés közepébe, és egy távoli kiszolgálónak adja meg a lehetőséget, hogy megváltoztassa, mit látszik mondani a dokumentum. A megvalósítások rögzítik az elfogadott kontextusokat és a szoftverrel együtt szállítják, ami a késleltetést is megszünteti.
Ez ugyanaz a JSON-LD, amit a keresőmotorok olvasnak?
Ugyanaz a formátum más szótárral. Egy weboldal strukturált adatai a @contextjüket a schema.orgra irányítják, míg egy hitelesítő adat a hitelesítőadat-szótárra és arra, amire még szüksége van. A feldolgozási szabályok mindkét esetben azonosak.
Források
Ez az oldal tájékoztató jellegű, és nem minősül jogi tanácsadásnak. Mérvadó útmutatásért tekintse meg közvetlenül a W3C specifikációit.