Un passeport numérique du produit ne montre pas la même chose à tout le monde. Une acheteuse voit les données publiques. Un réparateur ou un reconditionneur en voit davantage. Une autorité de surveillance du marché voit tout. Ce point est clair, et les normes européennes le stipulent désormais expressément.
La question intéressante, plus subtile, est la suivante : si des champs protégés, au-delà des données publiques, sont divulgués à quelqu’un, peut-il alors prouver que ces champs-là, précisément, sont authentiques ? Ou doit-il se fier au fait que la plateforme les a correctement sélectionnés et transmis sans les modifier ?
Pour la plupart des plateformes, la réponse honnête est : la confiance. Nous avons conçu la nôtre de telle sorte que la réponse soit « la preuve » - non seulement pour les champs publics, mais aussi pour chaque champ ajouté au moment de la divulgation. Pourquoi cette différence est importante, et pourquoi nous avons choisi cette voie plus complexe.
Tout le monde respecte la même règle d’accès
La normeEN 18239, norme européenne relative aux droits d’accès, à la sécurité et à la confidentialité dans le DPP, exige un contrôle d’accès par élément de données : pour chaque champ, il existe une règle définissant qui est autorisé à le consulter. C’est l’exigence appropriée, et elle n’est pas difficile à respecter. Nous avons détaillé le statut de ces normes dans l’article Normes harmonisées.
La méthode habituelle pour y parvenir est le filtrage côté serveur. Le serveur identifie l’utilisateur qui envoie la requête, vérifie ce que cette personne est autorisée à voir et renvoie exactement cet extrait. Contrôle d’accès : c’est fait. La norme n’exige rien de plus.
Il y a toutefois un hic dont la norme ne tient pas compte : l’extrait arrive sans signature. Le lecteur reçoit une vue personnalisée et doit croire que le serveur a effectué une sélection honnête et n’a rien modifié en cours de route. Pour une fiche d’information publique, cela convient. Mais pour une valeur sur laquelle un recycleur base directement le prix d’une batterie d’occasion, c’est faire preuve d’une grande confiance.
Quand une signature unique atteint ses limites
La solution qui s’impose est de signer les données. Pour les deux extrémités de l’échelle, une signature classique fonctionne bien : signer la vue publique, signer l’ensemble complet des données, et vérifier les deux à l’aide d’une clé publique, sans qu’un serveur ne s’interpose. Le fonctionnement détaillé est décrit dans Signatures et certificats dans le DPP.
C’est au milieu que le système présente une faille. Une signature portant sur l’ensemble du document ne couvre exactement qu’un ensemble de champs, à savoir ceux qui étaient présents au moment de la signature. Si l’on dévoile en plus un champ protégé à un lecteur autorisé, ce champ se trouve en dehors de l’ensemble signé et lui parvient sans être couvert par la signature. Si, au contraire, on signe d’emblée l’ensemble complet des données, la signature couvre certes tout, mais il faudrait alors tout montrer à tout le monde.
Les maillons intermédiaires passent ainsi entre les mailles du filet : l’atelier de réparation, l’assureur, le recycleur. Si l’on voulait signer à l’avance chaque combinaison possible de « qui voit quoi », il faudrait un document signé distinct pour chaque combinaison, et le nombre de combinaisons explose à chaque nouveau groupe d’accès. Personne ne procède ainsi. On revient alors au filtre serveur non signé, et l’étape intermédiaire repose à nouveau sur la confiance.
Signer chaque champ individuellement
Il existe une meilleure approche, et c’est sur celle-ci que nous construisons la plateforme. Au lieu de signer le document final sous forme d’un bloc unique, l’émetteur définit chaque champ individuellement au cours d’un seul cycle de signature (pour les connaisseurs des normes : le certificat W3C ecdsa-sd-2023 pour la divulgation sélective).
Chaque vue commence par le noyau public
Chaque vue commence donc par les mêmes champs publics. Ce qu’un lecteur voit en plus s’ajoute champ par champ, et chacun de ces champs renvoie toujours à la clé publique de l’émetteur - hors ligne, sans nouvelle signature et sans faire confiance à l’entité qui a compilé la vue. Les champs pour lesquels aucun droit n’est revendiqué sont tout simplement absents. Non pas masqués, mais carrément inexistants, et aucune information à leur sujet ne transparaît.
Pourquoi l’« intégrité » est-elle l’essentiel ?
Imaginez un notaire qui ne certifie pas la lettre dans son ensemble, mais chaque paragraphe individuellement. Tout le monde reçoit la lettre publique. Ceux qui ont droit à davantage reçoivent les paragraphes supplémentaires, et chacun d’entre eux porte toujours le sceau du même notaire. Dans la procédure habituelle, la plateforme retranscrit ces paragraphes pour vous, et ce qui vous parvient ne porte plus que sa parole.
Pourquoi le fait qu’il soit « intact » est-il si important ? Cela mérite une explication supplémentaire. Un sceau intact ne garantit pas que le contenu est vrai. Il indique simplement : c’est exactement ce qu’a écrit l’émetteur, et depuis, personne n’y a apporté la moindre modification. Ainsi, toute personne qui s’est contentée de transmettre le document - le serveur de cache, le réseau, les archives, nous - est écartée de la question de confiance. Peu importe qui vous a remis le passeport.
Et un sceau est binaire. Soit il tient, soit il ne tient pas ; il n’y a pas de demi-brisé. S’il se brise, vous ne saurez pas quelle phrase a été modifiée, mais seulement que vous ne pouvez plus faire confiance à l’ensemble du document. C’est pourquoi le fait que les champs supplémentaires vous parviennent avec ou sans leur sceau ne constitue pas une différence graduelle : sans sceau, ils ne sont pas simplement moins bien attestés, ils ne sont pas attestés du tout.
Les deux méthodes à découvrir
Chacun peut le vérifier par lui-même. La Transpareo Time Machine est notre application open source de visualisation des passeports de produit : elle parcourt l’historique des versions d’un passeport et recalcule chaque signature dans le navigateur de l’utilisateur, sans interroger l’un de nos serveurs. Deux exemples de passeports y sont accessibles au public. Le passeport d’un t-shirt comporte une signature couvrant l’ensemble du document, tandis que celui d’une pile présente une divulgation champ par champ.
Il s’agit dans les deux cas de spécifications ouvertes du W3C : eddsa-jcs-2022 pour la signature couvrant l’ensemble du document, ecdsa-sd-2023 pour la divulgation champ par champ. Quiconque le souhaite peut les mettre en œuvre. C’est l’effort que cela demande qui explique pourquoi beaucoup ne le feront pas : la signature couvrant l’ensemble du document est nettement moins coûteuse à mettre en place et à gérer, et ceux qui ne fournissent que des données publiques s’en contentent.
Le fait que Time Machine maîtrise les deux méthodes est intentionnel et le restera. Elle n’appartient à aucune plateforme. Un vérificateur qui n’accepterait que la méthode la plus coûteuse ne serait un outil qu’à notre service, et à celui de personne d’autre.
À qui les champs protégés sont-ils divulgués?
Il est utile de se demander à qui, au-delà des données publiques, des informations sont réellement divulguées. Pas à l’acheteuse occasionnelle, qui reçoit le passeport public. Ce sont le préparateur, qui évalue la valeur d’un bloc-batterie d’occasion, l’assureur, qui évalue un risque, le recycleur, qui trie les composés chimiques, et l’autorité, qui monte un dossier. Ce sont ces lecteurs dont les décisions ont une incidence sur l’argent ou la sécurité.
Et ce sont précisément ces champs qui, dans l’approche habituelle, ne sont pas couverts. Ceux qui auraient le plus de raisons de vouloir une attestation cryptographique ne l’obtiennent justement pas pour les champs qui sous-tendent leur décision.
Nous estimons qu’un label de certification devrait avoir la même signification pour tous. « Vérifié par Transpareo » signifie la même chose sur la vue détaillée d’un atelier de réparation que sur le passeport public d’une acheteuse : chaque domaine affiché provient de l’émetteur et n’a pas été modifié depuis. Un label qui ne s’applique qu’aux champs publics n’est qu’un demi-label.
Au-delà des exigences de la norme
Nous le disons sans détour : rien de tout cela n’est obligatoire. La norme EN 18239 exige que l’accès soit contrôlé, et un filtre côté serveur assure parfaitement ce contrôle. Rendre les champs exposés vérifiables par cryptographie est également quelque chose que nous faisons en plus, et non une simple case à cocher exigée par la réglementation.
C’est précisément pour cette raison que cela mérite d’être précisé. Il serait facile de se conformer à la lettre de la norme, de fournir le filtre côté serveur et de déclarer cette étape terminée. Nous préférons que cet engagement s’applique partout où le label apparaît. Car tout l’intérêt d’un passeport signé réside dans le fait que personne n’ait à faire confiance à la plateforme. Exclure le niveau intermédiaire en tant qu’exception rétablit précisément la confiance que la signature était censée éliminer.
Ce même principe permet d’oublier un champ
Se prononcer sur chaque champ individuellement implique une deuxième caractéristique, et celle-ci est en effet exigée par le droit européen. Le Règlement général sur la protection des données donne aux personnes le droit de faire effacer leurs données à caractère personnel. Un ensemble de données signé en bloc ne peut pas se conformer à cette exigence sans détruire sa propre signature.
Comme chaque champ est indépendant, il est possible de supprimer un champ isolé, tandis que tout le reste reste vérifiable. Si des données à caractère personnel se retrouvent par inadvertance dans un passeport, elles en sont retirées proprement et le passeport reste valide : pas de réémission, pas d’historique brisé. Les champs réglementaires que la loi impose de conserver restent en place ; ce qui peut être supprimé peut l’être sur demande, même des années plus tard.
Un passeport tout à fait ordinaire malgré tout
Rien de tout cela ne fait du passeport un objet particulier que seuls nos outils peuvent ouvrir. Il reste un « Verifiable Credential » au format JSON-LD, le format vers lequel converge le monde des standards du Web, et le même format utilisé par le Protocole de transparence des Nations Unies et le reste de l’écosystème du W3C.
Le passeport qu’une acheteuse scanne dans son navigateur est donc le même objet qu’un partenaire de la salle de données peut lire, et tout vérificateur conforme aux normes peut le vérifier, pas seulement le nôtre. Cette sécurité supplémentaire ne coûte rien au lecteur et ne lie personne à nous.
Pourquoi c’est techniquement difficile
Tout d’abord, pour éviter toute impression erronée : nous n’avons pas inventé ce procédé. ecdsa-sd-2023 est une spécification publique du W3C, la cryptographie qui la sous-tend ne vient pas de nous, et quiconque souhaite la mettre en œuvre peut se renseigner à ce sujet. Ce n’est pas difficile d’avoir l’idée. Ce qui est difficile, c’est de la concevoir de telle sorte qu’un passeport puisse encore être validé dans dix ans. C’est là que réside tout le travail, et on peut en tirer des conclusions utiles.
La différence peut sembler minime, mais elle change la donne : une signature classique effectue ses calculs sur les octets d’un document. La divulgation sélective effectue ses calculs sur ses déclarations. Avant la signature, le passeport est mis sous une forme normalisée, dans laquelle chaque information est présentée comme une phrase distincte et autonome. Ce n’est qu’ainsi qu’il est possible d’omettre une phrase sans altérer les autres.
On hérite ainsi d’un problème que ne pose pas une signature par octet : cette même forme normalisée doit réapparaître exactement telle quelle dans dix ans. Pas approximativement, mais caractère par caractère, sinon la preuve ne sera plus valable. Trois éléments font obstacle à cela, et tous trois sont insignifiants.
Les nombres perdent leur type. Si l’on écrit un nombre sous forme de simple JSON, on perd en cours de route la nature de ce nombre. Une valeur telle que 2,0 revient sous la forme 2 après un passage par JSON. Pour un humain, c’est la même chose ; pour la forme normalisée, c’est une phrase différente, et la vérification échoue.
Les désignations ne constituent pas encore une signification. Pour que la forme normalisée puisse voir le jour, chaque nom de champ doit correspondre à une signification unique. S’il en manque une, le champ disparaît tacitement lors de la conversion. Il figure alors dans le passeport, mais la justification ne le couvre pas, et personne ne s’en rend compte.
Les significations se trouvent généralement sur Internet. Cette correspondance figure dans un vocabulaire que la plupart des outils chargent depuis le Web lors de la validation. Ceux qui procèdent ainsi font dépendre la validabilité de leur passeport du fait qu’une adresse tierce réponde encore dans dix ans, et ce sans avoir changé.
Comment nous avons résolu le problème
Nous avons réglé ces trois points à la source, au lieu de les corriger a posteriori.
Types. Chaque valeur est écrite avec son type, et la publication est interrompue dès qu’un seul nombre sans type apparaît dans la forme normalisée. L’erreur est ainsi détectée là où elle ne coûte qu’une ligne de code, au lieu de se manifester des années plus tard sous la forme d’une violation inexplicable de la validation.
Vocabulaires. Chaque vocabulaire auquel un passeport fait référence est disponible localement chez nous et n’est jamais récupéré via le réseau. Une adresse inconnue entraîne un arrêt brutal de la signature, et non un retour silencieux à un résultat vide.
Identifiants. Chaque nœud du document porte un identifiant stable, afin que la forme normalisée reste reproductible, au lieu d’attribuer de nouveaux noms auxiliaires à chaque passage.
La partie la plus délicate réside dans le principe « Bring Your Own Key » (Apportez votre propre clé). Pour chaque émission, une clé supplémentaire à durée de vie limitée est nécessaire, avec laquelle les champs pouvant être divulgués sont signés individuellement. Cette clé est générée puis supprimée par l’émetteur lui-même. Si elle se trouvait en notre possession, nous pourrions inventer a posteriori certains champs, et l’indépendance de la signature de l’émetteur ne serait plus qu’une simple affirmation. Nous vérifions la preuve renvoyée à l’aide de la clé publique enregistrée avant de lui accorder notre confiance.
Chaque passeport comporte deux justificatifs de ce type, l’un provenant de l’émetteur et l’autre de Transpareo, et chacun d’entre eux est dérivé de manière indépendante pour être consulté par un lecteur. Deux signatures, deux autorités indépendantes l’une de l’autre, même pour un champ divulgué individuellement.
Pour nous, cet effort est justifié. Nous n’avons pas ajouté la vérifiabilité a posteriori ; la plateforme a été conçue autour de ce principe dès sa première version. Chaque passeport est signé lors de sa publication et chaîné à la version précédente. Les archives inaltérables sur dix ans sont créées et entrent en vigueur dès que les passeports sont enregistrés auprès du registre DPP de l’UE. Signer chaque champ plutôt que l’ensemble du bloc constitue une extension de ce noyau, et non un ajout à quelque chose qui n’a jamais été conçu à cet effet.
Où en sommes-nous ?
En résumé, le choix est simple. Vous pouvez divulguer les champs protégés et demander au lecteur de faire confiance à votre filtre - cela répond à la norme. Ou vous pouvez les divulguer tout en fournissant immédiatement la preuve - cela répond à une exigence plus élevée, que ces champs méritent selon nous.
Nous avons opté pour la preuve, pour chaque lecteur, car un label doit avoir la même signification, quelle que soit la personne qui le consulte. Pour ceux qui souhaitent voir comment cela fonctionne : les deux démos dont les liens figurent ci-dessus s’autovérifient directement dans le navigateur, hors ligne, en s’appuyant uniquement sur une clé publique.