JSON-LD
JSON-LD, c'est du JSON ordinaire avec un champ supplémentaire, @context, qui dit ce que signifient les autres champs. Le contexte associe chaque nom de champ abrégé à un identifiant unique au niveau mondial, en général une URL publiée par celui qui a défini le vocabulaire, de sorte qu'un système qui n'a jamais vu ces données peut tout de même comprendre ce qu'on lui dit.
Le JSON ordinaire dit comment les données sont écrites, pas ce qu'elles signifient. Un champ nommé name peut contenir une personne, une entreprise ou un produit, et deux systèmes peuvent tous deux émettre du JSON valide tout en étant en désaccord sur chacun de ses champs. Cet écart est normalement comblé par un accord écrit entre les deux parties, ce qui fonctionne pour une intégration et cesse de fonctionner dès qu'une attestation émise dans un pays doit être lue par un vérificateur d'un autre pays à qui personne n'a parlé au préalable.
JSON-LD comble cet écart à l'intérieur même du document. Le @context associe chaque nom de champ abrégé à un identifiant unique au niveau mondial, de sorte que le champ reste lisible pour un humain et devient sans ambiguïté pour une machine. Aucune des valeurs ne change, et un destinataire qui ne reconnaît pas le vocabulaire peut toujours lire le document comme du JSON ordinaire et ignorer le reste. JSON-LD 1.0 est devenu une W3C Recommendation le 16 janvier 2014, et la version 1.1 a suivi le 16 juillet 2020.
Le W3C Verifiable Credentials Data Model 2.0 est construit dessus. Chaque attestation s'ouvre sur un @context dont la première valeur est le vocabulaire partagé des attestations, de sorte que l'émetteur, le sujet, les dates de validité et les informations de statut signifient partout la même chose, et tout vocabulaire supplémentaire fournit les champs dont un type d'attestation particulier a besoin.
Signer un document de données liées suppose de choisir entre deux mécanismes. Une preuve enveloppante telle qu'un JWT signe les octets exactement tels qu'ils sont, de sorte que tout ce qui les réordonne ou les reformate en chemin casse la signature. Une preuve Data Integrity intégrée signe à la place une forme canonique, définie par RDF Dataset Canonicalization, ce qui permet à la signature de survivre à une réécriture ailleurs.
Ce n'est pas l'un des formats d'attestation de l'EUDI Wallet. L'Architecture and Reference Framework désigne SD-JWT VC et mdoc, et aucun des deux n'utilise JSON-LD, si bien qu'une organisation qui émet vers le portefeuille européen ne rencontrera jamais de @context. JSON-LD trouve sa place là où les données doivent voyager au-delà de l'écosystème qui les a définies : déploiements d'attestations W3C, passeports de produits et données de chaîne d'approvisionnement.
Le même format est aussi la manière dont un site web indique à un moteur de recherche de quoi parle une page, le @context pointant alors vers schema.org plutôt que vers un vocabulaire d'attestations. Les règles de traitement sont identiques dans les deux cas, ce qui fait des données structurées l'endroit le plus simple pour voir ce qu'un contexte apporte réellement.
Lire l'explication complète
Cette page donne la définition courte. Notre explication montre ce que cela signifie en pratique : qui est concerné, comment cela fonctionne et ce qui change pour votre organisation.
JSON-LD expliquéJSON-LD fait-il partie des formats d'attestation de l'EUDI Wallet ?
Non. L'Architecture and Reference Framework désigne SD-JWT VC et mdoc, et aucun des deux n'est un format JSON-LD : un portefeuille ou un vérificateur conçu pour les règles européennes n'a donc besoin d'aucun processeur JSON-LD.
Il s'agit d'un choix de périmètre, pas d'un verdict sur le format. Les deux formats désignés par le cadre ont une forme fixe, un seul mécanisme de signature et aucun document qu'un vérificateur doive aller chercher avant de pouvoir vérifier quoi que ce soit, ce que récompensent un téléphone et un temps de réponse mesuré en millisecondes. JSON-LD répond à une autre question, celle de savoir comment les données conservent leur sens en dehors de l'écosystème qui les a définies, et les organisations qui travaillent dans les deux mondes finissent généralement par prendre en charge les deux.
Quelle est la différence entre JSON-LD et le JSON ordinaire ?
Aucune dans la façon dont le document est écrit : tout document JSON-LD est du JSON valide, et un logiciel qui n'a besoin que d'un champ peut le traiter comme tel. La différence tient au @context, qui associe chaque nom de champ à un identifiant défini au niveau mondial, de sorte que le sens des données voyage avec le document au lieu de résider dans une spécification que les deux parties devaient convenir au préalable.
La machinerie supplémentaire ne compte que lorsqu'un document est développé dans sa forme complète ou canonicalisé pour être signé, des étapes qu'un vérificateur qui lit une seule déclaration n'effectue jamais. Le vrai coût est ailleurs : le contexte doit être disponible, et un vérificateur qui le récupère pendant la vérification a placé un appel réseau et un serveur distant au cœur d'une décision de sécurité. Les implémentations figent les contextes qu'elles acceptent et les livrent avec le logiciel.