JSON-LD forklart
JSON-LD er vanlig JSON med én ekstra linje som sier hva feltene betyr. Den linjen gjør et lokalt feltnavn om til et globalt definert, slik at et system som aldri har sett dataene dine likevel kan finne ut hva du snakker om. Det har vært en W3C-standard siden 2014, det er slik søkemotorer leser nettopp denne siden, og det er grunnlaget for W3Cs datamodell for verifiserbare credentials.
Problemet med vanlig JSON
JSON sier hvordan data skrives ned. Det sier ingenting om hva noe av det betyr. Et felt som heter name kan være en person, et selskap eller et produkt. Et felt som heter id kan være et kundenummer, et passnummer eller en rad i noens database. To systemer kan begge produsere helt gyldig JSON og likevel være uenige om hvert eneste felt i det.
I praksis tettes gapet med en avtale. De to partene skriver ned hva feltene betyr og bygger programvaren deretter. Det fungerer for én integrasjon, blir dyrt ved ti, og slutter helt å fungere når et credential utstedt i ett land skal forstås av en verifikator i et annet som ingen har snakket med på forhånd.
Hva @context gjør
JSON-LD tetter det gapet inne i selve dokumentet. En @context knytter hvert korte feltnavn til en globalt unik identifikator, normalt en URL som kontrolleres av den som definerte vokabularet. Feltet forblir kort og lesbart for et menneske og blir entydig for en maskin.
Vanlig JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Gyldig, lesbart og meningsløst for alle som ikke på forhånd har fått vite hva feltene skal inneholde.
De samme dataene som JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Hvert felt peker nå på en publisert definisjon, slik at et system som aldri har sett dette dokumentet likevel kan lese det riktig.
- @context navngir vokabularet som hvert felt i dokumentet er definert i.
- @type sier hva slags ting dokumentet beskriver, slik at de riktige definisjonene plukkes fra det vokabularet.
Ingenting ved dataene selv endres. De samme verdiene i samme form bærer nå en peker til definisjonen av hvert felt. Et mottakende system som kjenner igjen vokabularet vet nøyaktig hva det fikk, og ett som ikke gjør det kan fortsatt lese dokumentet som vanlig JSON og se bort fra resten.
Det er hele ideen. Meningen reiser med dokumentet i stedet for å ligge i en spesifikasjon som de to partene måtte bli enige om på forhånd.
Hvor det dukker opp i verifiserbare credentials
W3C Verifiable Credentials Data Model 2.0, W3C Recommendation siden 15. mai 2025, er bygget på JSON-LD. Hvert credential åpner med en @context der den første verdien er det felles credential-vokabularet, slik at begrepene alle credentials har til felles, utstederen, subjektet, gyldighetsdatoene og statusinformasjonen, betyr det samme overalt.
Alt utover det kommer fra et annet vokabular. Et universitet publiserer ett for vitnemålsfelter, et handelskammer ett for felter om foretaksregistrering. En verifikator som bryr seg om vitnemål laster det første, en som bryr seg om foretaksdata laster det andre, og ingen av dem må endres når den andre legger til et felt.
Det er dette som lar ett credential-format bære data ingen forutså da formatet ble skrevet, og det er egenskapen et åpent økosystem trenger og en lukket profil ikke gjør.
Å signere lenkede data
Et credential må også signeres, og datamodellen lar det bevisst stå et valg der. Et omsluttende bevis pakker hele credentialet inn i en signaturbeholder som et JWT. Bytene signeres nøyaktig slik de er, så alt som omorganiserer eller omformaterer dem underveis bryter signaturen.
Et innebygd Data Integrity-bevis fungerer motsatt. Dokumentet settes først i en kanonisk form, definert av RDF Dataset Canonicalization og W3C Recommendation siden 21. mai 2024, og signaturen dekker den formen i stedet for bytene. Fordi den kanoniske formen ikke avhenger av nøkkelrekkefølge, mellomrom eller hvilke korte navn @context tilfeldigvis bruker, overlever signaturen at dokumentet skrives ut på nytt et annet sted.
Hvor det passer inn i EUDI Wallet
Ikke der de fleste antar. Architecture and Reference Framework peker ut to credential-formater for den europeiske lommeboken, SD-JWT VC og mdoc, og ingen av dem er JSON-LD. En organisasjon som utsteder til EUDI Wallet i dag vil ikke møte noen @context på veien.
Begrunnelsen er gjennomførbarhet. Begge formatene har en fast struktur, én signaturmekanisme og ikke noe dokument en verifikator må hente før den kan kontrollere noe som helst. For en lommebok som kjører på en telefon og en verifikator som må svare på millisekunder, er det verdt mer enn et åpent vokabular.
JSON-LD fortjener plassen sin der data må reise utenfor økosystemet som definerte dem: produktpass og data i leverandørkjeden, piloter på tvers av sektorer, og credential-typer ingen sentral profil noensinne kommer til å liste opp. De to verdenene overlapper oftere enn de konkurrerer, og organisasjoner som jobber i begge ender som regel opp med å støtte begge.
Det andre JSON-LD, det du allerede har brukt
Lenge før credentials ble JSON-LD måten et nettsted forteller en søkemotor hva en side handler om. En blokk av det i sidens kildekode, med vokabularet til schema.org, er det som gjør en side til en gjenkjent artikkel, et produkt, et arrangement eller en organisasjon. Denne siden har en slik blokk.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD forklart",
"description": "Hva JSON-LD legger til vanlig JSON, hvordan en @context gir hvert felt én betydning, og hvor verifiserbare credentials bruker det.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "no",
"mainEntityOfPage": "https://www.credenco.com/no/explained/json-ld",
"author": {
"@type": "Organization",
"name": "Credenco",
"url": "https://www.credenco.com/"
},
"publisher": {
"@type": "Organization",
"name": "Credenco",
"logo": {
"@type": "ImageObject",
"url": "https://www.credenco.com/logo.svg"
}
}
}Det er samme format med et annet vokabular, og det er den klareste måten å se poenget på. Ingen her har avtalt noe med noen søkemotor. @context peker mot schema.org, søkemotoren kjenner allerede det vokabularet, og siden forstås av en part den aldri har snakket med. Et credential som krysser en grense gjør nøyaktig det samme.
Hva det koster
Konteksten må være tilgjengelig. En verifikator som henter den på verifiseringstidspunktet har lagt en nettverksavhengighet inn i en sikkerhetsbeslutning, og den som serverer dokumentet kan endre hva credentialet ser ut til å si. Reelle installasjoner låser kontekstene de godtar og leverer dem med programvaren i stedet for å slå dem opp i sanntid.
Kanonisering er også reelt arbeid. Å gjøre et dokument om til et kanonisk datasett før signering er atskillig mer kode enn å signere byte, og feilmåtene er subtile. Dokumentene er dessuten større, noe som begynner å telle på en QR-kode eller ved en NFC-berøring.
Ingenting av dette gjør JSON-LD til feil valg. Det gjør det til et valg: betal for åpne vokabularer der data må overleve avtalen som skapte dem, og dropp dem der en fast profil allerede sier alt de to partene trenger.
Hva dette betyr for deg
Utsteder
Å utstede til EUDI Wallet betyr SD-JWT VC eller mdoc, og JSON-LD kommer aldri opp. Å utstede til et W3C-økosystem gjør @context-en din til en langsiktig forpliktelse: den er den offentlige definisjonen av feltene dine, og å endre den ødelegger hver verifikator som har hurtiglagret den gamle.
Verifikator
Bestem hvilke kontekster du godtar og lever dem med programvaren din. Å hente en under verifisering gjør en ekstern server til en del av sikkerhetsbeslutningen din og legger et nettverkskall midt i responstiden din.
Utvikler
Les et JSON-LD-dokument som vanlig JSON når alt du trenger er ett felt, og ta fram en full prosessor bare der du faktisk utvider eller kanoniserer. Det meste av kompleksiteten folk tilskriver JSON-LD ligger i signeringsløpet, ikke i leseløpet.
Relaterte begreper
Ofte stilte spørsmål
Er JSON-LD fortsatt bare JSON?
Ja. Ethvert JSON-LD-dokument er gyldig JSON, og programvare som bare trenger å lese ett felt kan behandle det slik. Det ekstra maskineriet kommer først i spill når du utvider et dokument til full form eller kanoniserer det for signering, noe det meste av koden som leser et credential aldri gjør.
Bruker EUDI Wallet JSON-LD?
Nei. Architecture and Reference Framework peker ut SD-JWT VC og mdoc som credential-formater, og ingen av dem bruker JSON-LD. Det betyr noe for W3C-økosystemer med verifiserbare credentials, for produktpass og for data i leverandørkjeden, ikke for den europeiske lommeboken i seg selv.
Laster en verifikator ned @context hver gang?
Det bør den ikke. Å hente en kontekst under verifisering legger et nettverkskall midt inne i en sikkerhetsbeslutning og gir en ekstern server muligheten til å endre hva dokumentet ser ut til å si. Implementasjoner låser kontekstene de godtar og leverer dem med programvaren, noe som også fjerner forsinkelsen.
Er dette det samme JSON-LD som søkemotorer leser?
Samme format med et annet vokabular. Strukturerte data på en nettside peker sin @context mot schema.org, mens et credential peker den mot credential-vokabularet og det andre det trenger. Behandlingsreglene er identiske i begge tilfeller.
Kilder
Denne siden er informativ og utgjør ikke juridisk rådgivning. For autoritativ veiledning, se spesifikasjonene fra W3C direkte.