JSON-LD
JSON-LD er vanlig JSON med ett ekstra felt, @context, som sier hva de andre feltene betyr. Konteksten knytter hvert korte feltnavn til en globalt unik identifikator, normalt en URL publisert av den som definerte vokabularet, slik at et system som aldri har sett dataene før likevel kan finne ut hva det blir fortalt.
Vanlig JSON sier hvordan data skrives ned, ikke hva de betyr. Et felt som heter name kan inneholde en person, et selskap eller et produkt, og to systemer kan begge sende gyldig JSON og likevel være uenige om hvert eneste felt i den. Det gapet tettes normalt med en skriftlig avtale mellom de to partene, noe som fungerer for én integrasjon og slutter å fungere når et credential utstedt i ett land må leses av en verifier i et annet som ingen har snakket med på forhånd.
JSON-LD tetter det inne i selve dokumentet. @context knytter hvert korte feltnavn til en globalt unik identifikator, slik at feltet forblir lesbart for et menneske og blir entydig for en maskin. Ingen av verdiene endres, og en mottaker som ikke kjenner vokabularet kan fortsatt lese dokumentet som vanlig JSON og se bort fra resten. JSON-LD 1.0 ble en W3C Recommendation 16. januar 2014, og versjon 1.1 fulgte 16. juli 2020.
W3C Verifiable Credentials Data Model 2.0 er bygget på det. Hvert credential åpner med en @context der den første verdien er det felles credential-vokabularet, slik at utstederen, subjektet, gyldighetsdatoene og statusinformasjonen betyr det samme overalt, og ethvert ytterligere vokabular leverer feltene én bestemt credential-type trenger.
Å signere et linked data-dokument er et valg mellom to mekanismer. Et omsluttende bevis som en JWT signerer bytene nøyaktig slik de er, så alt som omorganiserer eller omformaterer dem underveis bryter signaturen. Et innebygd Data Integrity-bevis signerer i stedet en kanonisk form, definert av RDF Dataset Canonicalization, og det er det som lar signaturen overleve at dokumentet skrives ut på nytt et annet sted.
Det er ingen av credential-formatene til EUDI Wallet. Architecture and Reference Framework peker ut SD-JWT VC og mdoc, og ingen av dem bruker JSON-LD, så en organisasjon som utsteder til den europeiske lommeboken vil aldri møte en @context. JSON-LD gjør nytte for seg der data må reise ut over økosystemet som definerte dem: utrullinger av W3C-credentials, produktpass og data i leverandørkjeden.
Samme format er også måten et nettsted forteller en søkemotor hva en side handler om, der @context peker på schema.org i stedet for på et credential-vokabular. Behandlingsreglene er identiske i begge tilfeller, noe som gjør strukturerte data til det enkleste stedet å se hva en kontekst faktisk gir deg.
Les hele forklaringen
Denne siden gir den korte definisjonen. Forklaringen vår viser hva det betyr i praksis: hvem som er involvert, hvordan det fungerer og hva som endres for organisasjonen din.
JSON-LD forklartRelaterte begreper
Er JSON-LD ett av credential-formatene til EUDI Wallet?
Nei. Architecture and Reference Framework peker ut SD-JWT VC og mdoc, og ingen av dem er et JSON-LD-format, så en lommebok eller en verifier bygget for de europeiske reglene trenger ingen JSON-LD-prosessor i det hele tatt.
Det er en avgrensning, ikke en dom over formatet. Begge formatene rammeverket peker ut har en fast form, én signaturmekanisme og ingen dokumenter en verifier må hente før den kan kontrollere noe, og det er nettopp det en telefon og en responstid målt i millisekunder belønner. JSON-LD svarer på et annet spørsmål, nemlig hvordan data beholder betydningen sin utenfor økosystemet som definerte dem, og organisasjoner som arbeider i begge verdener ender vanligvis opp med å støtte begge.
Hva er forskjellen mellom JSON-LD og vanlig JSON?
Ingenting i hvordan dokumentet er skrevet: hvert JSON-LD-dokument er gyldig JSON, og programvare som bare trenger ett felt fra det kan behandle det slik. Forskjellen er @context, som knytter hvert feltnavn til en globalt definert identifikator, slik at betydningen av dataene reiser med dokumentet i stedet for å ligge i en spesifikasjon de to partene måtte bli enige om på forhånd.
Det ekstra maskineriet betyr noe først når et dokument utvides til sin fulle form eller kanoniseres for signering, steg en verifier som leser én enkelt påstand aldri utfører. Den virkelige kostnaden ligger et annet sted: konteksten må være tilgjengelig, og en verifier som henter den mens den verifiserer har plassert et nettverkskall og en ekstern server midt inne i en sikkerhetsbeslutning. Implementasjoner låser kontekstene de godtar og leverer dem med programvaren i stedet.