JSON-LD
JSON-LD es JSON corriente con un campo adicional, @context, que dice qué significan los demás campos. El contexto asigna a cada nombre de campo abreviado un identificador único a escala mundial, normalmente una URL publicada por quien definió el vocabulario, de modo que un sistema que nunca ha visto esos datos puede deducir qué se le está diciendo.
El JSON corriente dice cómo se escriben los datos, no qué significan. Un campo llamado name puede contener una persona, una empresa o un producto, y dos sistemas pueden emitir JSON válido y aun así discrepar sobre todos sus campos. Esa brecha se cierra normalmente con un acuerdo escrito entre las dos partes, que funciona para una integración y deja de funcionar cuando una credencial emitida en un país tiene que ser leída por un verificador de otro con el que nadie habló de antemano.
JSON-LD la cierra dentro del propio documento. El @context asigna a cada nombre de campo abreviado un identificador único a escala mundial, de modo que el campo sigue siendo legible para una persona y se vuelve inequívoco para una máquina. Ninguno de los valores cambia, y quien recibe el documento sin reconocer el vocabulario todavía puede leerlo como JSON corriente e ignorar el resto. JSON-LD 1.0 pasó a ser W3C Recommendation el 16 de enero de 2014, y la versión 1.1 siguió el 16 de julio de 2020.
El W3C Verifiable Credentials Data Model 2.0 está construido sobre él. Cada credencial empieza con un @context cuyo primer valor es el vocabulario compartido de credenciales, de modo que el emisor, el sujeto, las fechas de validez y la información de estado significan lo mismo en todas partes, y cualquier vocabulario adicional aporta los campos que necesita un tipo de credencial concreto.
Firmar un documento de datos enlazados es una elección entre dos mecanismos. Una prueba envolvente como un JWT firma los bytes exactamente como están, así que cualquier cosa que los reordene o los reformatee por el camino rompe la firma. Una prueba Data Integrity incrustada firma en cambio una forma canónica, definida por RDF Dataset Canonicalization, que es lo que permite que la firma sobreviva a que el documento se vuelva a escribir en otro sitio.
No es ninguno de los formatos de credencial de la EUDI Wallet. El Architecture and Reference Framework señala SD-JWT VC y mdoc, y ninguno de los dos usa JSON-LD, así que una organización que emita hacia la cartera europea nunca se encontrará un @context. JSON-LD se gana su sitio allí donde los datos tienen que viajar más allá del ecosistema que los definió: implantaciones de credenciales W3C, pasaportes de producto y datos de la cadena de suministro.
El mismo formato es también la forma en que un sitio web le dice a un motor de búsqueda de qué trata una página, con el @context apuntando a schema.org en lugar de a un vocabulario de credenciales. Las reglas de procesamiento son idénticas en ambos casos, lo que convierte los datos estructurados en el lugar más fácil para ver qué aporta realmente un contexto.
Lea la explicación completa
Esta página ofrece la definición breve. Nuestra explicación muestra lo que significa en la práctica: quién interviene, cómo funciona y qué cambia para su organización.
JSON-LD explicadoTérminos relacionados
¿Es JSON-LD uno de los formatos de credencial de la EUDI Wallet?
No. El Architecture and Reference Framework señala SD-JWT VC y mdoc, y ninguno de los dos es un formato JSON-LD, así que una cartera o un verificador construidos para las reglas europeas no necesitan ningún procesador de JSON-LD.
Eso es una decisión de alcance, no un veredicto sobre el formato. Los dos formatos que señala el marco tienen una forma fija, un único mecanismo de firma y ningún documento que un verificador tenga que ir a buscar antes de poder comprobar nada, que es lo que premian un teléfono y un tiempo de respuesta medido en milisegundos. JSON-LD responde a otra pregunta, la de cómo los datos conservan su significado fuera del ecosistema que los definió, y las organizaciones que trabajan en ambos mundos suelen acabar admitiendo los dos.
¿Cuál es la diferencia entre JSON-LD y el JSON corriente?
Ninguna en cómo se escribe el documento: todo documento JSON-LD es JSON válido, y el software que solo necesita un campo puede tratarlo como tal. La diferencia es el @context, que asigna a cada nombre de campo un identificador definido a escala mundial, de modo que el significado de los datos viaja con el documento en lugar de vivir en una especificación que las dos partes tuvieron que acordar de antemano.
La maquinaria adicional solo importa cuando un documento se expande a su forma completa o se canonicaliza para firmarlo, pasos que un verificador que lee una sola afirmación nunca realiza. El coste real está en otro sitio: el contexto tiene que estar disponible, y un verificador que lo descarga mientras verifica ha metido una llamada de red y un servidor remoto dentro de una decisión de seguridad. Las implementaciones fijan los contextos que aceptan y los distribuyen con el software.