JSON-LD forklaret
JSON-LD er almindelig JSON med én ekstra linje, der fortæller, hvad felterne betyder. Den linje gør et lokalt feltnavn til et globalt defineret, så et system, der aldrig har set dine data, alligevel kan regne ud, hvad du taler om. Det har været en W3C-standard siden 2014, det er sådan søgemaskiner læser netop denne side, og det er grundlaget for W3C's datamodel for verificerbare credentials.
Problemet med almindelig JSON
JSON fortæller, hvordan data skrives ned. Det siger intet om, hvad noget af det betyder. Et felt, der hedder name, kan være en person, et firma eller et produkt. Et felt, der hedder id, kan være et kundenummer, et pasnummer eller en række i nogens database. To systemer kan begge udsende fuldstændig gyldig JSON og alligevel være uenige om hvert eneste felt i den.
I praksis lukkes hullet med en aftale. De to parter skriver ned, hvad felterne betyder, og bygger deres software derefter. Det virker for én integration, bliver dyrt ved ti og holder helt op med at virke, når et credential udstedt i ét land skal forstås af en verifikator i et andet, som ingen har talt med på forhånd.
Hvad @context gør
JSON-LD lukker det hul inde i selve dokumentet. En @context knytter hvert kort feltnavn til en globalt entydig identifikator, normalt en URL, der kontrolleres af den, som definerede vokabularet. Feltet forbliver kort og læsbart for et menneske og bliver utvetydigt for en maskine.
Almindelig JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Gyldigt, læsbart og meningsløst for enhver, der ikke på forhånd har fået at vide, hvad felterne skal indeholde.
De samme data som JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Hvert felt peger nu på en offentliggjort definition, så et system, der aldrig har set dette dokument, alligevel kan læse det korrekt.
- @context navngiver det vokabular, som hvert felt i dokumentet er defineret i.
- @type fortæller, hvilken slags ting dokumentet beskriver, så de rigtige definitioner hentes fra det vokabular.
Intet ved selve data ændres. De samme værdier i samme form bærer nu en henvisning til definitionen af hvert felt. Et modtagende system, der genkender vokabularet, ved præcis, hvad det fik, og et der ikke gør, kan stadig læse dokumentet som almindelig JSON og se bort fra resten.
Det er hele idéen. Betydningen rejser med dokumentet i stedet for at bo i en specifikation, som de to parter skulle blive enige om på forhånd.
Hvor det dukker op i verificerbare credentials
W3C Verifiable Credentials Data Model 2.0, W3C Recommendation siden den 15. maj 2025, er bygget på JSON-LD. Hvert credential åbner med en @context, hvis første værdi er det fælles credential-vokabular, så de begreber, alle credentials har til fælles, udstederen, subjektet, gyldighedsdatoerne og statusoplysningerne, betyder det samme overalt.
Alt derudover kommer fra et andet vokabular. Et universitet udgiver et til eksamensfelter, et handelskammer et til felter om virksomhedsregistrering. En verifikator, der interesserer sig for eksamensbeviser, henter det første, en der interesserer sig for virksomhedsdata, henter det andet, og ingen af dem skal ændres, når den anden tilføjer et felt.
Det er dette, der lader ét credential-format bære data, som ingen forudså, da formatet blev skrevet, og det er den egenskab, et åbent økosystem har brug for, og en lukket profil ikke har.
At signere sammenkædede data
Et credential skal også signeres, og datamodellen lader bevidst et valg stå der. Et omsluttende bevis pakker hele credentialet ind i en signaturbeholder som et JWT. Bytene signeres præcis, som de er, så alt, der omordner eller omformaterer dem undervejs, bryder signaturen.
Et indlejret Data Integrity-bevis fungerer omvendt. Dokumentet bringes først på en kanonisk form, defineret af RDF Dataset Canonicalization og W3C Recommendation siden den 21. maj 2024, og signaturen dækker den form i stedet for bytene. Fordi den kanoniske form ikke afhænger af nøglerækkefølge, mellemrum eller hvilke korte navne @context tilfældigvis bruger, overlever signaturen, at dokumentet skrives ud igen et andet sted.
Hvor det passer ind i EUDI Wallet
Ikke der, hvor de fleste antager. Architecture and Reference Framework udpeger to credential-formater til den europæiske tegnebog, SD-JWT VC og mdoc, og ingen af dem er JSON-LD. En organisation, der udsteder til EUDI Wallet i dag, møder ingen @context undervejs.
Begrundelsen er gennemførlighed. Begge formater har en fast struktur, én signaturmekanisme og intet dokument, som en verifikator skal hente, før den kan kontrollere noget som helst. For en tegnebog, der kører på en telefon, og en verifikator, der skal svare på millisekunder, er det mere værd end et åbent vokabular.
JSON-LD gør sig fortjent til sin plads der, hvor data skal rejse ud over det økosystem, der definerede dem: produktpas og data i forsyningskæden, pilotprojekter på tværs af sektorer og credential-typer, som ingen central profil nogensinde kommer til at opregne. De to verdener overlapper oftere, end de konkurrerer, og organisationer, der arbejder i begge, ender som regel med at understøtte dem begge.
Det andet JSON-LD, det du allerede har brugt
Længe før credentials blev JSON-LD måden, hvorpå et websted fortæller en søgemaskine, hvad en side handler om. En blok af det i sidens kildekode, med schema.org-vokabularet, er det, der gør en side til en genkendt artikel, et produkt, en begivenhed eller en organisation. Denne side bærer sådan en blok.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD forklaret",
"description": "Hvad JSON-LD tilføjer til almindelig JSON, hvordan en @context giver hvert felt én betydning, og hvor verificerbare credentials bruger det.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "da",
"mainEntityOfPage": "https://www.credenco.com/da/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 andet vokabular, og det er den klareste måde at se pointen på. Ingen her har aftalt noget med nogen søgemaskine. @context peger mod schema.org, søgemaskinen kender allerede det vokabular, og siden forstås af en part, den aldrig har talt med. Et credential, der krydser en grænse, gør præcis det samme.
Hvad det koster
Konteksten skal være tilgængelig. En verifikator, der henter den på verifikationstidspunktet, har tilføjet en netværksafhængighed til en sikkerhedsbeslutning, og den, der serverer dokumentet, kan ændre, hvad credentialet synes at sige. Rigtige installationer fastlåser de kontekster, de accepterer, og leverer dem med softwaren i stedet for at slå dem op i realtid.
Kanonisering er også rigtigt arbejde. At omdanne et dokument til et kanonisk datasæt før signering er betydeligt mere kode end at signere bytes, og fejlmønstrene er subtile. Dokumenterne er desuden større, hvilket begynder at tælle på en QR-kode eller ved et NFC-tryk.
Intet af det gør JSON-LD til det forkerte valg. Det gør det til et valg: betal for åbne vokabularer der, hvor data skal overleve den aftale, der skabte dem, og undlad dem der, hvor en fast profil allerede siger alt, hvad de to parter har brug for.
Hvad det betyder for dig
Udsteder
At udstede til EUDI Wallet betyder SD-JWT VC eller mdoc, og JSON-LD kommer aldrig op. At udstede til et W3C-økosystem gør din @context til en langsigtet forpligtelse: den er den offentlige definition af dine felter, og at ændre den ødelægger enhver verifikator, der har cachet den gamle.
Verifikator
Beslut, hvilke kontekster du accepterer, og lever dem med din software. At hente en under verifikationen gør en fjernserver til en del af din sikkerhedsbeslutning og placerer et netværkskald midt i din svartid.
Udvikler
Læs et JSON-LD-dokument som almindelig JSON, når alt du skal bruge er ét felt, og tag først en fuld processor frem der, hvor du faktisk udfolder eller kanoniserer. Det meste af den kompleksitet, folk tilskriver JSON-LD, ligger i signeringsvejen, ikke i læsevejen.
Relaterede begreber
Ofte stillede spørgsmål
Er JSON-LD stadig bare JSON?
Ja. Ethvert JSON-LD-dokument er gyldig JSON, og software, der kun skal læse ét felt, kan behandle det sådan. Det ekstra maskineri kommer først i spil, når du udfolder et dokument til dets fulde form eller kanoniserer det til signering, hvilket det meste kode, der læser et credential, aldrig gør.
Bruger EUDI Wallet JSON-LD?
Nej. Architecture and Reference Framework udpeger SD-JWT VC og mdoc som credential-formater, og ingen af dem bruger JSON-LD. Det har betydning for W3C-økosystemer med verificerbare credentials, for produktpas og for data i forsyningskæden, ikke for den europæiske tegnebog i sig selv.
Henter en verifikator @context hver gang?
Det bør den ikke. At hente en kontekst under verifikationen placerer et netværkskald midt i en sikkerhedsbeslutning og giver en fjernserver mulighed for at ændre, hvad dokumentet synes at sige. Implementeringer fastlåser de kontekster, de accepterer, og leverer dem med softwaren, hvilket også fjerner forsinkelsen.
Er det det samme JSON-LD, som søgemaskiner læser?
Samme format med et andet vokabular. Strukturerede data på en webside peger deres @context mod schema.org, mens et credential peger den mod credential-vokabularet og det øvrige, det har brug for. Behandlingsreglerne er identiske i begge tilfælde.
Kilder
Denne side er informativ og udgør ikke juridisk rådgivning. For autoritativ vejledning henvises direkte til specifikationerne fra W3C.