2026-06-17 · 8 min de lectura · Todos los artículos

Cómo dpp.gs cumple las nuevas normas de DPP de la UE (EN 18216–18223)

Durante dos años, el pasaporte digital de producto solo estuvo definido por la regulación — el ESPR exige un pasaporte, pero no qué forma debe tener a nivel de datos. Esa brecha se cerró en mayo de 2026, cuando el comité CEN/CENELEC JTC 24 publicó las primeras normas DPP: la serie EN 18216–18223. Este artículo asigna dpp.gs a cada una.

La serie EN 18216–18223 de un vistazo

JTC 24 dividió el problema en capas. Cada norma rige un aspecto, y un pasaporte conforme debe responder a todas:

1. Identidad y portadores: GS1 Digital Link (EN 18219 / EN 18220)

Todo empieza por el identificador. dpp.gs nunca inventa un ID propio — usa el GTIN que ya tienes, expresado como GS1 Digital Link. Esa única decisión satisface dos normas a la vez: la capa de identificadores (EN 18219) y la de portadores (EN 18220). El mismo código que escanea un cliente en la tienda lo lee el escáner aduanero en la frontera.

2. Recuperación y búsqueda: una dirección, varios formatos (EN 18216 / EN 18222)

EN 18216 trata de cómo se recupera un pasaporte, y EN 18222 de cómo se encuentran los pasaportes y cómo se consulta su ciclo de vida. dpp.gs responde a ambos desde un solo lugar:

• Recuperar — GET /dpp/v1/passports/{GTIN} devuelve el pasaporte completo como JSON-LD (o JSON).
• Buscar — GET /dpp/v1/passports?sector=textile&operator=… encuentra pasaportes por identificador, operador, código aduanero, sector o estado, con paginación.
• Ciclo de vida — GET /dpp/v1/passports/{GTIN}/lifecycle informa del estado de registro y fechas clave.

3. Un modelo de datos semántico, no un volcado de formulario (EN 18223)

La interoperabilidad falla en cuanto dos sistemas discrepan sobre el significado de un campo. EN 18223 empuja hacia los datos enlazados, y dpp.gs sirve cada pasaporte como JSON-LD: un grafo schema.org Product, ampliado con el vocabulario GS1 y un espacio de nombres dpp:. El @context está estructurado para reapuntar luego a la ontología CIRPASS sin cambiar la forma de los datos.

4. Confianza: Verifiable Credentials firmados (prEN 18246)

El borrador de norma de autenticación plantea una pregunta difícil: ¿cómo sabe un reciclador, un aduanero o un consumidor que un pasaporte es auténtico e inalterado? dpp.gs lo resuelve con criptografía abierta, no con un ledger. Cada pasaporte puede emitirse como W3C Verifiable Credential, firmado con una clave Ed25519 como vc+jwt compacto. Cualquiera obtiene la clave pública del emisor desde /.well-known/jwks.json y verifica la firma sin conexión — sin blockchain.

5. Preparación para el registro (ESPR art. 12–13)

Además de la serie EN, el ESPR exige un registro de DPP de la UE central que registra un pequeño conjunto de identificadores obligatorios por pasaporte. dpp.gs ya captura esos campos para cada producto y los mantiene listos para cuando el registro de la Comisión entre en funcionamiento. Ese día, el registro es un interruptor, no una migración.

Qué significa esto para ti

Al emitir pasaportes en dpp.gs, no apuestas por un formato propietario que las normas podrían contradecir luego. Emites identificadores GS1 Digital Link, datos JSON-LD, portadores QR + DataMatrix y, opcionalmente, credentials firmados — exactamente las piezas hacia las que convergen las normas europeas.

Lectura relacionada: GS1 Digital Link explicado · Estándares abiertos, no blockchain