JSON-LD
A JSON-LD közönséges JSON egyetlen plusz mezővel, a @contexttel, amely megmondja, mit jelentenek a többi mezők. A kontextus minden rövid mezőnevet egy világszinten egyedi azonosítóhoz rendel, rendszerint egy URL-hez, amelyet az tett közzé, aki a szótárat definiálta, így egy rendszer, amely még sosem látta ezeket az adatokat, mégis ki tudja következtetni, mit mondanak neki.
A közönséges JSON azt mondja meg, hogyan írjuk le az adatokat, nem azt, hogy mit jelentenek. Egy name nevű mező tartalmazhat személyt, céget vagy terméket, és két rendszer egyaránt küldhet érvényes JSON-t úgy, hogy közben minden egyes mezőjét másként érti. Ezt a rést rendszerint a két fél közötti írásos megállapodás zárja be, ami egyetlen integrációnál működik, és megszűnik működni, amint egy az egyik országban kibocsátott hitelesítő adatot egy másik ország ellenőrzőjének kell elolvasnia, akivel előzetesen senki sem beszélt.
A JSON-LD magán a dokumentumon belül zárja be. A @context minden rövid mezőnevet egy világszinten egyedi azonosítóhoz rendel, így a mező ember számára olvasható marad, a gép számára pedig egyértelművé válik. Egyik érték sem változik, és az a fogadó, amely nem ismeri fel a szótárat, továbbra is közönséges JSON-ként olvashatja a dokumentumot, a többit pedig figyelmen kívül hagyhatja. A JSON-LD 1.0 2014. január 16-án lett W3C Recommendation, az 1.1-es változat pedig 2020. július 16-án követte.
Erre épül a W3C Verifiable Credentials Data Model 2.0. Minden hitelesítő adat egy @contexttel kezdődik, amelynek első értéke a közös hitelesítőadat-szótár, így a kibocsátó, az alany, az érvényességi dátumok és az állapotinformáció mindenhol ugyanazt jelenti, minden további szótár pedig azokat a mezőket adja, amelyekre egy adott hitelesítőadat-típusnak szüksége van.
Egy összekapcsolt adatokat tartalmazó dokumentum aláírása két mechanizmus közötti választás. A burkoló bizonyíték, például egy JWT, pontosan úgy írja alá a bájtokat, ahogy vannak, ezért bármi, ami útközben átrendezi vagy újraformázza őket, elrontja az aláírást. A beágyazott Data Integrity bizonyíték ehelyett egy kanonikus alakot ír alá, amelyet az RDF Dataset Canonicalization határoz meg, és éppen ez teszi lehetővé, hogy az aláírás túlélje, ha a dokumentumot máshol újra leírják.
Nem tartozik az EUDI Wallet hitelesítőadat-formátumai közé. Az Architecture and Reference Framework az SD-JWT VC-t és az mdocot nevezi meg, és egyik sem használ JSON-LD-t, így az a szervezet, amely az európai tárcába bocsát ki, soha nem fog @contexttel találkozni. A JSON-LD ott érdemli ki a helyét, ahol az adatoknak túl kell utazniuk az őket meghatározó ökoszisztémán: W3C-hitelesítőadatok bevezetései, termékútlevelek és ellátásilánc-adatok.
Ugyanez a formátum az is, ahogyan egy webhely elmondja egy keresőmotornak, miről szól egy oldal, ilyenkor a @context a schema.orgra mutat, nem pedig egy hitelesítőadat-szótárra. A feldolgozási szabályok mindkét esetben azonosak, ezért a strukturált adatokon látszik a legkönnyebben, mit ad valójában egy kontextus.
Olvassa el a teljes magyarázatot
Ez az oldal a rövid meghatározást adja meg. Magyarázatunk bemutatja, mit jelent ez a gyakorlatban: kik vesznek részt benne, hogyan működik, és mi változik az Ön szervezete számára.
JSON-LD elmagyarázvaKapcsolódó fogalmak
A JSON-LD az EUDI Wallet hitelesítőadat-formátumai közé tartozik?
Nem. Az Architecture and Reference Framework az SD-JWT VC-t és az mdocot nevezi meg, és egyik sem JSON-LD formátum, így az európai szabályokhoz épített tárcának vagy ellenőrzőnek egyáltalán nincs szüksége JSON-LD feldolgozóra.
Ez hatókörről szóló döntés, nem ítélet a formátumról. A keretrendszer által megnevezett mindkét formátumnak rögzített alakja 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, és éppen ezt jutalmazza egy telefon és egy ezredmásodpercekben mért válaszidő. A JSON-LD más kérdésre válaszol, nevezetesen arra, hogyan őrzik meg az adatok a jelentésüket az őket meghatározó ökoszisztémán kívül, és a mindkét világban dolgozó szervezetek általában mindkettőt támogatják a végén.
Mi a különbség a JSON-LD és a közönséges JSON között?
Semmi abban, ahogyan a dokumentum le van írva: minden JSON-LD dokumentum érvényes JSON, és az a szoftver, amelynek csak egyetlen mezőre van szüksége belőle, kezelheti is így. A különbség a @context, amely minden mezőnevet egy világszinten meghatározott azonosítóhoz rendel, így az adatok jelentése a dokumentummal együtt utazik, ahelyett hogy egy olyan specifikációban élne, amelyről a két félnek előre meg kellett állapodnia.
A többletgépezet csak akkor számít, amikor egy dokumentumot teljes alakjára bontanak ki vagy aláíráshoz kanonizálnak, és ezeket a lépéseket egyetlen állítást olvasó ellenőrző soha nem végzi el. A valódi ár máshol van: a kontextusnak elérhetőnek kell lennie, és az az ellenőrző, amely ellenőrzés közben tölti le, hálózati hívást és távoli kiszolgálót tett egy biztonsági döntés közepébe. A megvalósítások rögzítik az elfogadott kontextusokat, és a szoftverrel együtt szállítják.