JSON-LD
O JSON-LD é JSON comum com um campo adicional, @context, que diz o que os restantes campos significam. O contexto associa cada nome de campo abreviado a um identificador único a nível mundial, normalmente um URL publicado por quem definiu o vocabulário, pelo que um sistema que nunca viu aqueles dados consegue ainda assim perceber o que lhe está a ser dito.
O JSON comum diz como os dados são escritos, não o que significam. Um campo chamado name pode conter uma pessoa, uma empresa ou um produto, e dois sistemas podem emitir ambos JSON válido e continuar a discordar sobre cada um dos seus campos. Essa lacuna é normalmente fechada por um acordo escrito entre as duas partes, o que funciona para uma integração e deixa de funcionar quando uma credencial emitida num país tem de ser lida por um verificador de outro com quem ninguém falou de antemão.
O JSON-LD fecha-a dentro do próprio documento. O @context associa cada nome de campo abreviado a um identificador único a nível mundial, pelo que o campo se mantém legível para uma pessoa e se torna inequívoco para uma máquina. Nenhum dos valores muda, e quem recebe o documento sem reconhecer o vocabulário continua a poder lê-lo como JSON comum e ignorar o resto. O JSON-LD 1.0 tornou-se W3C Recommendation a 16 de janeiro de 2014, e a versão 1.1 seguiu-se a 16 de julho de 2020.
O W3C Verifiable Credentials Data Model 2.0 assenta nele. Cada credencial abre com um @context cujo primeiro valor é o vocabulário partilhado de credenciais, pelo que o emissor, o sujeito, as datas de validade e a informação de estado significam o mesmo em toda a parte, e qualquer vocabulário adicional fornece os campos de que um tipo específico de credencial precisa.
Assinar um documento de dados ligados é uma escolha entre dois mecanismos. Uma prova envolvente como um JWT assina os bytes exatamente como estão, pelo que tudo o que os reordene ou reformate pelo caminho quebra a assinatura. Uma prova Data Integrity incorporada assina em vez disso uma forma canónica, definida pela RDF Dataset Canonicalization, e é isso que permite que a assinatura sobreviva a ser escrita de novo noutro sítio.
Não é nenhum dos formatos de credencial da EUDI Wallet. O Architecture and Reference Framework indica SD-JWT VC e mdoc, e nenhum deles usa JSON-LD, por isso uma organização que emita para a carteira europeia nunca vai encontrar um @context. O JSON-LD ganha o seu lugar onde os dados têm de viajar para além do ecossistema que os definiu: implementações de credenciais W3C, passaportes de produto e dados da cadeia de abastecimento.
O mesmo formato é também a forma de um sítio web dizer a um motor de busca sobre o que é uma página, com o @context a apontar para schema.org em vez de para um vocabulário de credenciais. As regras de processamento são idênticas nos dois casos, o que faz dos dados estruturados o sítio mais fácil para ver o que um contexto traz realmente.
Ler a explicação completa
Esta página dá a definição breve. A nossa explicação mostra o que significa na prática: quem está envolvido, como funciona e o que muda para a sua organização.
JSON-LD explicadoTermos relacionados
O JSON-LD é um dos formatos de credencial da EUDI Wallet?
Não. O Architecture and Reference Framework indica SD-JWT VC e mdoc, e nenhum deles é um formato JSON-LD, por isso uma carteira ou um verificador construídos para as regras europeias não precisam de nenhum processador de JSON-LD.
Isso é uma decisão de âmbito, não um veredicto sobre o formato. Ambos os formatos indicados pelo quadro têm uma forma fixa, um único mecanismo de assinatura e nenhum documento que um verificador tenha de ir buscar antes de poder verificar o que quer que seja, e é isso que um telemóvel e um tempo de resposta medido em milissegundos premeiam. O JSON-LD responde a outra pergunta, a de como os dados mantêm o seu significado fora do ecossistema que os definiu, e as organizações que trabalham nos dois mundos acabam normalmente por suportar ambos.
Qual é a diferença entre JSON-LD e JSON comum?
Nenhuma na forma como o documento é escrito: todo o documento JSON-LD é JSON válido, e o software que só precisa de um campo pode tratá-lo como tal. A diferença é o @context, que associa cada nome de campo a um identificador definido a nível mundial, pelo que o significado dos dados viaja com o documento em vez de viver numa especificação que as duas partes tiveram de acordar de antemão.
O maquinismo adicional só conta quando um documento é expandido para a sua forma completa ou canonicalizado para ser assinado, passos que um verificador que lê uma única afirmação nunca executa. O custo real está noutro sítio: o contexto tem de estar disponível, e um verificador que o obtém enquanto verifica colocou uma chamada de rede e um servidor remoto dentro de uma decisão de segurança. As implementações fixam os contextos que aceitam e distribuem-nos com o software.