JSON-LD
JSON-LD je navaden JSON z enim dodatnim poljem, @context, ki pove, kaj pomenijo ostala polja. Kontekst vsako kratko ime polja poveže z globalno enoličnim identifikatorjem, običajno naslovom URL, ki ga je objavil tisti, ki je besednjak definiral, tako da sistem, ki teh podatkov še nikoli ni videl, kljub temu ugotovi, kaj mu je povedano.
Navaden JSON pove, kako so podatki zapisani, ne pa kaj pomenijo. Polje z imenom name lahko vsebuje osebo, podjetje ali izdelek, dva sistema pa lahko oba pošiljata veljaven JSON in se vseeno ne strinjata o nobenem njegovem polju. To vrzel običajno zapolni pisni dogovor med stranema, ki deluje za eno integracijo in preneha delovati, ko mora poverilnico, izdano v eni državi, prebrati preveritelj v drugi, s katerim se nihče ni vnaprej dogovoril.
JSON-LD jo zapolni znotraj samega dokumenta. @context vsako kratko ime polja poveže z globalno enoličnim identifikatorjem, tako da polje ostane berljivo za človeka in postane nedvoumno za stroj. Nobena od vrednosti se ne spremeni, prejemnik, ki besednjaka ne prepozna, pa lahko dokument še vedno bere kot navaden JSON in preostanek prezre. JSON-LD 1.0 je postal W3C Recommendation 16. januarja 2014, različica 1.1 pa je sledila 16. julija 2020.
Na njem je zgrajen W3C Verifiable Credentials Data Model 2.0. Vsaka poverilnica se začne z @context, katerega prva vrednost je skupni besednjak poverilnic, tako da izdajatelj, subjekt, datumi veljavnosti in podatki o statusu povsod pomenijo isto, vsak nadaljnji besednjak pa prispeva polja, ki jih potrebuje ena določena vrsta poverilnice.
Podpisovanje dokumenta s povezanimi podatki je izbira med dvema mehanizmoma. Ovojni dokaz, kot je JWT, podpiše bajte natanko take, kot so, zato vse, kar jih med potjo preuredi ali preoblikuje, podpis pokvari. Vgrajeni dokaz Data Integrity namesto tega podpiše kanonično obliko, ki jo določa RDF Dataset Canonicalization, in prav to omogoči, da podpis preživi, če se dokument drugje zapiše znova.
Ni nobeden od formatov poverilnic EUDI Wallet. Architecture and Reference Framework navaja SD-JWT VC in mdoc, nobeden od njiju pa ne uporablja JSON-LD, zato organizacija, ki izdaja v evropsko denarnico, nikoli ne bo naletela na @context. JSON-LD si svoje mesto prisluži tam, kjer morajo podatki potovati onkraj ekosistema, ki jih je definiral: uvedbe poverilnic W3C, potni listi izdelkov in podatki dobavne verige.
Isti format je tudi način, kako spletno mesto iskalniku pove, o čem govori stran, pri čemer @context kaže na schema.org namesto na besednjak poverilnic. Pravila obdelave so v obeh primerih enaka, zaradi česar so strukturirani podatki najlažje mesto, kjer se vidi, kaj kontekst pravzaprav prinese.
Preberite celotno razlago
Ta stran podaja kratko definicijo. Naša razlaga pokaže, kaj to pomeni v praksi: kdo je vključen, kako deluje in kaj se spremeni za vašo organizacijo.
JSON-LD pojasnjenJe JSON-LD eden od formatov poverilnic EUDI Wallet?
Ne. Architecture and Reference Framework navaja SD-JWT VC in mdoc, nobeden od njiju pa ni format JSON-LD, zato denarnica ali preveritelj, zgrajena po evropskih pravilih, sploh ne potrebujeta procesorja JSON-LD.
To je odločitev o obsegu, ne sodba o formatu. Oba formata, ki ju navaja okvir, imata določeno obliko, en sam mehanizem podpisa in nobenega dokumenta, po katerega bi moral preveritelj iti, preden sploh lahko kaj preveri, in prav to nagrajujeta telefon in odzivni čas, merjen v milisekundah. JSON-LD odgovarja na drugo vprašanje, namreč kako podatki ohranijo pomen zunaj ekosistema, ki jih je definiral, in organizacije, ki delajo v obeh svetovih, na koncu običajno podpirajo oba.
Kakšna je razlika med JSON-LD in navadnim JSON?
Nobena v tem, kako je dokument zapisan: vsak dokument JSON-LD je veljaven JSON, programska oprema, ki iz njega potrebuje samo eno polje, pa ga lahko tako tudi obravnava. Razlika je @context, ki vsako ime polja poveže z globalno določenim identifikatorjem, tako da pomen podatkov potuje z dokumentom, namesto da bi živel v specifikaciji, o kateri sta se morali strani vnaprej dogovoriti.
Dodatna mehanika začne šteti šele, ko se dokument razširi v polno obliko ali kanonizira za podpis, in teh korakov preveritelj, ki prebere eno samo izjavo, nikoli ne izvede. Prava cena je drugje: kontekst mora biti na voljo, preveritelj, ki ga med preverjanjem prenese, pa je omrežni klic in oddaljeni strežnik postavil sredi varnostne odločitve. Izvedbe kontekste, ki jih sprejemajo, pripnejo in jih dostavijo s programsko opremo.