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 effectue 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’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 passage 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 avoir à faire confiance à l’entité qui a compilé la vue. Les champs pour lesquels aucun droit n’a été revendiqué sont tout simplement absents. Ils ne sont pas masqués, mais n’existent tout simplement pas, et aucune information à leur sujet ne transparaît.
Un exemple concret : l’atelier de réparation
Un exemple concret illustre bien comment cela fonctionne. Un atelier de réparation a déclaré un intérêt légitime pour une batterie, l’un des niveaux d’accès expressément prévus par le règlement sur les batteries. Son système d’atelier se connecte à notre interface à l’aide de sa clé API et récupère le passeport.
La réponse est le même passeport public que celui que voit l’acheteuse, enrichi d’un champ supplémentaire : les instructions de démontage, qui ne sont divulguées qu’aux lecteurs autorisés. Pas de deuxième document, pas de version spéciale, le même passeport avec un champ en plus.
Avant que l’entreprise ne se fie à ce champ, son logiciel vérifie la preuve fournie par rapport à la clé publique de l’émetteur. Si la vérification aboutit, y compris pour le champ supplémentaire, elle sait alors que ces instructions proviennent à la lettre du fabricant et que ni nous, ni aucune autre partie intermédiaire, n’y avons apporté la moindre modification. Si la vérification échoue, il en est tout aussi certain et met de côté l’ensemble du document.
Notre rôle dans ce processus est délibérément limité. Veiller à ce qu’il reçoive exactement les champs auxquels il a droit relève de notre contrôle d’accès ; c’est ce que fait n’importe quel filtre de serveur. Ce qui est nouveau, c’est l’étape suivante : c’est lui-même qui vérifie l’authenticité de ce qu’il reçoit, sans nous consulter.
Pourquoi le fait que le sceau soit « intact » est-il si important ?
Imaginons un notaire qui ne certifie pas la lettre dans son ensemble, mais chaque paragraphe séparément. Tout le monde reçoit la lettre officielle. Ceux qui ont droit à davantage reçoivent les paragraphes supplémentaires, et chacun d’entre eux porte toujours le sceau du même notaire.
Pourquoi le fait qu’ il soit « intact » est-il si important ? Cela mérite une explication supplémentaire. Un sceau intact ne signifie pas que le contenu est vrai. Il indique : c’est exactement ce qu’a écrit l’émetteur, et depuis, personne n’y a modifié le moindre signe. Ainsi, toute personne qui s’est contentée de transmettre le document - le serveur intermédiaire, 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’existe pas de sceau à moitié 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, elles ne sont pas simplement un peu moins validées, elles ne sont pas validées 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 produits : 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 sur 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 sur 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 composants chimiques, 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 cryptographiquement est également quelque chose que nous faisons en plus, et non une case à cocher que la réglementation nous impose.
C’est précisément pour cette raison que cela mérite d’être mentionné. Tout l’intérêt d’un passeport signé réside dans le fait que personne n’a besoin de faire confiance à la plateforme. Supprimer le niveau intermédiaire à titre d’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 supprimer 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 peuvent en être 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 l’ensemble 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 s’appuie 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 preuve 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, au lieu d’apparaître des années plus tard sous la forme d’une violation de validation inexpliquée.
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. C’est l’émetteur lui-même qui génère et supprime cette clé. 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. L’archive inaltérable de dix ans est créée et entre 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’avait jamais été conçu à cet effet.
Où en sommes-nous ?
Nous avons opté pour la preuve, pour chaque lecteur, car un sceau doit avoir la même signification, quelle que soit la personne qui le regarde. Pour ceux qui souhaitent voir comment cela fonctionne : les deux démos dont les liens figurent plus haut s’exécutent directement dans le navigateur, sans interroger de serveur.
Questions concernant cet article
Une norme impose-t-elle la signature champ par champ ?
Non. La norme EN 18239 exige que l’accès soit contrôlé pour chaque élément de données, et un filtre côté serveur répond pleinement à cette exigence. Le fait de rendre vérifiables les champs divulgués au-delà de cette exigence relève de notre décision et ne constitue pas une condition imposée par la réglementation. Nous estimons que cet effort est justifié, car l’intérêt même d’un passeport signé réside dans le fait que personne ne doit avoir à faire confiance à la plateforme ; supprimer l’intermédiaire revient précisément à rétablir cette confiance. Le statut exact de ces normes est précisé dans notre article consacré aux normes harmonisées.
En quoi cela diffère-t-il concrètement d'un filtre côté serveur ?
Ce n’est pas qui voit quoi, mais ce qui arrive. Ces deux méthodes indiquent au lecteur précisément les champs auxquels il a droit. Avec le filtrage côté serveur, l’extrait arrive sans signature ; le lecteur doit donc supposer que le serveur a été choisi de bonne foi et n’a rien modifié en cours de route. Dans le cas des justificatifs champ par champ, ce même extrait est accompagné d’un justificatif qui, hors ligne, permet de remonter jusqu’à la clé publique de l’émetteur, sans que quiconque ait besoin de nous interroger. Pour une fiche d’information publique, la différence est purement théorique ; en revanche, pour la valeur sur laquelle un recycleur fonde le prix d’une batterie usagée, c’est là tout l’enjeu.
Les lecteurs ont-ils besoin d'un logiciel spécifique pour cela ?
Non. Le passe reste une « Verifiable Credential » au format JSON-LD, et la preuve est fournie par la cryptosuite publique du W3C « ecdsa-sd-2023 » ; tout vérificateur conforme à la norme peut donc le valider. Notre application d’affichage open source, Transpareo Time Machine, recalcule chaque signature dans le navigateur de l’utilisateur sans interroger l’un de nos serveurs, et prend délibérément en charge également la signature simple portant sur l’ensemble du document. Un vérificateur qui n’accepterait que notre procédure ne serait utile qu’à nous, et à personne d’autre.
À qui ces champs protégés sont-ils donc divulgués ?
Ce n’est pas l’acheteuse occasionnelle qui obtient le passeport public. Il s’agit de l’atelier de réparation ayant déclaré un intérêt légitime, du préparateur qui évalue la valeur d’un bloc-batterie usagé, du recycleur qui trie les composants chimiques, de l’assureur qui évalue un risque, et de l’autorité qui monte un dossier - des acteurs dont les décisions dépendent de l’argent ou de la sécurité. Le règlement européen sur les batteries prévoit précisément ces étapes. Ce sont également ces acteurs qui, dans l’approche habituelle, ne reçoivent justement aucune preuve concernant les domaines sur lesquels repose leur décision.
Nous ne publions que des données publiques. Est-ce nécessaire ?
Probablement pas, et nous le disons clairement. Une signature couvrant l’ensemble du document, utilisant la suite cryptographique eddsa-jcs-2022, protège un passe dont tous les champs sont publics, et elle est nettement moins coûteuse à mettre en place et à exploiter. La divulgation champ par champ s’avère utile dès qu’un deuxième groupe cible entre en jeu, par exemple un réseau de réparation, un recycleur ou une administration à qui vous remettriez autrement des extraits non signés. Ces deux procédures sont des spécifications ouvertes du W3C, et toutes deux fonctionnent aujourd’hui dans la Time Machine, sur le passeport d’un t-shirt et sur celui d’une batterie.
Est-il possible de faire supprimer ultérieurement les données à caractère personnel sans invalider le passeport ?
Oui, et cet aspect est effectivement exigé par le droit européen. Le Règlement général sur la protection des données confère aux personnes le droit de faire supprimer leurs données à caractère personnel, et un enregistrement signé sous forme de bloc ne peut pas respecter cette exigence sans détruire sa propre signature. Comme chaque champ est ici défini individuellement, il est possible de supprimer un seul champ, tandis que tout le reste reste vérifiable : pas de réémission, pas d’historique des versions fragmenté. Les champs réglementaires que la loi exige de conserver restent en place.
Qui détient la clé de signature ?
Chaque passeport comporte deux justificatifs, dont l’un peut être le vôtre. Chaque émission nécessite en outre une clé à durée de vie limitée qui signe individuellement les champs pouvant être divulgués ; c’est l’émetteur lui-même qui la génère et la détruit, car si elle se trouvait entre nos mains, nous pourrions inventer certains champs a posteriori, et l’indépendance de la signature de l’émetteur ne serait plus qu’une simple affirmation. Nous vérifions le justificatif renvoyé à l’aide de la clé publique enregistrée avant de lui accorder notre confiance. Chaque passeport comporte ainsi deux justificatifs émanant de deux autorités indépendantes, tant pour un champ divulgué individuellement que pour l’ensemble des données.
Un passeport sera-t-il encore valable dans dix ans ?
C’est précisément là que réside la difficulté. La divulgation sélective s’appuie sur le contenu d’un document plutôt que sur ses octets ; ce même format normalisé doit donc être restitué, caractère par caractère, une décennie plus tard. Trois éléments viennent perturber ce fonctionnement, et nous les avons tous les trois résolus à la source : chaque valeur est écrite avec son type et la publication s’interrompt en cas de nombre sans type ; chaque vocabulaire est disponible localement et n’est jamais récupéré via le réseau ; et chaque nœud porte un identifiant stable, afin que la forme normalisée reste reproductible. Les archives immuables sur dix ans sont mises en place et entreront en vigueur dès que les passeports seront enregistrés auprès du registre de l’UE, qui fonctionne depuis le 20 juillet 2026 en vertu du règlement d’exécution (UE) 2026/1778. Pour en savoir plus, consultez notre analyse du règlement relatif au registre.
