2026-06-17 · 8 min de leitura · Todos os artigos

Como dpp.gs se alinha com as novas normas DPP da UE (EN 18216, 18219–18223, 18239, 18246)

Durante dois anos, o Passaporte Digital de Produto foi definido apenas pela regulamentação — o ESPR dizia que um passaporte tem de existir, mas não que forma deveria ter na transmissão. Essa lacuna fechou-se em maio de 2026, quando o comité técnico JTC 24 do CEN/CENELEC publicou as primeiras normas europeias de DPP: a série EN 18216, 18219–18223, 18239, 18246. Este artigo mapeia dpp.gs para cada uma, de forma clara, para que possa ver exatamente onde a plataforma está em conformidade hoje.

A série EN 18216, 18219–18223, 18239, 18246 num relance

O JTC 24 dividiu o problema em camadas. Cada norma rege uma preocupação, e um passaporte conforme tem de responder a todas:

1. Identidade e portadores: GS1 Digital Link (EN 18219 / EN 18220)

Tudo começa com o identificador. dpp.gs nunca inventa um ID de produto proprietário — usa o GTIN que já possui, expresso como um GS1 Digital Link. Essa única decisão satisfaz duas normas de uma só vez: a camada de identificador (EN 18219) e a camada de portador de dados (EN 18220), porque um Digital Link foi concebido para residir tanto dentro de um código QR de consumo como de um GS1 DataMatrix. O mesmo código que um comprador lê numa loja é o código que um scanner alfandegário lê na fronteira. Não há um segundo sistema de identidade para reconciliar.

2. Obtenção e pesquisa: um URL, muitos formatos (EN 18216 / EN 18222)

A EN 18216 trata de como um passaporte é obtido, e a EN 18222 de como os passaportes são encontrados e de como o seu ciclo de vida é consultado. dpp.gs responde a ambas a partir do mesmo sítio:

• Obter — GET /dpp/v1/passports/{GTIN} devolve o passaporte completo como JSON-LD (ou JSON simples). O URL público do visualizador faz o mesmo via negociação de conteúdo: peça application/ld+json e obtém dados, não uma página web.
• Pesquisar — GET /dpp/v1/passports?sector=textile&operator=… permite a qualquer sistema autorizado descobrir passaportes por identificador de produto, operador económico, código de mercadoria (HS), setor ou estado de registo, com paginação.
• Ciclo de vida — GET /dpp/v1/passports/{GTIN}/lifecycle reporta o estado de registo e as datas-chave, para que um sistema a jusante saiba se um passaporte está ativo, pendente ou retirado.

As operações de escrita (criar, atualizar, retirar) permanecem atrás de APIs autenticadas por tenant — a superfície pública é apenas de leitura e pesquisa, que é exatamente a assimetria que as normas pressupõem.

3. Um modelo de dados semântico, não um despejo de formulário (EN 18223)

A interoperabilidade falha no momento em que dois sistemas discordam sobre o que um campo significa. A EN 18223 aponta para os dados ligados, e dpp.gs serve cada passaporte como JSON-LD: um grafo Product de schema.org, estendido com o vocabulário GS1 e um espaço de nomes dpp: para aspetos específicos do passaporte (materiais, substâncias preocupantes, dados do setor). O @context está estruturado de modo a poder ser posteriormente reapontado para a ontologia intersetorial CIRPASS sem alterar a forma dos dados. Materiais, substâncias e conteúdo reciclado são modelados como blocos de construção partilhados, reutilizados por cada uma das 14 categorias de produtos — para que a ferramenta de um reciclador leia "cobalto, 12%, SVHC: não" da mesma forma, quer o produto seja uma bateria ou um brinquedo.

4. Confiança: Credenciais Verificáveis assinadas (prEN 18246)

O projeto de norma de autenticação coloca uma questão difícil: como sabe um reciclador, um funcionário aduaneiro ou um consumidor que um passaporte é genuíno e não foi alterado? dpp.gs responde-lhe com criptografia aberta em vez de um livro-razão. Qualquer passaporte pode ser emitido como uma Credencial Verificável da W3C, assinada com uma chave Ed25519 como um vc+jwt compacto (a representação VC-JOSE-COSE). Qualquer pessoa pode obter a chave pública do emissor em /.well-known/jwks.json e verificar a assinatura offline — provando tanto quem emitiu o passaporte como que nem um byte foi alterado. Sem blockchain, sem intermediário central de confiança, sem dependência de fornecedor. (Veja porque escolhemos normas abertas em vez de blockchain.)

5. Prontidão para o registo (ESPR Art. 12–13)

A par da série EN, o ESPR exige um Registo DPP da UE central que regista um pequeno conjunto de identificadores obrigatórios para cada passaporte. dpp.gs já captura esses campos para cada produto e mantém-nos prontos a enviar assim que o endpoint do registo da Comissão entrar em funcionamento. Quando esse dia chegar, o registo é um interruptor de configuração, não uma migração.

O que isto significa para si

Se emite passaportes em dpp.gs, não está a apostar num formato proprietário que as normas possam mais tarde contradizer. Está a emitir identificadores GS1 Digital Link, dados JSON-LD, portadores QR + DataMatrix e, opcionalmente, credenciais assinadas — os ingredientes exatos para os quais as normas europeias estão a convergir. À medida que a série EN e o Registo da UE se consolidam, os seus passaportes acompanham-nos, em vez de precisarem de ser reemitidos.

Leitura relacionada: GS1 Digital Link explicado · Normas abertas, não blockchain · Quem vê o quê num passaporte