JSON-LD
JSON-LD je obyčajný JSON s jedným poľom navyše, @context, ktoré hovorí, čo znamenajú ostatné polia. Kontext priraďuje každému krátkemu názvu poľa celosvetovo jedinečný identifikátor, zvyčajne URL zverejnenú tým, kto slovník definoval, takže systém, ktorý tieto údaje nikdy nevidel, aj tak zistí, čo sa mu hovorí.
Obyčajný JSON hovorí, ako sú údaje zapísané, nie čo znamenajú. Pole s názvom name môže obsahovať osobu, firmu alebo produkt a dva systémy môžu oba posielať platný JSON a napriek tomu sa nezhodnúť na žiadnom jeho poli. Túto medzeru zvyčajne zacelí písomná dohoda medzi dvoma stranami, čo funguje pre jednu integráciu a prestáva fungovať, len čo poverenie vydané v jednej krajine musí prečítať overovateľ v inej, s ktorým nikto vopred nehovoril.
JSON-LD ju zaceľuje vnútri samotného dokumentu. @context priraďuje každému krátkemu názvu poľa celosvetovo jedinečný identifikátor, takže pole zostáva čitateľné pre človeka a stáva sa jednoznačným pre stroj. Žiadna z hodnôt sa nemení a príjemca, ktorý slovník nepozná, môže dokument naďalej čítať ako obyčajný JSON a zvyšok ignorovať. JSON-LD 1.0 sa stal W3C Recommendation 16. januára 2014 a verzia 1.1 nasledovala 16. júla 2020.
Stojí na ňom W3C Verifiable Credentials Data Model 2.0. Každé poverenie sa začína @context, ktorého prvou hodnotou je zdieľaný slovník poverení, takže vydavateľ, subjekt, dátumy platnosti a stavová informácia znamenajú všade to isté, a každý ďalší slovník dodáva polia, ktoré potrebuje jeden konkrétny typ poverenia.
Podpísanie dokumentu s prepojenými údajmi je voľbou medzi dvoma mechanizmami. Obaľujúci dôkaz ako JWT podpisuje bajty presne tak, ako sú, takže čokoľvek, čo ich cestou preusporiada alebo preformátuje, podpis rozbije. Vložený dôkaz Data Integrity podpisuje namiesto toho kanonickú podobu, ktorú definuje RDF Dataset Canonicalization, a práve to umožňuje podpisu prežiť, keď sa dokument inde zapíše znova.
Nie je žiadnym z formátov poverení EUDI Wallet. Architecture and Reference Framework uvádza SD-JWT VC a mdoc a ani jeden z nich JSON-LD nepoužíva, takže organizácia vydávajúca do európskej peňaženky na žiadny @context nikdy nenarazí. JSON-LD si zaslúži svoje miesto tam, kde údaje musia cestovať za hranice ekosystému, ktorý ich definoval: nasadenia poverení W3C, produktové pasy a údaje dodávateľského reťazca.
Ten istý formát je aj spôsob, akým web hovorí vyhľadávaču, o čom stránka je, pričom @context ukazuje na schema.org namiesto na slovník poverení. Pravidlá spracovania sú v oboch prípadoch rovnaké, čo zo štruktúrovaných dát robí najjednoduchšie miesto, kde vidieť, čo kontext vlastne prináša.
Prečítajte si úplné vysvetlenie
Táto stránka uvádza krátku definíciu. Naše vysvetlenie ukazuje, čo to znamená v praxi: kto je zapojený, ako to funguje a čo sa zmení pre vašu organizáciu.
JSON-LD vysvetlenýJe JSON-LD jedným z formátov poverení EUDI Wallet?
Nie. Architecture and Reference Framework uvádza SD-JWT VC a mdoc a ani jeden z nich nie je formát JSON-LD, takže peňaženka ani overovateľ postavený podľa európskych pravidiel nepotrebuje žiadny procesor JSON-LD.
Je to rozhodnutie o rozsahu, nie súd nad formátom. Oba formáty, ktoré rámec uvádza, majú pevnú podobu, jediný mechanizmus podpisu a žiadny dokument, po ktorý by si overovateľ musel ísť, kým vôbec niečo skontroluje, a práve to odmeňuje telefón a doba odozvy meraná v milisekundách. JSON-LD odpovedá na inú otázku, totiž ako si údaje zachovávajú význam mimo ekosystému, ktorý ich definoval, a organizácie pracujúce v oboch svetoch zvyčajne nakoniec podporujú oboje.
Aký je rozdiel medzi JSON-LD a obyčajným JSON?
Žiadny v tom, ako je dokument zapísaný: každý dokument JSON-LD je platný JSON a softvér, ktorý z neho potrebuje jediné pole, s ním tak môže zaobchádzať. Rozdielom je @context, ktorý priraďuje každému názvu poľa celosvetovo definovaný identifikátor, takže význam údajov cestuje spolu s dokumentom namiesto toho, aby žil v špecifikácii, na ktorej sa obe strany museli vopred dohodnúť.
Strojáreň navyše začne hrať rolu až vtedy, keď sa dokument rozbalí do plnej podoby alebo kanonizuje kvôli podpisu, a tieto kroky overovateľ čítajúci jediné tvrdenie nikdy nevykonáva. Skutočná cena leží inde: kontext musí byť dostupný a overovateľ, ktorý si ho stiahne počas overovania, umiestnil sieťové volanie a vzdialený server doprostred bezpečnostného rozhodnutia. Implementácie si prijímané kontexty fixujú a dodávajú ich so softvérom.