Přejít na hlavní obsah

JSON-LD vysvětlen

JSON-LD je obyčejný JSON s jedním řádkem navíc, který říká, co pole znamenají. Ten řádek mění lokální název pole na globálně definovaný, takže systém, který vaše data nikdy neviděl, přesto pozná, o čem mluvíte. Je to standard W3C od roku 2014, takto čtou vyhledávače právě tuto stránku a právě na něm stojí datový model W3C pro ověřitelná pověření.

Problém obyčejného JSON

JSON říká, jak se data zapisují. Neříká nic o tom, co znamenají. Pole jménem name může být osoba, firma nebo produkt. Pole jménem id může být číslo zákazníka, číslo pasu nebo řádek v něčí databázi. Dva systémy mohou oba vydávat naprosto platný JSON a přesto se neshodnout na žádném jeho poli.

V praxi se ta mezera zacelí dohodou. Obě strany sepíší, co pole znamenají, a podle toho postaví svůj software. To funguje u jedné integrace, u deseti začne být drahé a přestane fungovat úplně, když pověření vydané v jedné zemi musí pochopit ověřovatel v jiné, se kterým nikdo předem nemluvil.

Co dělá @context

JSON-LD tu mezeru zaceluje uvnitř samotného dokumentu. @context přiřazuje každému krátkému názvu pole celosvětově jedinečný identifikátor, obvykle URL, kterou spravuje ten, kdo slovník definoval. Pole zůstává krátké a čitelné pro člověka a stává se jednoznačným pro stroj.

Obyčejný JSON

{
  "name": "Alex Jansen",
  "birthDate": "1994-03-21",
  "jobTitle": "Compliance Officer"
}

Platný, čitelný a bezvýznamný pro každého, komu nikdo předem neřekl, co mají pole obsahovat.

Stejná data jako JSON-LD

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Alex Jansen",
  "birthDate": "1994-03-21",
  "jobTitle": "Compliance Officer"
}

Každé pole nyní ukazuje na zveřejněnou definici, takže systém, který tento dokument nikdy neviděl, ho přesto přečte správně.

  • @context pojmenovává slovník, v němž je definováno každé pole dokumentu.
  • @type říká, jakou věc dokument popisuje, aby se z toho slovníku vybraly správné definice.
Dva přidané řádky jsou celý rozdíl. Nezměnila se ani jedna hodnota.

Na samotných datech se nic nemění. Stejné hodnoty ve stejné podobě nyní nesou odkaz na definici každého pole. Přijímající systém, který slovník zná, přesně ví, co dostal, a ten, který ho nezná, může dokument dál číst jako obyčejný JSON a zbytek ignorovat.

V tom je celá myšlenka. Význam cestuje s dokumentem, místo aby bydlel ve specifikaci, na které se obě strany musely předem dohodnout.

Kde se objevuje u ověřitelných pověření

W3C Verifiable Credentials Data Model 2.0, od 15. května 2025 W3C Recommendation, stojí na JSON-LD. Každé pověření začíná @context, jehož první hodnotou je sdílený slovník pověření, takže pojmy, které mají všechna pověření společné, vydavatel, subjekt, data platnosti a stavová informace, znamenají všude totéž.

Vše ostatní pochází z druhého slovníku. Univerzita jeden zveřejňuje pro pole diplomů, hospodářská komora jeden pro pole o registraci firem. Ověřovatel, kterému jde o diplomy, načte první, ověřovatel, kterému jde o firemní data, načte druhý, a ani jeden se nemusí měnit, když ten druhý přidá pole.

Právě to umožňuje jedinému formátu pověření nést data, která nikdo nepředvídal, když formát vznikal, a to je vlastnost, kterou otevřený ekosystém potřebuje a uzavřený profil ne.

Podepisování propojených dat

Pověření se také musí podepsat a datový model tam záměrně nechává volbu. Obalující důkaz zabalí celé pověření do podpisového kontejneru, například do JWT. Bajty se podepisují přesně tak, jak jsou, takže cokoli, co je cestou přeskládá nebo přeformátuje, podpis rozbije.

Vložený důkaz Data Integrity funguje opačně. Dokument se nejprve převede do kanonické podoby, kterou definuje RDF Dataset Canonicalization a která je od 21. května 2024 W3C Recommendation, a podpis pokrývá tuto podobu místo bajtů. Protože kanonická podoba nezávisí na pořadí klíčů, na mezerách ani na tom, jaké krátké názvy @context zrovna používá, podpis přežije i to, že se dokument někde jinde zapíše znovu.

Kam zapadá v EUDI Wallet

Ne tam, kde to většina lidí předpokládá. Architecture and Reference Framework uvádí pro evropskou peněženku dva formáty pověření, SD-JWT VC a mdoc, a ani jeden z nich není JSON-LD. Organizace, která dnes vydává do EUDI Wallet, cestou na žádný @context nenarazí.

Důvodem je proveditelnost. Oba formáty mají pevnou strukturu, jediný podpisový mechanismus a žádný dokument, který by si ověřovatel musel stáhnout, než může cokoli zkontrolovat. Pro peněženku běžící v telefonu a pro ověřovatele, který musí odpovědět v milisekundách, to má větší cenu než otevřený slovník.

JSON-LD si své místo zaslouží tam, kde data musí cestovat mimo ekosystém, který je definoval: produktové pasy a data dodavatelského řetězce, mezioborové pilotní projekty a typy pověření, které žádný centrální profil nikdy nevyjmenuje. Tyto dva světy se překrývají častěji, než si konkurují, a organizace působící v obou obvykle skončí u podpory obou.

Ten druhý JSON-LD, který už dávno používáte

Dlouho před pověřeními se JSON-LD stal způsobem, jak web říká vyhledávači, o čem stránka je. Jeho blok ve zdrojovém kódu stránky, se slovníkem schema.org, je to, co ze stránky dělá rozpoznaný článek, produkt, událost nebo organizaci. Tato stránka takový blok nese.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LD vysvětlen",
  "description": "Co JSON-LD přidává k obyčejnému JSON, jak @context dává každému poli jediný význam a kde jej používají ověřitelná pověření.",
  "image": "https://www.credenco.com/images/og-default.jpg",
  "datePublished": "2026-10-15",
  "dateModified": "2026-10-15",
  "inLanguage": "cs",
  "mainEntityOfPage": "https://www.credenco.com/cs/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"
    }
  }
}

Je to tentýž formát s jiným slovníkem a je to nejjasnější způsob, jak tu pointu vidět. Nikdo tady se s žádným vyhledávačem na ničem nedohodl. @context ukazuje na schema.org, vyhledávač ten slovník už zná a stránce rozumí strana, se kterou nikdy nemluvila. Pověření překračující hranici dělá přesně totéž.

Co to stojí

Kontext musí být dostupný. Ověřovatel, který si jej stáhne v okamžiku ověření, přidal k bezpečnostnímu rozhodnutí síťovou závislost, a ten, kdo tento dokument poskytuje, může změnit, co pověření zdánlivě říká. Skutečná nasazení si přijímané kontexty fixují a dodávají je se softwarem, místo aby je řešila za běhu.

Kanonizace je také skutečná práce. Převést dokument před podpisem do kanonické datové sady je podstatně víc kódu než podepsat bajty a způsoby, jak může selhat, jsou nenápadné. Dokumenty jsou navíc větší, což začíná hrát roli na QR kódu nebo při přiložení NFC.

Nic z toho nedělá z JSON-LD špatnou volbu. Dělá z něj volbu: zaplaťte za otevřené slovníky tam, kde data musí přežít dohodu, která je vytvořila, a vynechte je tam, kde pevný profil už říká vše, co obě strany potřebují.

Co to znamená pro vás

Vydavatel

Vydávat do EUDI Wallet znamená SD-JWT VC nebo mdoc a JSON-LD nikdy nepřijde na řadu. Vydávat do ekosystému W3C dělá z vašeho @context dlouhodobý závazek: je to veřejná definice vašich polí a jeho změna rozbije každého ověřovatele, který si uložil tu starou.

Ověřovatel

Rozhodněte, které kontexty přijímáte, a dodávejte je se svým softwarem. Stáhnout si jeden během ověřování udělá ze vzdáleného serveru součást vašeho bezpečnostního rozhodnutí a vloží síťové volání doprostřed vaší doby odezvy.

Vývojář

Čtěte dokument JSON-LD jako obyčejný JSON, když potřebujete jen jedno pole, a po plném procesoru sáhněte až tam, kde skutečně rozbalujete nebo kanonizujete. Většina složitosti, kterou lidé JSON-LD připisují, sedí v cestě podpisu, ne v cestě čtení.

Související pojmy

Často kladené otázky

Je JSON-LD pořád jen JSON?

Ano. Každý dokument JSON-LD je platný JSON a software, který potřebuje přečíst jen jedno pole, s ním tak může zacházet. Další mechanika přichází ke slovu až ve chvíli, kdy dokument rozbalíte do plné podoby nebo jej kanonizujete kvůli podpisu, což většina kódu čtoucího pověření nikdy nedělá.

Používá EUDI Wallet JSON-LD?

Ne. Architecture and Reference Framework uvádí jako formáty pověření SD-JWT VC a mdoc a ani jeden z nich JSON-LD nepoužívá. Záleží na něm v ekosystémech W3C s ověřitelnými pověřeními, u produktových pasů a u dat dodavatelského řetězce, nikoli u samotné evropské peněženky.

Stahuje ověřovatel @context pokaždé?

Neměl by. Stažení kontextu během ověřování vkládá síťové volání doprostřed bezpečnostního rozhodnutí a dává vzdálenému serveru možnost změnit, co dokument zdánlivě říká. Implementace si přijímané kontexty fixují a dodávají je se softwarem, což zároveň odstraní zpoždění.

Je to tentýž JSON-LD, který čtou vyhledávače?

Tentýž formát s jiným slovníkem. Strukturovaná data na webové stránce míří svým @context na schema.org, zatímco pověření jím míří na slovník pověření a na cokoli dalšího, co potřebuje. Pravidla zpracování jsou v obou případech stejná.

Zdroje

  1. JSON-LD 1.1, W3C Recommendation, 16. července 2020
  2. Verifiable Credentials Data Model 2.0, W3C Recommendation, 15. května 2025
  3. Verifiable Credential Data Integrity 1.0, W3C Recommendation, 15. května 2025
  4. RDF Dataset Canonicalization, W3C Recommendation, 21. května 2024

Tato stránka je informativní a nepředstavuje právní poradenství. Pro závazné pokyny nahlédněte přímo do specifikací W3C.

Promluvte si s námi o formátech pověření a interoperabilitě