JSON-LD förklarat
JSON-LD är vanlig JSON med en extra rad som säger vad fälten betyder. Den raden gör ett lokalt fältnamn till ett globalt definierat, så att ett system som aldrig sett dina data ändå kan lista ut vad du talar om. Det har varit en W3C-standard sedan 2014, det är så sökmotorer läser just den här sidan, och det är det som W3C:s datamodell för verifierbara intyg bygger på.
Problemet med vanlig JSON
JSON säger hur data skrivs ned. Det säger ingenting om vad något av det betyder. Ett fält som heter name kan vara en person, ett företag eller en produkt. Ett fält som heter id kan vara ett kundnummer, ett passnummer eller en rad i någons databas. Två system kan båda producera fullt giltig JSON och ändå vara oense om varenda fält i den.
I praktiken täpps glappet till med en överenskommelse. De två parterna skriver ned vad fälten betyder och bygger sin programvara därefter. Det fungerar för en integration, blir dyrt vid tio och slutar fungera helt när ett intyg utfärdat i ett land ska förstås av en verifierare i ett annat som ingen talat med i förväg.
Vad @context gör
JSON-LD täpper till det glappet inuti själva dokumentet. En @context kopplar varje kort fältnamn till en globalt unik identifierare, normalt en URL som kontrolleras av den som definierade vokabulären. Fältet förblir kort och läsbart för en människa och blir entydigt för en maskin.
Vanlig JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Giltigt, läsbart och meningslöst för var och en som inte i förväg fått veta vad fälten ska innehålla.
Samma data som JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Varje fält pekar nu på en publicerad definition, så att ett system som aldrig sett det här dokumentet ändå kan läsa det rätt.
- @context namnger den vokabulär som varje fält i dokumentet är definierat i.
- @type anger vilken sorts sak dokumentet beskriver, så att rätt definitioner hämtas ur den vokabulären.
Ingenting i själva data ändras. Samma värden i samma form bär nu en pekare till definitionen av varje fält. Ett mottagande system som känner igen vokabulären vet exakt vad det fick, och ett som inte gör det kan fortfarande läsa dokumentet som vanlig JSON och bortse från resten.
Det är hela idén. Betydelsen färdas med dokumentet i stället för att bo i en specifikation som de två parterna måste komma överens om i förväg.
Var det dyker upp i verifierbara intyg
W3C Verifiable Credentials Data Model 2.0, W3C Recommendation sedan den 15 maj 2025, är byggd på JSON-LD. Varje intyg inleds med en @context vars första värde är den gemensamma intygsvokabulären, så att de begrepp alla intyg har gemensamt, utfärdaren, subjektet, giltighetsdatumen och statusinformationen, betyder samma sak överallt.
Allt därutöver kommer från en andra vokabulär. Ett universitet publicerar en för examensfält, en handelskammare en för fält om företagsregistrering. En verifierare som bryr sig om examina laddar den första, en som bryr sig om företagsdata laddar den andra, och ingen av dem behöver ändras när den andra lägger till ett fält.
Det är detta som låter ett enda intygsformat bära data som ingen förutsåg när formatet skrevs, och det är egenskapen som ett öppet ekosystem behöver och en sluten profil inte gör.
Att signera länkade data
Ett intyg måste också signeras, och datamodellen lämnar medvetet ett val där. Ett omslutande bevis packar in hela intyget i en signaturbehållare som ett JWT. Byten signeras exakt som de är, så allt som ordnar om eller formaterar om dem på vägen bryter signaturen.
Ett inbäddat Data Integrity-bevis fungerar tvärtom. Dokumentet förs först till en kanonisk form, definierad av RDF Dataset Canonicalization och W3C Recommendation sedan den 21 maj 2024, och signaturen täcker den formen i stället för byten. Eftersom den kanoniska formen inte beror på nyckelordning, blanksteg eller vilka korta namn @context råkar använda, överlever signaturen att dokumentet skrivs ut på nytt någon annanstans.
Var det passar in i EUDI Wallet
Inte där de flesta antar. Architecture and Reference Framework pekar ut två intygsformat för den europeiska plånboken, SD-JWT VC och mdoc, och inget av dem är JSON-LD. En organisation som utfärdar till EUDI Wallet i dag kommer inte att möta någon @context på vägen.
Skälet är genomförbarhet. Båda formaten har en fast struktur, en enda signaturmekanism och inget dokument som en verifierare måste hämta innan den kan kontrollera något alls. För en plånbok som kör på en telefon och en verifierare som måste svara på millisekunder är det värt mer än en öppen vokabulär.
JSON-LD gör sig förtjänt av sin plats där data måste färdas bortom det ekosystem som definierade dem: produktpass och data i leveranskedjan, piloter över sektorsgränser, och intygstyper som ingen central profil någonsin kommer att räkna upp. De två världarna överlappar oftare än de konkurrerar, och organisationer som arbetar i båda brukar sluta med att stödja bägge.
Det andra JSON-LD, det du redan har använt
Långt före intygen blev JSON-LD sättet på vilket en webbplats talar om för en sökmotor vad en sida handlar om. Ett block av det i sidans källkod, med schema.org-vokabulären, är det som gör en sida till en igenkänd artikel, produkt, händelse eller organisation. Den här sidan bär ett sådant block.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD förklarat",
"description": "Vad JSON-LD tillför vanlig JSON, hur en @context ger varje fält en enda betydelse och var verifierbara intyg använder det.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "sv",
"mainEntityOfPage": "https://www.credenco.com/sv/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 är samma format med en annan vokabulär, och det är det tydligaste sättet att se poängen. Ingen här har kommit överens om något med någon sökmotor. @context pekar mot schema.org, sökmotorn kan redan den vokabulären, och sidan förstås av en part den aldrig talat med. Ett intyg som korsar en gräns gör exakt samma sak.
Vad det kostar
Kontexten måste vara tillgänglig. En verifierare som hämtar den vid verifieringstillfället har lagt ett nätverksberoende i ett säkerhetsbeslut, och den som serverar dokumentet kan ändra vad intyget verkar säga. Riktiga installationer låser de kontexter de godtar och levererar dem med programvaran i stället för att slå upp dem i realtid.
Kanonisering är också riktigt arbete. Att göra om ett dokument till en kanonisk datamängd före signering är betydligt mer kod än att signera byte, och felsätten är subtila. Dokumenten är dessutom större, vilket börjar spela roll på en QR-kod eller vid en NFC-tryckning.
Inget av detta gör JSON-LD till fel val. Det gör det till ett val: betala för öppna vokabulärer där data måste överleva den överenskommelse som skapade dem, och hoppa över dem där en fast profil redan säger allt som de två parterna behöver.
Vad detta betyder för dig
Utfärdare
Att utfärda till EUDI Wallet betyder SD-JWT VC eller mdoc, och JSON-LD kommer aldrig upp. Att utfärda till ett W3C-ekosystem gör din @context till ett långsiktigt åtagande: den är den offentliga definitionen av dina fält, och att ändra den slår sönder varje verifierare som cachat den gamla.
Verifierare
Bestäm vilka kontexter du godtar och leverera dem med din programvara. Att hämta en under verifieringen gör en fjärrserver till en del av ditt säkerhetsbeslut och lägger ett nätverksanrop mitt i din svarstid.
Utvecklare
Läs ett JSON-LD-dokument som vanlig JSON när allt du behöver är ett fält, och ta fram en fullständig processor bara där du faktiskt expanderar eller kanoniserar. Det mesta av den komplexitet som tillskrivs JSON-LD sitter i signeringsvägen, inte i läsvägen.
Relaterade termer
Vanliga frågor
Är JSON-LD fortfarande bara JSON?
Ja. Varje JSON-LD-dokument är giltig JSON, och programvara som bara behöver läsa ett fält kan behandla det som sådant. Det extra maskineriet kommer in först när du expanderar ett dokument till dess fulla form eller kanoniserar det för signering, vilket den mesta kod som läser ett intyg aldrig gör.
Använder EUDI Wallet JSON-LD?
Nej. Architecture and Reference Framework pekar ut SD-JWT VC och mdoc som intygsformat, och inget av dem använder JSON-LD. Det spelar roll för W3C-ekosystem med verifierbara intyg, för produktpass och för data i leveranskedjan, inte för den europeiska plånboken i sig.
Laddar en verifierare ned @context varje gång?
Det bör den inte. Att hämta en kontext under verifieringen placerar ett nätverksanrop mitt i ett säkerhetsbeslut och ger en fjärrserver möjligheten att ändra vad dokumentet verkar säga. Implementationer låser de kontexter de godtar och levererar dem med programvaran, vilket också tar bort fördröjningen.
Är detta samma JSON-LD som sökmotorer läser?
Samma format med en annan vokabulär. Strukturerade data på en webbsida riktar sin @context mot schema.org, medan ett intyg riktar den mot intygsvokabulären och det övriga det behöver. Bearbetningsreglerna är identiska i båda fallen.
Källor
Den här sidan är informativ och utgör inte juridisk rådgivning. För auktoritativ vägledning, läs specifikationerna från W3C direkt.