JSON-LD
JSON-LD je obyčejný JSON s jedním polem navíc, @context, které říká, co znamenají ostatní pole. Kontext přiřazuje každému krátkému názvu pole celosvětově jedinečný identifikátor, obvykle URL zveřejněnou tím, kdo slovník definoval, takže systém, který tato data nikdy neviděl, přesto pozná, co se mu sděluje.
Obyčejný JSON říká, jak jsou data zapsána, ne co znamenají. Pole jménem name může obsahovat osobu, firmu nebo produkt a dva systémy mohou oba posílat platný JSON a přesto se neshodnout na žádném jeho poli. Tuto mezeru obvykle zacelí písemná dohoda mezi dvěma stranami, což funguje pro jednu integraci a přestává fungovat, jakmile pověření vydané v jedné zemi musí přečíst ověřovatel v jiné, se kterým nikdo předem nemluvil.
JSON-LD ji zaceluje uvnitř samotného dokumentu. @context přiřazuje každému krátkému názvu pole celosvětově jedinečný identifikátor, takže pole zůstává čitelné pro člověka a stává se jednoznačným pro stroj. Žádná z hodnot se nemění a příjemce, který slovník nezná, může dokument dál číst jako obyčejný JSON a zbytek ignorovat. JSON-LD 1.0 se stal W3C Recommendation 16. ledna 2014 a verze 1.1 následovala 16. července 2020.
W3C Verifiable Credentials Data Model 2.0 na něm stojí. Každé pověření začíná @context, jehož první hodnotou je sdílený slovník pověření, takže vydavatel, subjekt, data platnosti a stavová informace znamenají všude totéž, a každý další slovník dodává pole, která potřebuje jeden konkrétní typ pověření.
Podepsání dokumentu s propojenými daty je volbou mezi dvěma mechanismy. Obalující důkaz jako JWT podepisuje bajty přesně tak, jak jsou, takže cokoli, co je cestou přeskládá nebo přeformátuje, podpis rozbije. Vložený důkaz Data Integrity podepisuje místo toho kanonickou podobu, kterou definuje RDF Dataset Canonicalization, a právě to umožňuje podpisu přežít, když se dokument někde jinde zapíše znovu.
Není žádným z formátů pověření EUDI Wallet. Architecture and Reference Framework uvádí SD-JWT VC a mdoc a ani jeden z nich JSON-LD nepoužívá, takže organizace vydávající do evropské peněženky na žádný @context nikdy nenarazí. JSON-LD si zaslouží své místo tam, kde data musí cestovat za hranice ekosystému, který je definoval: nasazení pověření W3C, produktové pasy a data dodavatelského řetězce.
Tentýž formát je také způsob, jak web říká vyhledávači, o čem stránka je, přičemž @context ukazuje na schema.org místo na slovník pověření. Pravidla zpracování jsou v obou případech stejná, což ze strukturovaných dat dělá nejsnazší místo, kde je vidět, co kontext vlastně přináší.
Přečtěte si úplné vysvětlení
Tato stránka uvádí krátkou definici. Naše vysvětlení ukazuje, co to znamená v praxi: kdo je zapojen, jak to funguje a co se změní pro vaši organizaci.
JSON-LD vysvětlenSouvisející pojmy
Je JSON-LD jedním z formátů pověření EUDI Wallet?
Ne. Architecture and Reference Framework uvádí SD-JWT VC a mdoc a ani jeden z nich není formát JSON-LD, takže peněženka ani ověřovatel postavený podle evropských pravidel nepotřebuje žádný procesor JSON-LD.
Je to rozhodnutí o rozsahu, ne soud nad formátem. Oba formáty, které rámec uvádí, mají pevnou podobu, jediný mechanismus podpisu a žádný dokument, pro který by si ověřovatel musel dojít, než vůbec něco zkontroluje, a právě to odměňuje telefon a doba odezvy měřená v milisekundách. JSON-LD odpovídá na jinou otázku, totiž jak si data uchovávají význam mimo ekosystém, který je definoval, a organizace pracující v obou světech obvykle nakonec podporují obojí.
Jaký je rozdíl mezi JSON-LD a obyčejným JSON?
Žádný v tom, jak je dokument zapsán: každý dokument JSON-LD je platný JSON a software, který z něj potřebuje jediné pole, s ním tak může zacházet. Rozdílem je @context, který přiřazuje každému názvu pole celosvětově definovaný identifikátor, takže význam dat cestuje spolu s dokumentem, místo aby žil ve specifikaci, na které se obě strany musely předem dohodnout.
Strojírna navíc začne hrát roli až ve chvíli, kdy se dokument rozbalí do plné podoby nebo kanonizuje kvůli podpisu, a tyto kroky ověřovatel čtoucí jediné tvrzení nikdy neprovádí. Skutečná cena leží jinde: kontext musí být dostupný a ověřovatel, který si jej stáhne během ověřování, umístil síťové volání a vzdálený server doprostřed bezpečnostního rozhodnutí. Implementace si přijímané kontexty fixují a dodávají je se softwarem.