Un pasaporte digital del producto no muestra lo mismo a todo el mundo. Una compradora ve los datos públicos. Un taller de reparación o una empresa de reacondicionamiento ve más. Una autoridad de vigilancia del mercado lo ve todo. Esto está claro, y las normas europeas ya lo establecen expresamente.
La pregunta interesante es más sutil: si a alguien se le revelan campos protegidos más allá de los datos públicos, ¿puede demostrar que precisamente esos campos son auténticos? ¿O debe confiar en que la plataforma los ha seleccionado correctamente y los ha transmitido sin modificaciones?
En la mayoría de las plataformas, la respuesta sincera es: confianza. Nosotros hemos diseñado la nuestra de tal forma que la respuesta sea «prueba», no solo para los campos públicos, sino para cada campo que se añada en el momento de la divulgación. Por qué esta diferencia es importante y por qué hemos optado por el camino más laborioso.
Todos cumplen la norma de acceso de la misma manera
Lanorma EN 18239, la norma europea sobre derechos de acceso, seguridad y confidencialidad en el DPP, exige un control de acceso por elemento de datos: para cada campo hay una regla que establece quién puede verlo. Ese es el requisito adecuado y no es difícil de cumplir. En normas armonizadas hemos desglosado qué estatus tienen realmente estas normas.
La forma habitual de lograrlo es mediante el filtrado en el servidor. El servidor sabe quién realiza la consulta, comprueba qué puede ver esa persona y devuelve exactamente ese fragmento. Control de acceso: resuelto. La norma no exige nada más.
Sin embargo, hay un inconveniente del que la norma no se ocupa: el fragmento llega sin firmar. El lector recibe una vista preparada a su medida y debe confiar en que el servidor ha seleccionado el contenido de forma honesta y no ha modificado nada durante la transmisión. Para una ficha informativa pública, esto está bien. Pero para un valor en el que un reciclador basa directamente el precio de una batería usada, se trata de una gran muestra de confianza.
Donde una sola firma llega a sus límites
La solución más obvia es firmar los datos. Para los dos extremos de la escala, una firma convencional funciona bien: firmar la vista pública, firmar el conjunto de datos completo y verificar ambos con una clave pública, sin que intervenga ningún servidor. El funcionamiento detallado se explica en Firmas y certificados en el DPP.
El problema surge en el punto intermedio. Una firma sobre todo el documento cubre exactamente un conjunto de campos, concretamente los que estaban presentes en el momento de la firma. Si se revela además un campo protegido a un lector autorizado, dicho campo queda fuera del conjunto firmado y le llega sin estar cubierto. Si, en cambio, se firma desde el principio el conjunto completo de datos, la firma cubre todo, pero entonces habría que mostrárselo todo a todo el mundo.
Los niveles intermedios quedan así fuera del sistema: el taller de reparación, la aseguradora, la empresa de reciclaje. Si se quisiera firmar de antemano cada posible combinación de «quién ve qué», se necesitaría un documento firmado específico para cada combinación, y el número de combinaciones se dispara con cada nuevo grupo de acceso. Nadie hace eso. Se recurre al filtro de servidor sin firmar, y el nivel intermedio vuelve a basarse en la confianza.
Firmar cada campo por separado
Existe un diseño mejor, y sobre él construimos la plataforma. En lugar de firmar el documento final como un bloque único, el emisor especifica cada campo por separado en una única pasada de firma (para los expertos en normas: el certificado del W3C ecdsa-sd-2023 para la divulgación selectiva).
Cada vista comienza por el núcleo público
Cada vista comienza, por tanto, con los mismos campos públicos. Lo que el lector ve además se añade campo a campo, y cada uno de estos campos sigue remitiendo a la clave pública del emisor - sin conexión, sin necesidad de volver a firmar y sin confiar en la entidad que ha compilado la vista - . Los campos sobre los que no se tiene derecho simplemente no aparecen. No están tachados, sino que no están ahí en absoluto, y no se filtra nada sobre ellos.
Por qué «sin interrupciones» es la clave
Imaginemos a un notario que no certifica la carta en su totalidad, sino cada párrafo por separado. Todo el mundo recibe la carta pública. Quien tenga derecho a más, recibirá los párrafos adicionales, y cada uno de ellos seguirá llevando el sello del mismo notario. En el procedimiento habitual, la plataforma transcribe estos párrafos por ti, y lo que te llega solo lleva tu palabra.
Merece la pena dedicar una frase más a explicar por qué es tan importante que el sello esté «intacto». Un sello intacto no garantiza que el contenido sea cierto. Lo que dice es: esto es exactamente lo que escribió el emisor y, desde entonces, nadie ha alterado ni un solo carácter. De este modo, queda fuera de la cuestión de la confianza cualquiera que simplemente haya transmitido el documento: el servidor de caché, la red, el archivo, nosotros. Ya no importa quién te haya entregado el pasaporte.
Y un sello es binario. O se mantiene intacto o no; no existe un sello medio roto. Si se rompe, no sabrás qué frase se ha modificado, sino solo que ya no puedes confiar en toda la hoja. Por eso no es una diferencia gradual si los campos adicionales te llegan con su sello o sin él: sin sello, no están «ligeramente menos validados», sino que no están validados en absoluto.
Ambos métodos para consultarlos
Cualquiera puede comprobarlo por sí mismo. La Transpareo Time Machine es nuestra aplicación de visualización de código abierto para pasaportes de productos: recorre el historial de versiones de un pasaporte y, al hacerlo, verifica cada firma en el navegador del usuario sin consultar a ninguno de nuestros servidores. En ella se pueden consultar públicamente dos pases de ejemplo. El pase de una camiseta lleva una firma que abarca todo el documento, mientras que el de una batería presenta la información campo por campo.
Ambas son especificaciones abiertas del W3C: eddsa-jcs-2022 para la firma que abarca todo el documento, ecdsa-sd-2023 para la divulgación campo por campo. Cualquiera que lo desee puede implementarlas. El esfuerzo que supone es la razón por la que muchos no lo harán: la firma que abarca todo el documento es mucho más barata de crear y mantener, y a quien solo facilite datos públicos le basta con eso.
El hecho de que Time Machine domine ambos procedimientos es intencionado y seguirá siendo así. No pertenece a ninguna plataforma. Un verificador que solo aceptara el método más caro sería una herramienta para nosotros y para nadie más.
A quién se le revelan los campos protegidos
Merece la pena preguntarse a quién se le revela realmente algo más allá de los datos públicos. No a la compradora ocasional, que recibe el certificado público. Son el preparador, que evalúa el valor de un paquete de baterías usado; la aseguradora, que calcula el precio de un riesgo; el reciclador, que clasifica los compuestos químicos; y la autoridad, que instruye un expediente. Estos son los destinatarios cuyas decisiones dependen del dinero o de la seguridad.
Y son precisamente esos campos los que, en el enfoque habitual, quedan al descubierto. Quien más motivos tendría para querer una certificación criptográfica, no la obtiene, precisamente, para los campos que sustentan su decisión.
Creemos que un sello de certificación debería significar lo mismo para todos. «Verificado por Transpareo» significa lo mismo en la vista ampliada de un taller de reparación que en el certificado público de una compradora: cada campo mostrado procede del emisor y no ha sido alterado desde entonces. Un sello que solo se aplica a los campos públicos es un sello a medias.
Más de lo que exige la norma
Lo decimos abiertamente: nada de esto es obligatorio. La norma EN 18239 exige que se controle el acceso, y un filtro del lado del servidor lo controla a la perfección. Hacer que los campos revelados sean verificables criptográficamente es algo que hacemos por nuestra cuenta, no un requisito que nos imponga la normativa.
Precisamente por eso merece la pena dejarlo por escrito. Sería fácil cumplir al pie de la letra la norma, entregar el filtro del servidor y dar por concluido este nivel. Preferimos que el compromiso se aplique en todos los lugares donde aparezca el sello. Porque el sentido de un pase firmado es precisamente que nadie tenga que confiar en la plataforma. Excluir el nivel intermedio como excepción supone recuperar precisamente esa confianza que la firma debía eliminar.
El mismo principio hace que se pase por alto un campo
Definir cada campo por separado conlleva una segunda característica, y esta es, de hecho, una exigencia de la legislación europea. El Reglamento General de Protección de Datos otorga a las personas el derecho a que se eliminen sus datos personales. Un conjunto de datos firmado como un bloque no puede cumplir este requisito sin destruir su propia firma.
Dado que aquí cada campo es independiente, se puede eliminar un solo campo, mientras que el resto sigue siendo verificable. Si, por error, se incluyen datos personales en un pasaporte, estos se eliminan por completo y el pasaporte sigue siendo válido: no hay que volver a expedirlo ni se interrumpe su historial. Los campos reglamentarios que la ley exige conservar permanecen intactos; lo que se puede eliminar se puede borrar previa solicitud, incluso años después.
A pesar de todo, un pasaporte totalmente normal
Nada de esto convierte al pasaporte en un objeto especial que solo nuestras herramientas puedan abrir. Sigue siendo una credencial verificable en JSON-LD, el formato hacia el que converge el mundo de los estándares web, y el mismo formato que utilizan el Protocolo de Transparencia de la ONU y el resto del entorno del W3C.
El carné que una compradora escanea en el navegador es, por tanto, el mismo objeto que puede leer un socio de la sala de datos, y cualquier verificador que cumpla con las normas puede comprobarlo, no solo los nuestros. La seguridad adicional no le cuesta nada al lector y no vincula a nadie con nosotros.
Por qué es técnicamente complicado
Antes de nada, para que no se cree una impresión errónea: nosotros no hemos inventado el procedimiento. ecdsa-sd-2023 es una especificación pública del W3C; la criptografía que hay detrás no es nuestra, y quien quiera implementarla puede consultar la documentación. Lo difícil no es tener la idea. Lo difícil es diseñarla de tal forma que una contraseña siga siendo válida dentro de diez años. Ahí es donde reside el trabajo, y sobre eso se puede decir algo útil.
La diferencia parece pequeña, pero cambia los fundamentos: una firma habitual realiza cálculos sobre los bytes de un documento. La divulgación selectiva realiza el cálculo a partir de sus afirmaciones. Antes de firmar, el pasaporte se adapta a un formato normalizado, en el que cada dato aparece como una frase independiente. Solo así es posible omitir una frase sin que ello afecte al resto.
Esto conlleva un problema que una firma de bytes no tiene: esa misma forma normalizada debe reproducirse exactamente igual dentro de diez años. No de forma aproximada, sino carácter por carácter; de lo contrario, la prueba ya no será válida. Hay tres cosas que lo impiden, y las tres son insignificantes.
Los números pierden su tipo. Si se escribe un número como simple JSON, por el camino se pierde qué tipo de número era. Un valor como 2,0 vuelve como 2 tras pasar por JSON. Para una persona es lo mismo, pero para la forma normalizada es otra frase, y la verificación falla.
Las denominaciones no son sinónimo de significado. Para que se genere la forma normalizada, cada nombre de campo debe resolverse en un significado único. Si falta uno, el campo desaparece silenciosamente durante la conversión. Entonces aparece en el carné, pero la justificación no lo cubre, y nadie se da cuenta.
Los significados suelen encontrarse en la red. Esta asignación figura en un vocabulario que la mayoría de las herramientas descargan de la red durante la comprobación. Quien lo haga, hace que la verificabilidad de su pasaporte dependa de que una dirección ajena siga respondiendo dentro de diez años, y además sin cambios.
Cómo lo hemos resuelto
Hemos resuelto los tres puntos desde la raíz, en lugar de detectarlos más tarde.
Tipos. Cada valor se escribe con su tipo, y la publicación se interrumpe en cuanto aparece, aunque sea uno solo, un número sin tipo en la forma normalizada. De este modo, el error se detecta allí donde supone una línea de código, en lugar de años más tarde como una inexplicable violación de la validación.
Vocabularios. Cada vocabulario al que hace referencia un pase está disponible localmente en nuestro sistema y nunca se recupera a través de la red. Una dirección desconocida provoca una interrupción brusca durante la firma, no una recaída silenciosa en un resultado vacío.
Identificadores. Cada nodo del documento lleva un identificador estable, para que la forma normalizada siga siendo reproducible, en lugar de asignar nuevos nombres auxiliares en cada pasada.
La parte más delicada reside en «Bring Your Own Key» (Trae tu propia clave). Para cada emisión se necesita una clave adicional de corta duración, con la que se firman individualmente los campos que pueden divulgarse. El propio emisor genera y desecha esta clave. Si estuviera en nuestro poder, podríamos inventarnos campos concretos a posteriori, y la independencia de la firma del emisor quedaría reducida a una mera afirmación. Comprobamos la prueba que nos llega cotejándola con la clave pública almacenada antes de darla por válida.
Cada pasaporte contiene dos de estos certificados: uno del emisor y otro de Transpareo, y cada uno de ellos se deriva de forma independiente para que un lector pueda consultarlo. Dos firmas, dos autoridades independientes entre sí, incluso para un campo divulgado de forma individual.
Para nosotros, este esfuerzo está bien invertido. No hemos añadido la verificabilidad a posteriori; la plataforma se ha desarrollado en torno a ella desde la primera versión. Cada pasaporte se firma al publicarse y se encadena a la versión anterior. El archivo inalterable de diez años se crea y entra en vigor tan pronto como los pasaportes se registran en el Registro DPP de la UE. Firmar cada campo en lugar de todo el bloque es una ampliación de este núcleo, no un añadido a algo que nunca se concibió para ello.
En qué punto nos encontramos
En esencia, la elección es sencilla. Puede revelar los campos protegidos y pedir al lector que confíe en su filtro; eso cumple la norma. O bien puede revelarlos y proporcionar la prueba al mismo tiempo; eso cumple un requisito más exigente que, en nuestra opinión, estos campos merecen.
Nos hemos decantado por la prueba, por el bien de todos los lectores, porque un sello debería significar lo mismo para cualquiera que lo vea. Para quienes quieran ver cómo funciona: las dos demostraciones enlazadas más arriba se verifican directamente en el navegador, sin conexión, utilizando únicamente una clave pública.