JSON-LD erklärt
JSON-LD ist gewöhnliches JSON mit einer zusätzlichen Zeile, die sagt, was die Felder bedeuten. Diese Zeile macht aus einem lokalen Feldnamen einen global definierten, sodass ein System, das Ihre Daten noch nie gesehen hat, trotzdem herausfinden kann, wovon Sie sprechen. Es ist seit 2014 ein W3C-Standard, es ist die Art, wie Suchmaschinen genau diese Seite lesen, und es ist die Grundlage des W3C-Datenmodells für verifizierbare Credentials.
Das Problem mit einfachem JSON
JSON sagt, wie Daten aufgeschrieben werden. Es sagt nichts darüber, was davon etwas bedeutet. Ein Feld namens name kann eine Person, ein Unternehmen oder ein Produkt sein. Ein Feld namens id kann eine Kundennummer, eine Passnummer oder eine Zeile in irgendeiner Datenbank sein. Zwei Systeme können beide völlig gültiges JSON ausgeben und sich trotzdem über jedes Feld darin uneinig sein.
In der Praxis wird diese Lücke durch eine Vereinbarung geschlossen. Beide Seiten halten fest, was die Felder bedeuten, und bauen ihre Software passend dazu. Das funktioniert bei einer Integration, wird bei zehn teuer und funktioniert überhaupt nicht mehr, wenn ein in einem Land ausgestelltes Credential von einem Prüfer in einem anderen Land verstanden werden muss, mit dem vorher niemand gesprochen hat.
Was der @context leistet
JSON-LD schließt diese Lücke im Dokument selbst. Ein @context bildet jeden kurzen Feldnamen auf eine global eindeutige Kennung ab, normalerweise eine URL, die von demjenigen kontrolliert wird, der das Vokabular definiert hat. Das Feld bleibt kurz und für Menschen lesbar und wird für Maschinen eindeutig.
Einfaches JSON
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Gültig, lesbar und bedeutungslos für jeden, dem niemand vorher gesagt hat, was in den Feldern stehen soll.
Dieselben Daten als JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Jedes Feld verweist jetzt auf eine veröffentlichte Definition, sodass ein System, das dieses Dokument noch nie gesehen hat, es trotzdem korrekt lesen kann.
- @context benennt das Vokabular, in dem jedes Feld des Dokuments definiert ist.
- @type sagt, welche Art von Sache das Dokument beschreibt, damit die richtigen Definitionen aus diesem Vokabular gewählt werden.
An den Daten selbst ändert sich nichts. Dieselben Werte in derselben Form tragen nun einen Verweis auf die Definition jedes Feldes. Ein empfangendes System, das das Vokabular kennt, weiß genau, was es bekommen hat, und eines, das es nicht kennt, kann das Dokument weiterhin als gewöhnliches JSON lesen und den Rest ignorieren.
Das ist die ganze Idee. Die Bedeutung reist mit dem Dokument, statt in einer Spezifikation zu stecken, auf die sich beide Seiten vorher einigen mussten.
Wo es bei verifizierbaren Credentials auftaucht
Das W3C Verifiable Credentials Data Model 2.0, seit dem 15. Mai 2025 eine W3C Recommendation, baut auf JSON-LD auf. Jedes Credential beginnt mit einem @context, dessen erster Wert das gemeinsame Credential-Vokabular ist, sodass die Begriffe, die alle Credentials teilen, der Aussteller, das Subjekt, die Gültigkeitsdaten und die Statusinformationen, überall dasselbe bedeuten.
Alles darüber hinaus kommt aus einem zweiten Vokabular. Eine Universität veröffentlicht eines für Diplomfelder, eine Handelskammer eines für Felder zur Unternehmensregistrierung. Ein Prüfer, dem Diplome wichtig sind, lädt das erste, ein Prüfer, dem Unternehmensdaten wichtig sind, lädt das zweite, und keiner von beiden muss geändert werden, wenn der andere ein Feld ergänzt.
Genau das erlaubt es einem einzigen Credential-Format, Daten zu tragen, die beim Schreiben des Formats niemand vorhergesehen hat, und das ist die Eigenschaft, die ein offenes Ökosystem braucht und ein geschlossenes Profil nicht.
Verknüpfte Daten signieren
Ein Credential muss auch signiert werden, und das Datenmodell lässt dort bewusst eine Wahl. Ein umhüllender Nachweis verpackt das gesamte Credential in einen Signaturcontainer wie ein JWT. Die Bytes werden genau so signiert, wie sie sind, also bricht alles, was sie unterwegs umsortiert oder neu formatiert, die Signatur.
Ein eingebetteter Data-Integrity-Nachweis funktioniert umgekehrt. Das Dokument wird zuerst in eine kanonische Form gebracht, definiert durch RDF Dataset Canonicalization und seit dem 21. Mai 2024 eine W3C Recommendation, und die Signatur deckt diese Form statt der Bytes ab. Weil die kanonische Form nicht von der Schlüsselreihenfolge, von Leerzeichen oder davon abhängt, welche Kurznamen der @context gerade verwendet, übersteht die Signatur ein erneutes Ausschreiben an anderer Stelle.
Wo es in die EUDI Wallet passt
Nicht dort, wo die meisten es vermuten. Das Architecture and Reference Framework nennt zwei Credential-Formate für die europäische Wallet, SD-JWT VC und mdoc, und keines davon ist JSON-LD. Eine Organisation, die heute in die EUDI Wallet ausstellt, begegnet unterwegs keinem @context.
Der Grund ist die Umsetzbarkeit. Beide Formate haben eine feste Struktur, einen einzigen Signaturmechanismus und kein Dokument, das ein Prüfer erst holen muss, bevor er irgendetwas prüfen kann. Für eine Wallet, die auf einem Telefon läuft, und einen Prüfer, der in Millisekunden antworten muss, ist das mehr wert als ein offenes Vokabular.
JSON-LD verdient seinen Platz dort, wo Daten über das Ökosystem hinaus reisen müssen, das sie definiert hat: Produktpässe und Lieferkettendaten, sektorübergreifende Pilotprojekte und Credential-Typen, die kein zentrales Profil jemals aufzählen wird. Die beiden Welten überschneiden sich häufiger, als sie konkurrieren, und Organisationen, die in beiden arbeiten, unterstützen am Ende meist beide.
Das andere JSON-LD, das Sie längst benutzt haben
Lange vor Credentials wurde JSON-LD zu der Art, wie eine Website einer Suchmaschine mitteilt, worum es auf einer Seite geht. Ein Block davon im Seitenquelltext, mit dem Vokabular von schema.org, macht aus einer Seite einen erkannten Artikel, ein Produkt, eine Veranstaltung oder eine Organisation. Diese Seite trägt einen solchen Block.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD erklärt",
"description": "Was JSON-LD einfachem JSON hinzufügt, wie ein @context jedem Feld eine Bedeutung gibt und wo verifizierbare Credentials es nutzen.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "de",
"mainEntityOfPage": "https://www.credenco.com/de/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"
}
}
}Es ist dasselbe Format mit einem anderen Vokabular, und es ist der klarste Weg, den Punkt zu sehen. Niemand hier hat mit irgendeiner Suchmaschine etwas vereinbart. Der @context zeigt auf schema.org, die Suchmaschine kennt dieses Vokabular bereits, und die Seite wird von einer Stelle verstanden, mit der sie nie gesprochen hat. Ein Credential, das eine Grenze überquert, tut genau dasselbe.
Was es kostet
Der Kontext muss verfügbar sein. Ein Prüfer, der ihn zum Prüfzeitpunkt lädt, hat einer Sicherheitsentscheidung eine Netzwerkabhängigkeit hinzugefügt, und wer dieses Dokument ausliefert, kann ändern, was das Credential scheinbar aussagt. Echte Installationen legen die akzeptierten Kontexte fest und liefern sie mit der Software aus, statt sie live aufzulösen.
Auch die Kanonisierung ist echte Arbeit. Ein Dokument vor dem Signieren in einen kanonischen Datensatz zu überführen ist erheblich mehr Code als Bytes zu signieren, und die Fehlerbilder sind subtil. Die Dokumente sind außerdem größer, was auf einem QR-Code oder bei einem NFC-Kontakt ins Gewicht fällt.
Nichts davon macht JSON-LD zur falschen Wahl. Es macht es zu einer Wahl: Zahlen Sie für offene Vokabulare, wo Daten die Vereinbarung überleben müssen, die sie hervorgebracht hat, und lassen Sie sie weg, wo ein festes Profil bereits alles sagt, was beide Seiten brauchen.
Was das für Sie bedeutet
Aussteller
In die EUDI Wallet auszustellen bedeutet SD-JWT VC oder mdoc, und JSON-LD kommt dabei nie vor. In ein W3C-Ökosystem auszustellen macht Ihren @context zu einer langfristigen Verpflichtung: Er ist die öffentliche Definition Ihrer Felder, und ihn zu ändern bricht jeden Prüfer, der die alte Fassung zwischengespeichert hat.
Prüfer
Entscheiden Sie, welche Kontexte Sie akzeptieren, und liefern Sie sie mit Ihrer Software aus. Einen während der Prüfung zu laden macht einen fremden Server zum Teil Ihrer Sicherheitsentscheidung und setzt einen Netzwerkaufruf mitten in Ihre Antwortzeit.
Entwickler
Lesen Sie ein JSON-LD-Dokument als gewöhnliches JSON, wenn Sie nur ein Feld brauchen, und greifen Sie erst dann zu einem vollständigen Prozessor, wenn Sie tatsächlich ausklappen oder kanonisieren. Der größte Teil der Komplexität, die man JSON-LD zuschreibt, steckt im Signaturpfad, nicht im Lesepfad.
Verwandte Begriffe
Häufig gestellte Fragen
Ist JSON-LD immer noch einfach JSON?
Ja. Jedes JSON-LD-Dokument ist gültiges JSON, und Software, die nur ein Feld lesen muss, kann es genau so behandeln. Die zusätzliche Mechanik kommt erst ins Spiel, wenn Sie ein Dokument in seine vollständige Form ausklappen oder es zum Signieren kanonisieren, was der größte Teil des Codes, der ein Credential liest, nie tut.
Nutzt die EUDI Wallet JSON-LD?
Nein. Das Architecture and Reference Framework nennt SD-JWT VC und mdoc als Credential-Formate, und keines von beiden nutzt JSON-LD. Wichtig ist es für W3C-Ökosysteme mit verifizierbaren Credentials, für Produktpässe und Lieferkettendaten, nicht für die europäische Wallet selbst.
Lädt ein Prüfer den @context jedes Mal herunter?
Das sollte er nicht. Einen Kontext während der Prüfung zu laden setzt einen Netzwerkaufruf mitten in eine Sicherheitsentscheidung und gibt einem fremden Server die Möglichkeit zu ändern, was das Dokument scheinbar aussagt. Implementierungen legen die akzeptierten Kontexte fest und liefern sie mit der Software aus, was auch die Latenz beseitigt.
Ist das dasselbe JSON-LD, das Suchmaschinen lesen?
Dasselbe Format mit einem anderen Vokabular. Strukturierte Daten auf einer Webseite richten ihren @context auf schema.org, während ein Credential ihn auf das Credential-Vokabular und auf alles Weitere richtet, was es braucht. Die Verarbeitungsregeln sind in beiden Fällen identisch.
Quellen
Diese Seite dient nur zur Information und stellt keine Rechtsberatung dar. Für maßgebliche Hinweise konsultieren Sie bitte direkt die Spezifikationen des W3C.