JSON-LD
JSON-LD ist gewöhnliches JSON mit einem zusätzlichen Feld, @context, das sagt, was die übrigen Felder bedeuten. Der Kontext bildet jeden kurzen Feldnamen auf eine global eindeutige Kennung ab, in der Regel eine URL, die von demjenigen veröffentlicht wurde, der das Vokabular definiert hat, sodass ein System, das die Daten noch nie gesehen hat, trotzdem herausfinden kann, was ihm mitgeteilt wird.
Gewöhnliches JSON sagt, wie Daten aufgeschrieben werden, nicht was sie bedeuten. Ein Feld namens name kann eine Person, ein Unternehmen oder ein Produkt enthalten, und zwei Systeme können beide gültiges JSON ausgeben und sich dennoch über jedes einzelne Feld uneinig sein. Diese Lücke wird normalerweise durch eine schriftliche Vereinbarung zwischen den beiden Parteien geschlossen, was für eine Integration funktioniert und aufhört zu funktionieren, sobald ein in einem Land ausgestelltes Credential von einem Verifier in einem anderen Land gelesen werden muss, mit dem vorher niemand gesprochen hat.
JSON-LD schließt sie im Dokument selbst. Der @context bildet jeden kurzen Feldnamen auf eine global eindeutige Kennung ab, sodass das Feld für Menschen lesbar bleibt und für Maschinen eindeutig wird. Keiner der Werte ändert sich, und ein Empfänger, der das Vokabular nicht kennt, kann das Dokument weiterhin als gewöhnliches JSON lesen und den Rest ignorieren. JSON-LD 1.0 wurde am 16. Januar 2014 eine W3C Recommendation, Version 1.1 folgte am 16. Juli 2020.
Das W3C Verifiable Credentials Data Model 2.0 baut darauf auf. Jedes Credential beginnt mit einem @context, dessen erster Wert das gemeinsame Credential-Vokabular ist, sodass der Aussteller, das Subjekt, die Gültigkeitsdaten und die Statusinformationen überall dasselbe bedeuten, und jedes weitere Vokabular liefert die Felder, die ein bestimmter Credential-Typ braucht.
Ein Linked-Data-Dokument zu signieren ist eine Wahl zwischen zwei Mechanismen. Ein umhüllender Nachweis wie ein JWT signiert die Bytes genau so, wie sie sind, sodass alles, was sie unterwegs umsortiert oder neu formatiert, die Signatur zerstört. Ein eingebetteter Data-Integrity-Nachweis signiert stattdessen eine kanonische Form, definiert durch RDF Dataset Canonicalization, und genau das lässt die Signatur ein erneutes Ausschreiben an anderer Stelle überstehen.
Es ist keines der Credential-Formate der EUDI Wallet. Das Architecture and Reference Framework nennt SD-JWT VC und mdoc, und keines von beiden verwendet JSON-LD, sodass eine Organisation, die in die europäische Wallet ausstellt, nie einem @context begegnet. JSON-LD verdient seinen Platz dort, wo Daten über das Ökosystem hinausreisen müssen, das sie definiert hat: W3C-Credential-Implementierungen, Produktpässe und Lieferkettendaten.
Dasselbe Format ist auch die Art, wie eine Website einer Suchmaschine mitteilt, worum es auf einer Seite geht, wobei der @context auf schema.org statt auf ein Credential-Vokabular zeigt. Die Verarbeitungsregeln sind in beiden Fällen identisch, was strukturierte Daten zum einfachsten Ort macht, um zu sehen, was ein Kontext tatsächlich bringt.
Die vollständige Erklärung lesen
Diese Seite gibt die kurze Definition. Unsere Erklärung zeigt, was das in der Praxis bedeutet: wer beteiligt ist, wie es funktioniert und was sich für Ihre Organisation ändert.
JSON-LD erklärtVerwandte Begriffe
Ist JSON-LD eines der Credential-Formate der EUDI Wallet?
Nein. Das Architecture and Reference Framework nennt SD-JWT VC und mdoc, und keines von beiden ist ein JSON-LD-Format, sodass eine Wallet oder ein Verifier, die für die europäischen Regeln gebaut sind, überhaupt keinen JSON-LD-Prozessor brauchen.
Das ist eine Entscheidung über den Geltungsbereich, kein Urteil über das Format. Beide vom Rahmenwerk genannten Formate haben eine feste Gestalt, einen einzigen Signaturmechanismus und kein Dokument, das ein Verifier erst abrufen muss, bevor er etwas prüfen kann, und genau das belohnen ein Telefon und eine in Millisekunden gemessene Antwortzeit. JSON-LD beantwortet eine andere Frage, nämlich wie Daten ihre Bedeutung außerhalb des Ökosystems behalten, das sie definiert hat, und Organisationen, die in beiden Welten arbeiten, unterstützen am Ende meist beides.
Was ist der Unterschied zwischen JSON-LD und gewöhnlichem JSON?
Nichts daran, wie das Dokument geschrieben ist: Jedes JSON-LD-Dokument ist gültiges JSON, und Software, die nur ein einziges Feld daraus braucht, kann es auch so behandeln. Der Unterschied ist der @context, der jeden Feldnamen auf eine global definierte Kennung abbildet, sodass die Bedeutung der Daten mit dem Dokument mitreist, statt in einer Spezifikation zu stecken, auf die sich die beiden Parteien vorher einigen mussten.
Die zusätzliche Maschinerie zählt erst, wenn ein Dokument in seine vollständige Form expandiert oder zum Signieren kanonisiert wird, Schritte, die ein Verifier beim Lesen einer einzelnen Aussage nie ausführt. Der eigentliche Preis liegt woanders: Der Kontext muss verfügbar sein, und ein Verifier, der ihn während der Prüfung lädt, hat einen Netzwerkaufruf und einen fremden Server mitten in eine Sicherheitsentscheidung gesetzt. Implementierungen legen die akzeptierten Kontexte fest und liefern sie stattdessen mit der Software aus.