Um passaporte digital do produto não mostra o mesmo a todos. Uma compradora vê os dados públicos. Uma oficina de reparação ou uma empresa de recondicionamento vê mais. Uma autoridade de fiscalização do mercado vê tudo. Isso está esclarecido e as normas europeias já o estabelecem expressamente.
A questão interessante é mais subtil: se a alguém forem revelados campos protegidos para além dos dados públicos, poderá essa pessoa comprovar que, precisamente esses campos, são autênticos? Ou terá de confiar que a plataforma os selecionou corretamente e os transmitiu sem alterações?
Na maioria das plataformas, a resposta honesta é: confiança. Construímos a nossa de forma a que a resposta seja «prova» - não só para os campos públicos, mas para cada campo que só é adicionado no momento da divulgação. Por que razão esta diferença é importante e por que razão optámos pelo caminho mais trabalhoso.
Todos cumprem a regra de acesso da mesma forma
A normaEN 18239, a norma europeia relativa aos direitos de acesso, segurança e confidencialidade no DPP, exige o controlo de acesso por elemento de dados: para cada campo existe uma regra que define quem o pode ver. Este é o requisito correto e não é difícil de cumprir. Quanto ao estatuto destas normas, explicámos-o em pormenor em normas harmonizadas.
A forma habitual de o fazer é através da filtragem do lado do servidor. O servidor sabe quem está a fazer a consulta, verifica o que essa pessoa pode ver e devolve exatamente essa parte da informação. Controlo de acesso: resolvido. A norma não exige mais nada.
Há, no entanto, um senão que a norma não aborda: A secção chega sem assinatura. O leitor recebe uma visualização preparada especificamente para si e tem de acreditar que o servidor fez uma seleção honesta e que nada foi alterado durante o trajeto. Para um folheto informativo público, isso é aceitável. Para um valor no qual um reciclador baseia diretamente o preço de uma bateria usada, é pedir muita confiança.
Onde uma assinatura única atinge os seus limites
A solução mais óbvia é assinar os dados. Para os dois extremos da escala, uma assinatura comum funciona bem: assinar a visualização pública, assinar o conjunto de dados completo e ambos são verificados contra uma chave pública, sem que haja um servidor intermédio. O funcionamento detalhado deste processo está descrito em Assinaturas e certificados no DPP.
No meio é que o sistema falha. Uma assinatura sobre todo o documento abrange exatamente um conjunto de campos, nomeadamente aqueles que estavam presentes no momento da assinatura. Se se revelar adicionalmente um campo protegido a um leitor autorizado, esse campo fica fora do conjunto assinado e chega-lhe sem cobertura. Se, em vez disso, se assinar desde o início o conjunto completo de dados, a assinatura abrange tudo, mas então seria necessário mostrar tudo a todos.
Os níveis intermédios ficam, assim, de fora: a oficina de reparação, a seguradora, a empresa de reciclagem. Se se quisesse assinar antecipadamente todas as combinações possíveis de «quem vê o quê», seria necessário um documento assinado específico para cada combinação, e o número de combinações dispararia com cada novo grupo de acesso. Ninguém faz isso. Recorre-se ao filtro do servidor não assinado, e o nível intermédio volta a basear-se na confiança.
Assinar cada campo individualmente
Existe uma estrutura melhor, e é nela que baseamos a plataforma. Em vez de assinar o documento final como um bloco único, o emissor define cada campo individualmente numa única passagem de assinatura (para os especialistas em normas: a especificação do W3C ecdsa-sd-2023 para divulgação seletiva).
Cada visualização começa pelo núcleo público
Cada visualização começa, assim, pelos mesmos campos públicos. O que um leitor vê para além disso é adicionado campo a campo, e cada um desses campos continua a remeter para a chave pública do emitente - offline, sem necessidade de nova assinatura e sem confiança na entidade que compilou a visualização. Os campos sem direito de acesso simplesmente não existem. Não estão ocultos, mas sim ausentes, e nada sobre eles transparece.
Por que razão a «ininterrupção» é o cerne da questão
Imagine um notário que não autentica a carta na sua totalidade, mas sim cada parágrafo individualmente. Todos recebem a carta pública. Quem tiver direito a mais recebe os parágrafos adicionais, e cada um deles continua a ostentar o selo do mesmo notário. No procedimento habitual, a plataforma transcreve esses parágrafos por si, e o que lhe chega já só contém a sua palavra.
Vale a pena dedicar mais uma frase à razão pela qual o facto de estar «intacto» é tão importante. Um selo intacto não significa que o conteúdo seja verdadeiro. Significa: foi exatamente isto que o emitente escreveu e, desde então, ninguém alterou nada no documento. Assim, quem apenas transmitiu o documento fica fora da questão da confiança - o servidor de cache, a rede, o arquivo, nós. Quem lhe entregou o passaporte já não importa.
E um selo é binário. Ou está intacto ou não está; não existe um selo parcialmente quebrado. Se se quebrar, não saberá qual a frase que foi alterada, mas apenas que já não pode confiar na folha na sua totalidade. Por isso, não é uma diferença gradual se os campos adicionais lhe chegam com o selo ou sem ele: sem selo, não estão apenas um pouco menos comprovados, estão completamente sem comprovação.
Ambos os métodos para visualização
Qualquer pessoa pode verificar isso por si própria. A Transpareo Time Machine é a nossa aplicação de visualização de código aberto para passaportes de produto: percorre o histórico de versões de um passaporte e, ao fazê-lo, recalcula cada assinatura no navegador do utilizador, sem consultar nenhum dos nossos servidores. Existem dois passaportes de exemplo disponíveis publicamente. O passaporte de uma t-shirt contém uma assinatura que abrange todo o documento, enquanto o passaporte de uma pilha apresenta a divulgação campo a campo.
Ambas são especificações abertas do W3C: eddsa-jcs-2022 para a assinatura que abrange todo o documento, ecdsa-sd-2023 para a divulgação campo a campo. Qualquer pessoa que queira pode implementá-las. O esforço envolvido é a razão pela qual muitos não o farão: a assinatura que abrange todo o documento é significativamente mais barata de criar e manter, e quem apenas fornece dados públicos consegue dar-se bem com isso.
O facto de a Time Machine dominar ambos os procedimentos é intencional e assim permanecerá. Ela não pertence a nenhuma plataforma. Um verificador que apenas aceitasse o método mais dispendioso seria uma ferramenta para nós e para mais ninguém.
A quem são divulgados os campos protegidos
Vale a pena perguntar a quem, para além dos dados públicos, é que algo é divulgado. Não é à compradora casual, que recebe o certificado público. São o processador, que avalia o valor de um conjunto de baterias usado; a seguradora, que calcula o preço de um risco; o reciclador, que separa os compostos químicos; e a autoridade, que constrói um processo. São estes os destinatários cujas decisões dependem de dinheiro ou segurança.
E são precisamente esses campos que, na abordagem habitual, ficam por cobrir. Quem teria mais motivos para querer uma certificação criptográfica não a recebe, precisamente, para os campos que sustentam a sua decisão.
Consideramos que um selo de certificação deve ter o mesmo significado para todos. «Verificado pela Transpareo» significa, na visualização alargada de uma oficina de reparação, exatamente o mesmo que no certificado público de uma compradora: cada campo apresentado provém do emissor e não foi alterado desde então. Um selo que só se aplica aos campos públicos é um selo incompleto.
Mais do que a norma exige
Dizemos isto abertamente: nada disto é obrigatório. A norma EN 18239 exige que o acesso seja controlado, e um filtro do lado do servidor controla o acesso de forma impecável. Tornar os campos divulgados verificáveis criptograficamente é algo que fazemos por iniciativa própria, não um requisito que a regulamentação nos imponha.
É precisamente por isso que vale a pena deixar isto por escrito. Seria fácil cumprir à letra a norma, fornecer o filtro do servidor e declarar a etapa concluída. Preferimos que o compromisso se aplique em todos os locais onde o selo apareça. Pois todo o sentido de um passe assinado é que ninguém tenha de confiar na plataforma. Excluir a etapa intermédia como exceção retoma precisamente a confiança que a assinatura deveria eliminar.
O mesmo princípio faz com que um campo seja esquecido
Definir cada campo individualmente traz consigo uma segunda característica, e esta é, de facto, exigida pelo direito europeu. O Regulamento Geral sobre a Proteção de Dados confere às pessoas o direito de solicitar a eliminação dos seus dados pessoais. Um conjunto de dados assinado como um bloco não pode cumprir este requisito sem destruir a própria assinatura.
Como aqui cada campo é independente, é possível remover um único campo, enquanto todo o resto continua a ser verificável. Se, por engano, forem incluídos dados pessoais num passaporte, estes são removidos de forma limpa e o passaporte permanece válido: sem necessidade de reemissão, sem histórico danificado. Os campos regulamentares que a lei exige que sejam mantidos permanecem intactos; o que for passível de eliminação pode ser eliminado mediante pedido, mesmo anos mais tarde.
Apesar de tudo, um passaporte perfeitamente normal
Nada disto transforma o passaporte num objeto especial que apenas as nossas ferramentas conseguem abrir. Continua a ser uma Credencial Verificável em JSON-LD, o formato para o qual o mundo dos padrões da Web está a convergir, e o mesmo formato utilizado pelo Protocolo de Transparência da ONU e pelo resto do ecossistema do W3C.
O passaporte que uma compradora digitaliza no navegador é, portanto, o mesmo objeto que um parceiro de uma sala de dados pode ler, e qualquer verificador em conformidade com as normas pode verificá-lo, não apenas os nossos. A segurança adicional não custa nada ao leitor e não vincula ninguém a nós.
Por que razão isto é tecnicamente difícil
Antes de mais, para que não surja uma impressão errada: não fomos nós que inventámos o procedimento. ecdsa-sd-2023 é uma especificação pública do W3C, a criptografia subjacente não é da nossa autoria e quem quiser implementá-la pode consultar a documentação. O difícil não é ter a ideia. O difícil é construí-la de forma a que uma passalha ainda possa ser verificada daqui a dez anos. É aí que reside o trabalho, e sobre isso há algo de útil a dizer.
A diferença pode parecer pequena, mas altera a base: uma assinatura comum faz cálculos com base nos bytes de um documento. A divulgação seletiva faz o cálculo com base nas suas afirmações. Antes da assinatura, o passaporte é transformado num formato padronizado, no qual cada informação aparece como uma frase independente. Só assim é possível omitir uma frase sem comprometer as restantes.
Com isso, surge um problema que uma assinatura por bytes não tem: essa mesma forma padronizada tem de ser reproduzida exatamente da mesma forma daqui a dez anos. Não de forma aproximada, mas caractere a caractere; caso contrário, a prova deixará de ser válida. Três fatores impedem isso, e todos os três são discretos.
Os números perdem o seu tipo. Se se escrever um número como mero JSON, perde-se pelo caminho o tipo de número que era. Um valor como 2,0 volta como 2 após uma passagem pelo JSON. Para um ser humano é a mesma coisa, mas para a forma padronizada é uma frase diferente, e a verificação falha.
As designações ainda não constituem significado. Para que a forma normalizada surja, cada nome de campo tem de corresponder a um significado único. Se faltar um, o campo desaparece silenciosamente durante a conversão. Fica então no passaporte, mas a prova não o abrange, e ninguém se apercebe disso.
Os significados encontram-se normalmente na Internet. Esta correspondência está num vocabulário que a maioria das ferramentas carrega da Internet durante a verificação. Quem o faz torna a verificabilidade do seu passaporte dependente do facto de um endereço externo ainda responder daqui a dez anos, e sem alterações.
Como resolvemos o problema
Resolvemosos três pontos na origem, em vez de os corrigirmos posteriormente.
Tipos. Cada valor é escrito com o seu tipo, e a publicação é interrompida assim que, na forma padronizada, surgir sequer um número sem tipo. Assim, o erro é detetado logo na fase em que custa uma linha, em vez de surgir anos mais tarde como uma violação inexplicável da verificação.
Vocabulários. Cada vocabulário a que um passaporte faz referência está disponível localmente e nunca é obtido através da Internet. Um endereço desconhecido provoca uma interrupção imediata durante a assinatura, em vez de uma recaída silenciosa para um resultado vazio.
Identificadores. Cada nó no documento possui um identificador estável, para que a forma padronizada permaneça reproduzível, em vez de atribuir novos nomes auxiliares a cada execução.
A parte mais delicada reside no «Bring Your Own Key». Para cada emissão, é necessária uma chave adicional de curta duração, com a qual os campos divulgáveis são assinados individualmente. Esta chave é gerada e descartada pelo próprio emissor. Se essa chave estivesse na nossa posse, poderíamos inventar campos individuais a posteriori, e a independência da assinatura do emissor seria apenas uma afirmação. Verificamos o comprovativo recebido em relação à chave pública armazenada, antes de confiarmos nele.
Cada passaporte contém dois comprovativos deste tipo: um do emitente e outro da Transpareo, sendo que cada um deles é derivado de forma independente para a visualização de um leitor. Duas assinaturas, duas autoridades independentes uma da outra, mesmo para um campo divulgado individualmente.
Para nós, este esforço é justificado. Não adicionámos a verificabilidade posteriormente; a plataforma foi concebida em torno disso desde a primeira versão. Cada passaporte é assinado no momento da publicação e encadeado à versão anterior. O arquivo inalterável de dez anos é criado e entra em vigor assim que os passaportes são registados no Registo DPP da UE. Assinar cada campo, em vez de todo o bloco, é uma extensão deste núcleo, não um acréscimo a algo que nunca foi concebido para esse fim.
Onde estamos
Se simplificarmos, a escolha é simples. Pode divulgar campos protegidos e pedir ao leitor que confie no seu filtro - isso cumpre a norma. Ou pode divulgá-los e fornecer a prova em simultâneo - isso cumpre um padrão mais elevado, que, na nossa opinião, estes campos merecem.
Optámos pela prova, para todos os leitores, porque um selo deve significar a mesma coisa, independentemente de quem o veja. Para quem quiser ver como funciona: as duas demonstrações cujos links se encontram acima verificam-se diretamente no navegador, offline, apenas com base numa chave pública.