FR 3155935 A1 20250530 FR 2313049 A 20231124 La présente invention concerne un procédé pour la mise en œuvre d’une transaction avec un serveur marchand (2) impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (21) dudit serveur marchand (2), d’étapes de : Réception depuis un terminal (1) de l’individu d’un premier ensemble d’identifiants vérifiables (VP1) dont au moins un identifiant vérifiable unique pour la mise en œuvre de la transaction, dit identifiant vérifiable principal, et un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client (1) ; Vérification de : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmission, à un serveur de validation (3) de la transaction, d’un deuxième ensemble d’identifiants vérifiables (VP2) dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand [Fig. 1] Procédé pour la mise en œuvre d’une transaction avec un serveur marchand impliquant la vérification d’un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine des transactions dématérialisées. Plus précisément, elle concerne un procédé pour la mise en œuvre d’une transaction avec un serveur marchand impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction. ETAT DE L’ART On connait aujourd’hui des solutions de paiement « one click » : un individu, ayant dématérialisé ses informations de paiement sur son terminal mobile, n’a qu’à s’authentifier par exemple en présentant un trait biométrique (son visage, une empreinte digitale, etc.) pour initier la transaction. Le problème est que de nombreuses transactions exigent aujourd’hui la vérification par le marchand d’attributs de l’identité de l’individu à l’origine de la transaction. Par exemple, certains produits ne peuvent être achetés que par des majeurs (alcool ou cigarettes par exemple), et la transaction implique la vérification que l’individu est majeur. Similairement, si la transaction est la location d’un véhicule, elle implique la vérification que l’individu a bien le permis. Un autre cas d’usage serait l’utilisation d’un distributeur automatique réservé aux hôtes d’une résidence ou d’un hôtel. Naturellement, l’utilisateur peut déclarer sur l’honneur qu’il satisfait la condition (en cochant par exemple une case « j’ai plus de 18 ans »), mais un niveau de preuve supérieur est souhaitable. Pour cela, l’utilisateur peut directement fournir un document d’identité, par exemple carte d’identité/passeport pour la preuve de majorité, ou directement le permis pour la location de voiture, en tant que preuve, par exemple une version scannée, le cas échéant signée par une entité de confiance. Cela pose toutefois deux problèmes : Un document d’identité contient de nombreuses données personnelles (nom, adresse, photo, etc.), qui vont au-delà de ce qui demandé pour la mise en œuvre de la transaction, de sorte qu’on expose inutilement la vie privée de l’individu (problème de privacy) ; On ne peut plus faire un paiement « one-click », car on ne peut pas juste envoyer le document d’identité avec les informations de paiement, dans la mesure où ce n’est pas le serveur bancaire qui vérifie les attributs de l’identité de l’individu mais le marchand (c’est de sa responsabilité de ne pas autoriser la transaction le cas échéant). La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé pour la mise en œuvre d’une transaction avec un serveur marchand impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données dudit serveur marchand, d’étapes de : Réception depuis un terminal de l’individu d’un premier ensemble d’identifiants vérifiables dont au moins un identifiant vérifiable unique pour la mise en œuvre de la transaction, dit identifiant vérifiable principal, un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client; Vérification de : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmission à un serveur de validation d’un deuxième ensemble d’identifiants vérifiables dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Selon des caractéristiques avantageuses et non limitatives : Le procédé comprend une étape préalable (a0) de transmission au terminal d’une requête d’informations pour la mise en œuvre de ladite transaction, exprimant ledit critère à vérifier. Lesdits identifiants vérifiables principal et secondaire sont choisis dans une liste d’identifiants vérifiables dudit utilisateur émis par une autorité et stockés par des moyens de stockage de données du terminal. Le procédé comprend une étape (a1) de sélection par l’individu sur son terminal desdits identifiants vérifiables principal et secondaire dans ladite liste d’identifiants vérifiables dudit utilisateur ; et de signature par les moyens de traitement de données du terminal dudit premier ensemble d’identifiants vérifiables. L’étape (a1) comprend en outre l’authentification de l’individu sur le terminal. Ladite transaction est de type paiement, et ledit identifiant vérifiable principal représente un identifiant unique d’un moyen de paiement de l’individu. Ledit deuxième ensemble d’identifiants vérifiables ne comprend aucun identifiant vérifiable secondaire du premier ensemble d’identifiants vérifiables. Ledit attribut est choisi dans la liste suivante : date de naissance/âge, adresse, taille, nationalité, situation familiale, diplôme, statut professionnel, employeur actuel, assurance maladie, handicap, permis de conduire, date d’obtention du permis de conduire, identifiant de carte de fidélité, points de fidélité, droits d’accès. Le deuxième ensemble d’identifiants vérifiables est signé par le serveur marchand à l’étape (d), le procédé comprenant une étape (e), mise en œuvre par des moyens de traitement de données d’un serveur de validation de ladite transaction, de vérification de : ladite signature du deuxième ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du deuxième ensemble d’identifiants vérifiables ; Le procédé comprend une étape (f) de réception, depuis un serveur de validation de la transaction, d’un troisième ensemble d’identifiants vérifiables dont au moins un identifiant vérifiable relatif à la confirmation de la transaction. Le premier ensemble d’identifiants vérifiables contient des informations descriptives de ladite transaction signées par le serveur marchand et contresignées par le terminal, ces informations descriptives de ladite transaction étant incluses dans le deuxième ensemble d’identifiants vérifiables, puis contresignées par le serveur de validation et incluses dans le troisième ensemble d’identifiants vérifiables. Selon un deuxième aspect, l’invention concerne un serveur marchand, caractérisé en ce qu’il comprend des moyens de traitement de données configurés pour : Recevoir, depuis un terminal d’un individu à l’origine d’une transaction avec ledit serveur marchand impliquant la vérification d’au moins un critère portant sur un attribut de l’identité dudit individu, un premier ensemble d’identifiants vérifiables dont au moins un identifiant vérifiable unique pour la mise en œuvre de ladite transaction, dit identifiant vérifiable principal, et un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client ; Vérifier : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmettre à un serveur de validation un deuxième ensemble d’identifiants vérifiables dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Selon un troisième aspect, l’invention concerne un ensemble du serveur marchand selon le deuxième aspect et d’au moins un terminal. Selon un quatrième et un cinquième aspect, l’invention propose un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction avec un serveur marchand impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction avec un serveur marchand impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention ; FIG. 3 la FIG. 3 illustre la coopération des équipements lors d’un mode de réalisation du procédé selon l’invention. DESCRIPTION DÉTAILLÉE Architecture La présente invention concerne un procédé pour la mise en œuvre d’une transaction avec un serveur marchand 2 impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, dans un système tel que représenté sur la FIG. 1 . Ladite transaction est initiée par ledit individu, via son terminal 1, au profit d’un marchand opérant le serveur marchand 2 (comme l’on verra plus loin, le serveur marchand 2 est généralement celui d’un tiers, par exemple dit PSP (payment service provider) dans le cas d’un paiement, auprès duquel le marchand a délégué la gestion des transactions à son profit – mais il peut alternativement gérer lui-même cette partie-là, i.e. le serveur marchand 2 est directement opéré par le marchand). Entre d’autres termes il s’agit d’une transaction entre ledit individu et le marchand, validée par ledit serveur 2. Elle est avantageusement de type paiement, en particulier par carte bancaire chez ledit marchand, i.e. le terminal 1 remplace une carte bancaire (de l’individu), que ce soit une transaction de type paiement en ligne ou de type paiement sans contact (via une communication sans fil de proximité, préférentiellement NFC ou QR code, entre le terminal 1 et un terminal du marchand connecté audit serveur 2). Il y a d’autres types de paiement possibles, par exemple par prélèvement bancaire, sur un blockchain (paiement dans une cryptomonnaie, etc.). On note que la transaction n’est cependant pas limitée à un paiement (transfert d’argent), et ce pourra tout à fait être par exemple toute transaction permettant de se prévaloir d’une réservation, d’un contrat, d’une propriété, ou de droits en général (droits d’accès, droit sociaux, droits médicaux, etc.). Par exemple, dans le cas où le marchand opère un distributeur automatique, l’individu peut avoir « prépayé » des achats en achetant des tokens, et la transaction consiste à utiliser un token au lieu de sa carte bancaire. On citera par exemple, dans le même style, une transaction permettant de donner l’accès à un véhicule de location, une chambre d’hôtel, etc. La transaction peut également être la commande de médicaments en échange d’une ordonnance/carte vitale. On verra de nombreux exemples plus loin. La transaction implique la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, ce qui signifie qu’elle n’est pas libre. En d’autres termes, ledit critère (et chaque critère s’il y en a plusieurs) doit être vérifié pour que la transaction soit acceptée par le marchand. Sinon elle est rejetée même si le paiement pouvait être bon. On verra plus loin de nombreux critères possibles et les attributs correspondants. Le serveur marchand 2 est connecté via un réseau 20 (en particulier le réseau internet) à un serveur de validation de transaction 3, en particulier un serveur bancaire, généralement distant. Le terminal 1 est généralement lui-mêmes connecté via ce réseau 20 au serveur marchand 2 et/ou au serveur de validation 3 (même si une communication de courte portée avec le serveur marchand 2 reste possible). Le terminal 1 et le serveur marchand 2 disposent chacun de moyens de traitement de données 11, 21 (typiquement un processeur) et de moyens de stockage de données 12, 22 (une mémoire, par exemple flash). Le terminal 1 est typiquement un terminal mobile de type smartphone ou autre (montre connectée, wallet sur un PC, etc.), et le serveur marchand 2 est typiquement un serveur intermédiaire dit PSP. Comme expliqué, on a en outre le serveur de validation 3, typiquement un serveur bancaire, connecté au serveur marchand 2 par le réseau 20. Ce serveur 3 est dit de validation car c’est lui au final qui valide ou non la mise en œuvre de la transaction sur la base des informations fournies par l’individu 1. Procédé En référence aux figures 2 et 3 , le présent procédé, mis en œuvre par les moyens de traitement de données 21 du serveur marchand 2, commence généralement par une étape (b) de réception depuis le terminal 1 de l’individu d’un premier ensemble d’identifiants vérifiables (noté VP1) dont au moins un identifiant vérifiable unique pour la mise en œuvre de la transaction, dit identifiant vérifiable principal, et un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client 1. Par « identifiant vérifiable », on entend un objet précis, bien connu de l’homme du métier, en anglais sous le nom de VC (Verifiable Credential), qui est une représentation numérique signée par une entité de confiance de tout ou partie d’un crédentiel de l’individu, c’est-à-dire tout document officiel associé à l’individu tel qu’un document d’identité, mais également d’un moyen de paiement, d’un diplôme, de toute attestation de droit ou de propriété, etc. En référence à la FIG. 1 , on voit un « triangle » dit Titulaire-Emetteur-Vérificateur (Holder-Issuer-Verifier) représentant les relations de confiance qui permettent l’utilisation à un VC d’avoir la même valeur qu’un document original : L’entité d’autorité 4 est l’Emetteur à l’origine du VC, qu’il confie au Titulaire sur requête de ce dernier. Pour un VC de moyen de paiement, l’Emetteur est typiquement une banque, pour un VC d’identité le gouvernement, pour un VC de diplôme une université, etc. A noter qu’il peut y avoir plusieurs émetteurs et donc plusieurs autorités 4 pour différents types de VC ; L’individu est le Titulaire, le détendeur du VC (puisque détenteur du document original), qu’il peut fournir au Vérificateur ; Le marchand est le Vérificateur, il fait confiance à l’Emetteur si un Titulaire lui présente un VC. On pourra également se référencer à la page https://fr.wikipedia.org/wiki/Identifiants_v%C3%A9rifiables. Dans le présent procédé, on a plusieurs identifiants vérifiables de divers types. L’identifiant vérifiable principal (VC principal) est un identifiant vérifiable unique pour la mise en œuvre de la transaction. Par « unique » on entend que deux individus auront nécessairement des VC principaux différents, et par « pour la mise en œuvre de la transaction », on entend que ce VC est essentiel. Dans le mode de réalisation préféré d’une transaction de type paiement, il s’agit d’un identifiant vérifiable unique d’un moyen de paiement (on parle de VC de moyen de paiement), par exemple d’une carte bancaire. Dans ce dernier cas le VC comprend par exemple un PAN ou préférentiellement un token de la carte bancaire. Un autre exemple de VC de moyen de paiement est dans le cas d’un prélèvement bancaire ou un virement de compte à compte, et le VC peut contenir un IBAN et un mandat SCT, etc. D’autres moyens de paiements sont tout aussi compatibles, à savoir un compte de crypto-monnaie, un moyen de paiement de type Paypal, Google Pay, Apple Pay, etc. Alternativement à un VC de moyen de paiement, on peut par exemple avoir un : VC de réservation (contenant un identifiant unique d’un voucher, token, etc.), par exemple pour accès/récupération de clés d’hôtel, d’une voiture de location, etc. VC de propriété (contenant une preuve de possession du bien, par exemple un identifiant unique d’acte notarié) pour la mise en location d’appartement VC de propriété (contenant le numéro unique de la carte grise) pour la vente/mise en location de voiture (notamment entre particuliers) ; VC d’ordonnance médicale et carte vitale pour des soins (contenant un identifiant unique de l’ordonnance ou un PAN de la carte vitale) ; VC fiscal (contenant un NIF) pour demande d’aides. L’identifiant vérifiable secondaire (VC secondaire) est un identifiant vérifiable relatif audit attribut de l’identité dudit individu (sur lequel porte le critère à vérifier) mais pas nécessaire pour la mise en œuvre de ladite transaction. On parle également de VC identité. On comprend que (1) un VC identité est uniquement relatif à un attribut (et donc un aspect) et pas toute l’identité de sorte à maintenant le maximum de confidentialité sur les autres attributs, (2) il n’est pas unique (plusieurs personnes peuvent avoir le même attribut, par exemple la même date de naissance et donc le même âge), et (3) il ne participe pas à la mise en œuvre de ladite transaction contrairement au VC principal, i.e. le VC secondaire. Il y a donc une distinction claire entre le VC principal et le VC secondaire. Il y a généralement un unique VC principal (à noter qu’il pourrait en avoir plusieurs en cas de transaction « en plusieurs fois » ou d’abonnement), et potentiellement une pluralité de VC secondaires, en particulier s’il y a plusieurs critères à vérifier. On peut notamment utiliser des VC secondaires relatifs aux attributs suivants de l’identité : Date de naissance/âge (voire éventuellement un simple booléen indiquant si l’individu est majeur ou non) Adresse (voire un simple booléen indiquant si l’individu habite dans un pays, une commune ou une communauté de commune attendu(e)) Taille Nationalité Situation familiale/relation de filiation ou maritale avec une autre personne Diplôme (type de diplôme et/ou année d’obtention) statut professionnel (chômage, travail, formation, etc.) Employeur actuel assurance maladie (statut, incluant mutuelle, CMU, etc.) handicap (cécité, surdité, mobilité réduite, etc.) carte de fidélité/de réduction (ouvrant droit à une cagnotte, ou des tarifs particuliers) Etc. Il est à noter que lesdits identifiants vérifiables principal et secondaire sont préférablement choisis dans une liste d’identifiants vérifiables dudit utilisateur émis par ladite autorité 4 et stockés par des moyens de stockage de données 12 du terminal 1, suite à un enrôlement préalable. En effet, le présent procédé commence avantageusement par une étape (a0) préalable de transmission au terminal 1 (toujours par le serveur marchand 2) d’une requête d’informations pour la mise en œuvre de ladite transaction, exprimant ledit critère à vérifier. Ladite requête peut être signée (avec une clé privée du marchand) et comprend en particulier préférentiellement Des informations descriptives de ladite transaction (type, marchand, montant, etc.) ; La liste de VC requis, ou du moins des attributs concernés ; Les éventuelles preuves/signatures/éléments de sécurité requis. Par conséquent, le procédé comprend avantageusement une étape (a1) (mise en œuvre du côté terminal 1) de sélection par l’individu sur son terminal 1 desdits identifiants vérifiables principal et secondaire dans ladite liste d’identifiants vérifiables dudit utilisateur. En effet, dans la mesure où les VC sont tous relatifs à des informations personnelles, il est préférable que ce soit l’individu qui prenne la décision finale d’accepter d’inclure ces VC dans le premier ensemble VP1. A noter qu’il reste possible alternativement que le terminal 1 génère automatiquement VP1 en sélectionnant les VC nécessaires (grâce à la requête reçue), ou encore les présélectionne et laisse à l’individu le dernier mot. Ceci permet d’opérer une transaction « one click » où l’utilisateur n’a plus que valider la transaction. De manière préférée, l’étape (a1) comprend en outre l’authentification de l’individu sur le terminal 1 pour la transmission du VP1, en particulier par saisie d’un code PIN ou par authentification biométrique, de sorte à atteindre une authentification forte ( multi-facteur se base), laquelle se base habituellement sur la vérification du terminal 1 enregistré pendant une phase d’enrôlement (facteur de possession, « ce que l’on possède »), sur un code secret (facteur de connaissance – « ce que l’on connait ») et/ou sur la biométrie de l’utilisateur (facteur d’inhérence - « qui on est »). En effet, il est préférable de s’assurer du consentement de l’individu à mettre en œuvre la transaction/fournir les VC relatifs aux attributs. Ledit premier ensemble d’identifiants vérifiables noté VP1 est ce que l’on appelle une « présentation vérifiable », ou VP (verifiable presentation). C’est un conteneur à VC, signé par son émetteur le terminal 1 (avec sa clé privée). De manière préférée, la VP1 comprend également lesdites informations descriptives de ladite transaction (récupérées de la requête reçue à l’étape (a0), en particulier contresignées également avec ladite clé privée. Ces informations contresignées constituent une preuve du consentement de l’individu, et de manière préférée la contresignature desdites informations descriptives de ladite transaction n’est mise en œuvre que lorsque l’individu est authentifié (i.e. c’est l’authentification qui déclenche la signature puis la suite du procédé). A ce titre, l’étape (a1) comprend en outre la signature par les moyens de traitement de données 11 du terminal 1 dudit premier ensemble d’identifiant vérifiable VP1, avant sa transmission au serveur marchand 2 à l’étape (b). Pour reformuler encore, parce qu’il y a eu la sélection des VCs et l’authentification de l’individu pour la construction et signature de la VP1, la VP1 certifie aussi le consentement de l’utilisateur pour cette transaction dans la suite du processus. Aujourd’hui le traitement de transactions électroniques repose classiquement sur des protocoles de sécurités complexes et couteux à mettre en œuvre. En effet ces transactions électroniques se basent habituellement sur des données sensibles et parfois personnelles que l’utilisateur doit transmettre aux serveurs Marchands : il faut donc les contrôler et les sécuriser afin de pouvoir traiter la transaction. De plus, ces données personnelles et sensibles ne sont habituellement que des identifiants qui permettent de traiter les transactions à partir du bon compte des utilisateurs. Ces identifiants ne sont porteurs d’aucune autres informations qui pourraient améliorer, changer ou contraindre le traitement transactionnel. De plus, pour des transactions hautement sécurisées, ces protocoles inclus très régulièrement des systèmes d’authentification forte multi-facteur basés sur le déploiement d’une application sur le terminal de l’utilisateur (souvent un mobile) qui permet d’assurer à la fois le consentement de l’utilisateur et l’authentification de ce dernier pour valider la transaction électronique. Cela pose quelques difficultés et complexités: La mise en place du protocole de sécurité implique un certains nombres d’acteurs avec lesquels il y a beaucoup d’échanges électroniques qui génèrent par défaut des délais dans les temps de réponses et des couts de fonctionnement. La mise en place de l’application d’authentification forte pour le consentement de l’utilisateur implique la maintenance d’un haut niveau de sécurité de cette application et surtout de faire fonctionner les serveurs d’authentifications. Les données personnelles et sensibles utilisées par l’utilisateur pour faire la transaction ne permettent pas d’ajouter des services supplémentaires comme par exemple limiter les marchands autorisés, contraindre les heures ou les dates autorisées pour les transactions. La capture du consentement et l’authentification forte de l’utilisateur ne peut se faire qu’en étant connecté à Internet. La présente invention vient donc astucieusement améliorer ces situations grâce aux système des multiples VP. Ensuite, le procédé comprend une étape (b), toujours mise en œuvre par le serveur marchand 2, de vérification de : ladite signature ; la validité de chaque identifiant vérifiable ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu. La signature se vérifie de manière classique, en particulier avec une clé publique du terminal 1. Chaque VC se vérifie grâce à l’Emetteur, en particulier en vérifiant une signature du VC par son Emetteur (à nouveau par clé publique). Chaque critère se vérifie par un test logique simple tel qu’une comparaison : par exemple si le critère est « majeur », alors on vérifiera que l’un des VC secondaire est bien « preuve d’âge adulte », ce qui permet de ne pas devoir demander l’âge ou même la date de naissance de la personne, information qui ne sont pas nécessaires et personnelles. On pourra aussi vérifier que le pays de résidence d’une personne est bien celui nécessaire à la délivrance du service ou produit. A noter que comme expliqué, un VC secondaire peut au final être un booléen et on vérifie juste qu’il est égal à vrai. On note que le VC principal n’est pas vérifié, ce sera en pratique le rôle du serveur 3. Si l’une des vérifications est rejetée, c’est que l’utilisateur est potentiellement en train de frauder en ce qui concerne le critère (même si les informations de paiement sont quant à elles exactes). Enfin, le procédé comprend une étape (d) toujours mise en œuvre par le serveur marchand 2 de signature (avec sa clé privée) et de transmission au serveur de validation 3 d’un deuxième ensemble d’identifiants vérifiables (une deuxième présentation vérifiable notée VP2) dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Ce dernier VC, dit VC marchand est l’équivalent du VC principal mais pour le marchand, i.e. c’est un identifiant unique pour la mise en œuvre de la transaction, par exemple un identifiant d’un compte bancaire du marchand dans le cas d’une transaction de paiement, l’identifiant unique d’une clé pour une location de voiture ou de chambre, etc. De manière préférée, la VP2 ne contient aucun VC secondaire : en effet, le serveur 3 n’en a pas besoin puisqu’on répète qu’ils ne contiennent pas d’informations nécessaires à la transaction, et le ou les critères ont déjà été vérifiés. Par contre, la VP2 comprend également avantageusement lesdites informations descriptives de ladite transaction de la VP1 (on note qu’elles sont contresignées par le terminal 1, i.e. déjà signées par chacun du terminal 1 et du serveur marchand 4). A noter que cette VP2 peut contenir la liste des critères vérifiés ou du moins une preuve que la vérification a été faite. Alternativement, la VP2 peut ne rien contenir d’autre que lesdits VC principaux et les informations descriptives de la transaction. Et à l’instar de ce qui est fait pour la VP1, ledit deuxième ensemble (VP2) est préférentiellement signé par le serveur marchand 2 (toujours avec sa clé privée). De cette manière, le serveur marchand 2 certifie que les critères ont été vérifiés. A ce stade, dans une étape (e) avantageuse, les moyens de traitement de données 31 du serveur 3 vérifient la VP2 de manière similaire à ce qu’a fait le serveur 2 avec la VP1, i.e. vérification de : ladite signature (celle du serveur marchand) ; la validité de chaque identifiant vérifiable. Si la VP2 contient des informations descriptives de ladite transaction contresignée, ses signatures son vérifiées. On note que le serveur 3 n’a pas de moyen ni de savoir qu’un critère a été vérifié ni de connaître les attributs de l’identité de l’individu qui ont été utilisés pour cette vérification, ce qui garantit la vie privée de l’individu. Alors, l’étape (e) peut comprendre la mise en œuvre classique de la transaction (transfert d’argent, etc.), en d’autres termes le « processing » de la transaction, puisque le serveur 3 dispose de toutes les informations dont il a besoin dans la VP2, et est assuré du consentement de l’individu. Si la transaction porte sur un token, le serveur 3 peut par exemple mettre en œuvre la transaction en vérifiant l’authenticité du token et en le détruisant. De manière particulièrement préférée, le procédé comprend une étape (f) de réception depuis le serveur de validation 3 d’un troisième ensemble d’identifiants vérifiables (une dernière VP notée VP3) dont au moins un identifiant vérifiable relatif à la confirmation de la transaction. Encore une fois, ledit troisième ensemble (VP3) est préférentiellement signé par le serveur de validation 3 (toujours avec sa clé privée). Ledit identifiant vérifiable relatif à la confirmation de la transaction est par exemple un VC de la banque contenant un identifiant unique de la transaction mise en œuvre. VP3 peut contenir lesdites informations descriptives de ladite transaction de VP1 et VP2 à nouveau contresignées par le serveur de validation 3. Ceci permet à cette VP3 de certifier et retracer toute la transaction depuis l’envoi des VCs par le terminal 1 jusqu’à la mise en œuvre effective de la transaction en passant par la vérification des critères. Lesdites informations descriptives de ladite transaction contresignées par tout le monde peuvent être conservées comme preuve du consentement de l’individu. L’étape (f) comprend alors, suite à cette réception qui confirme bien que la transaction est accomplie, le déclenchement d’une action correspondant à la contrepartie de la transaction : l’expédition d’un produit acheté en ligne, la mise en marche d’un distributeur automatique, le déblocage d’une clé de voiture/ chambre, etc. A noter que la VP3 peut également être transmise au terminal 1, ce dernier peut la conserver en tant que preuve finale. Serveur Selon un deuxième aspect, l’invention concerne le serveur 2 pour la mise en œuvre du procédé selon le premier aspect. Le serveur marchand 2 comprend des moyens de traitement de données 21 et des moyens de stockage de données 22. Les moyens de traitement de données 21 sont configurés pour : Recevoir, depuis un terminal 1 d’un individu à l’origine d’une transaction avec ledit serveur marchand 2 impliquant la vérification d’au moins un critère portant sur un attribut de l’identité dudit individu, un premier ensemble d’identifiants vérifiables (VP1) dont au moins un identifiant vérifiable unique pour la mise en œuvre de ladite transaction, dit identifiant vérifiable principal, et un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client 1 ; Vérifier : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmettre, à un serveur de validation 3 de ladite transaction, un deuxième ensemble d’identifiants vérifiables (VP2) dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Selon un troisième aspect, l’invention concerne l’ensemble du serveur 2 selon le deuxième aspect et d’au moins un terminal 1, et avantageusement un serveur de validation 3, connectés via ledit réseau 20. Produit programme d’ordinateur Selon un quatrième et un cinquième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 21 du serveur marchand 2) d’un procédé selon le premier aspect pour la mise en œuvre d’une transaction avec le serveur marchand 2 impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction ; et un moyen de stockage (par exemple les moyens de stockage de données 22 du serveur marchand 2) sur lequel on trouve ce produit programme d’ordinateur. Procédé pour la mise en œuvre d’une transaction avec un serveur marchand (2) impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, caractérisé en ce qu’il comprend la mise en œuvre par des moyens de traitement de données (21) dudit serveur marchand (2), d’étapes de : Réception depuis un terminal (1) de l’individu d’un premier ensemble d’identifiants vérifiables (VP1) dont au moins un identifiant vérifiable unique pour la mise en œuvre de la transaction, dit identifiant vérifiable principal, un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client (1) ; Vérification de : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmission, à un serveur de validation (3) de ladite transaction, d’un deuxième ensemble d’identifiants vérifiables (VP2) dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Procédé selon la revendication 1 comprend une étape préalable (a0) de transmission au terminal (1) d’une requête d’informations pour la mise en œuvre de ladite transaction, exprimant ledit critère à vérifier. Procédé selon l’une des revendications 1 et 2, dans lequel lesdits identifiants vérifiables principal et secondaire sont choisis dans une liste d’identifiants vérifiables dudit utilisateur émis par une autorité et stockés par des moyens de stockage de données (12) du terminal (1). Procédé selon la revendication 3, comprenant une étape (a1) de sélection par l’individu sur son terminal (1) desdits identifiants vérifiables principal et secondaire dans ladite liste d’identifiants vérifiables dudit utilisateur ; et de signature par les moyens de traitement de données (11) du terminal (1) dudit premier ensemble d’identifiants vérifiables (VP1). Procédé selon la revendication 4, dans lequel l’étape (a1) comprend en outre l’authentification de l’individu sur le terminal (1) de sorte à prouver son consentement à mettre en œuvre la transaction. Procédé selon l’une des revendications 1 à 5, dans lequel ladite transaction est de type paiement, et ledit identifiant vérifiable principal représente un identifiant unique d’un moyen de paiement de l’individu. Procédé selon l’une des revendications 1 à 6, dans lequel ledit deuxième ensemble d’identifiants vérifiables (VP2) ne comprend aucun identifiant vérifiable secondaire du premier ensemble d’identifiants vérifiables (VP1). Procédé selon l’une des revendications 1 à 7, dans lequel ledit attribut est choisi dans la liste suivante : date de naissance/âge, adresse, taille, nationalité, situation familiale, diplôme, statut professionnel, employeur actuel, assurance maladie, handicap, permis de conduire, date d’obtention du permis de conduire, identifiant de carte de fidélité, points de fidélité, droits d’accès. Procédé selon l’une des revendications 1 à 8, dans lequel le deuxième ensemble d’identifiants vérifiables (VP2) est signé par le serveur marchand (2) à l’étape (d), le procédé comprenant une étape (e), mise en œuvre par des moyens de traitement de données (31) du serveur de validation (3) de ladite transaction, de vérification de : ladite signature du deuxième ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du deuxième ensemble d’identifiants vérifiables ; Procédé selon l’une des revendications 1 à 9, comprenant une étape (f) de réception, depuis le serveur de validation (3) de la transaction, d’un troisième ensemble d’identifiants vérifiables (VP3) dont au moins un identifiant vérifiable relatif à la confirmation de la transaction. Procédé selon la revendication 10, dans lequel le premier ensemble d’identifiants vérifiables (VP1) contient des informations descriptives de ladite transaction signées par le serveur marchand (2) et contresignées par le terminal (1), ces informations descriptives de ladite transaction étant incluses dans le deuxième ensemble d’identifiants vérifiables (VP2), puis contresignées par le serveur de validation (3) et incluses dans le troisième ensemble d’identifiants vérifiables (VP3). Serveur marchand (2), caractérisé en ce qu’il comprend des moyens de traitement de données (21) configurés pour : Recevoir, depuis un terminal (1) d’un individu à l’origine d’une transaction avec ledit serveur marchand (2) impliquant la vérification d’au moins un critère portant sur un attribut de l’identité dudit individu, un premier ensemble d’identifiants vérifiables (VP1) dont au moins un identifiant vérifiable unique pour la mise en œuvre de ladite transaction, dit identifiant vérifiable principal, et un identifiant vérifiable relatif audit attribut de l’identité dudit individu mais pas nécessaire pour la mise en œuvre de ladite transaction, dit identifiant vérifiable secondaire, ledit premier ensemble étant signé par le terminal client (1) ; Vérifier : ladite signature du premier ensemble d’identifiants vérifiables ; la validité de chaque identifiant vérifiable du premier ensemble d’identifiants vérifiables ; chaque critère portant sur un attribut de l’identité dudit individu en fonction dudit identifiant vérifiable relatif audit attribut de l’identité dudit individu ; Transmettre, à un serveur de validation (3) de la transaction, un deuxième ensemble d’identifiants vérifiables (VP2) dont ledit identifiant vérifiable principal et un identifiant vérifiable relatif audit marchand. Ensemble du serveur marchand (2) selon la revendication 12 et d’au moins un terminal (1). Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 pour la mise en œuvre d’une transaction avec un serveur marchand (2) impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction, lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 11 pour la mise en œuvre d’une transaction avec un serveur marchand (2) impliquant la vérification d’au moins un critère portant sur un attribut de l’identité d’un individu à l’origine de ladite transaction.