Method for implementing a transaction with a merchant server involving the verification of a criterion relating to an attribute of the identity of an individual initiating said transaction.

Abstract

The present invention relates to a method for implementing a transaction with a merchant server (2) involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction, characterized in that it comprises the implementation by data processing means (21) of said merchant server (2), of the steps of: Receiving from a terminal (1) of the individual a first set of verifiable identifiers (VP1) of which at least one unique verifiable identifier for the implementation of the transaction, called the primary verifiable identifier, and a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal (1); Verification of: said signature of the first set of verifiable identifiers;the validity of each verifiable identifier from the first set of verifiable identifiers; each criterion relating to an attribute of the identity of said individual as a function of said verifiable identifier relating to said attribute of the identity of said individual; Transmission, to a validation server (3) of the transaction, of a second set of verifiable identifiers (VP2) including said main verifiable identifier and a verifiable identifier relating to said merchant [Fig. 1];

Description

Title of the invention: Method for implementing a transaction with a merchant server involving the verification of a criterion relating to an attribute of the identity of an individual originating said transaction.

[0001] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of electronic transactions. More specifically, it concerns a method for implementing a transaction with a merchant server involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction.

[0003] STATE OF THE ART

[0004] Today we know of "one click" payment solutions: an individual, having dematerialized their payment information on their mobile terminal, only has to authenticate themselves, for example by presenting a biometric trait (their face, a fingerprint, etc.) to initiate the transaction.

[0005] The problem is that many transactions today require the merchant to verify attributes of the identity of the individual initiating the transaction.

[0006] For example, some products can only be purchased by adults (alcohol or cigarettes, for example), and the transaction involves verifying that the individual is of legal age. Similarly, if the transaction is the rental of a vehicle, it involves verifying that the individual has a valid driver's license. Another use case would be the use of an ATM reserved for guests of a residence or hotel.

[0007] Naturally, the user can declare on his honor that he meets the condition (by ticking for example a box "I am over 18 years old"), but a higher level of proof is desirable.

[0008] For this purpose, the user can directly provide an identity document, for example identity card / passport for proof of majority, or directly the license for car rental, as proof, for example a scanned version, where appropriate signed by a trusted entity.

[0009] This, however, raises two problems: - An identity document contains a lot of personal data (name, address, photo, etc.), which goes beyond what is required for the implementation of the transaction, so that the individual's private life is unnecessarily exposed (privacy problem); - One-click payments are no longer possible because you can't simply send your ID document along with your payment information. to the extent that it is not the bank server that verifies the attributes of the individual's identity but the merchant (it is their responsibility not to authorize the transaction if necessary).

[0010] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0011] The present invention therefore relates, in a first aspect, to a method for implementing a transaction with a merchant server involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction, characterized in that it comprises the implementation, by means of data processing of said merchant server, of the following steps: a. Receipt from an individual's terminal of a first set of verifiable identifiers, including at least one unique verifiable identifier for the implementation of the transaction, called the primary verifiable identifier, and a verifiable identifier relating to said attribute of the individual's identity but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal; b. Verification of: - said signature of the first set of verifiable identifiers; - the validity of each verifiable identifier in the first set of verifiable identifiers; - each criterion relating to an attribute of the identity of said individual according to said verifiable identifier relating to said attribute of the identity of said individual; a. Transmission to a validation server of a second set of verifiable identifiers including said main verifiable identifier and a verifiable identifier relating to said merchant.

[0012] According to advantageous and non-limiting features:

[0013] The method includes a preliminary step (aO) of transmitting to the terminal a request for information for the implementation of said transaction, expressing said criterion to be verified.

[0014] Said primary and secondary verifiable identifiers are chosen from a list of verifiable identifiers of said user issued by an authority and stored by terminal data storage means.

[0015] The process includes a step (al) of selection by the individual on his terminal of said verifiable primary and secondary identifiers in said list of verifiable identifiers of said user; and of signature by the data processing means of the terminal of said first set of verifiable identifiers.

[0016] Step (al) further includes the authentication of the individual on the terminal.

[0017] Said transaction is of the payment type, and said primary verifiable identifier represents a unique identifier of an individual's means of payment.

[0018] Said second set of verifiable identifiers does not include any secondary verifiable identifier from the first set of verifiable identifiers.

[0019] Said attribute is chosen from the following list: date of birth / age, address, height, nationality, family status, diploma, professional status, current employer, health insurance, disability, driving licence, date of obtaining driving licence, loyalty card identifier, loyalty points, access rights.

[0020] The second set of verifiable identifiers is signed by the merchant server in step (d), the process comprising a step (e), implemented by data processing means of a validation server for said transaction, of verification of: - said signature of the second set of verifiable identifiers; - the validity of each verifiable identifier in the second set of verifiable identifiers;

[0021] The method includes a step (f) of receiving, from a transaction validation server, a third set of verifiable identifiers, at least one of which is a verifiable identifier relating to the confirmation of the transaction.

[0022] The first set of verifiable identifiers contains descriptive information of said transaction signed by the merchant server and countersigned by the terminal, this descriptive information of said transaction being included in the second set of verifiable identifiers, then countersigned by the validation server and included in the third set of verifiable identifiers.

[0023] According to a second aspect, the invention relates to a merchant server, characterized in that it comprises data processing means configured to: - To receive, from a terminal of an individual who initiated a transaction with said merchant server involving the verification of at least one criterion relating to an attribute of the identity of said individual, a first set of verifiable identifiers including at least one unique verifiable identifier for the implementation of said transaction, called the primary verifiable identifier, and a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal; - Check : • said signature of the first set of verifiable identifiers; • the validity of each verifiable identifier in the first set of verifiable identifiers; • each criterion relating to an attribute of the identity of said individual based on said verifiable identifier relating to said attribute of the identity of said individual; - Transmit to a validation server a second set of verifiable identifiers including the said main verifiable identifier and a verifiable identifier relating to said merchant.

[0024] According to a third aspect, the invention relates to a merchant server assembly according to the second aspect and at least one terminal.

[0025] According to a fourth and a fifth aspect, the invention proposes a computer program product comprising code instructions for the execution of a process according to the first aspect for the implementation of a transaction with a merchant server involving the verification of at least one criterion relating to an attribute of the identity of an individual originating said transaction; and a computer-readable storage means on which is stored a computer program product comprising code instructions for the execution of a process according to the first aspect for the implementation of a transaction with a merchant server involving the verification of at least one criterion relating to an attribute of the identity of an individual originating said transaction. PRESENTATION OF THE FIGURES

[0026] Other features and advantages of the present invention will become apparent from the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings in which:

[0027] [Fig.1] [Fig.1] is a diagram of a system for implementing the method according to the invention;

[0028] [Fig.2] [Fig.2] is a flowchart illustrating the steps of an embodiment of the process according to the invention;

[0029] [Fig.3] [Fig.3] illustrates the cooperation of the equipment during an embodiment of the process according to the invention. DETAILED DESCRIPTION

[0030] Architecture

[0031] The present invention relates to a method for implementing a transaction with a merchant server 2 involving the verification of at least one criterion relating to an attribute of the identity of an individual originating said transaction, in a system as represented in [Fig.1].

[0032] Said transaction is initiated by said individual, via their terminal 1, for the benefit of a merchant operating the merchant server 2 (as will be seen later, the merchant server 2 is generally that of a third party, for example a PSP (payment service provider) in the case of a payment, to which the merchant has delegated the management of transactions for their benefit - but they may alternatively manage this part themselves, i.e., the merchant server 2 is directly operated by the merchant). In other words, it is a transaction between said individual and the merchant, validated by said server 2.

[0033] It is advantageously of the payment type, in particular by bank card at said merchant, i.e. terminal 1 replaces a bank card (of the individual), whether it is an online payment transaction or a contactless payment transaction (via a proximity wireless communication, preferably NFC or QR code, between terminal 1 and a merchant terminal connected to said server 2). There are other possible payment types, for example by bank transfer, on a blockchain (payment in a cryptocurrency, etc.).

[0034] It should be noted that the transaction is not limited to a payment (money transfer), and could very well be, for example, any transaction enabling the exercise of a reservation, a contract, ownership, or rights in general (access rights, social rights, medical rights, etc.). For example, if the merchant operates an ATM, the individual may have "prepaid" for purchases by buying tokens, and the transaction consists of using a token instead of a bank card. Similarly, a transaction granting access to a rental vehicle, a hotel room, etc., could also be the ordering of medication in exchange for a prescription / health insurance card. Many more examples will be seen later.

[0035] The transaction involves the verification of at least one criterion relating to an attribute of the identity of the individual initiating said transaction, which means that it is not free. In other words, said criterion (and each criterion if there are several) must be verified for the transaction to be accepted by the merchant. Otherwise, it is rejected even if the payment would have been valid. Many possible criteria and their corresponding attributes will be discussed later.

[0036] The merchant server 2 is connected via a network 20 (in particular the internet) to a transaction validation server 3, in particular a banking server, generally remote. The terminal 1 is itself generally connected via this network 20 to the merchant server 2 and / or the validation server 3 (although short-range communication with the merchant server 2 remains possible).

[0037] Terminal 1 and merchant server 2 each have data processing means 11, 21 (typically a processor) and data storage means 12, 22 (a memory, for example flash). Terminal 1 is typically a mobile terminal such as a smartphone or other (smartwatch, wallet on a PC, etc.), and merchant server 2 is typically an intermediate server called PSP.

[0038] As explained, there is also the validation server 3, typically a banking server, connected to the merchant server 2 by the network 20. This server 3 is called the validation server because it is ultimately the one that validates or does not validate the implementation of the transaction on the basis of the information provided by individual 1.

[0039] Process

[0040] With reference to Figures 2 and 3, the present method, implemented by the data processing means 21 of the merchant server 2, generally begins with a step (b) of receiving from the individual's terminal 1 a first set of verifiable identifiers (denoted VP1) of which at least one unique verifiable identifier for the implementation of the transaction, called the primary verifiable identifier, and a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal 1.

[0041] By "verifiable identifier," we mean a specific object, well known to those skilled in the art, in English as a VC (Verifiable Credential), which is a digital representation signed by a trusted entity of all or part of an individual's credential, that is to say, any official document associated with the individual such as an identity document, but also a means of payment, a diploma, any certificate of right or ownership, etc. With reference to [Fig. 1], we see a "triangle" called Holder-Issuer-Verifier, representing the trust relationships that allow the use of a VC to have the same value as an original document: - Authority entity 4 is the Issuer who created the VC, which it entrusts to the Holder at the latter's request. For a VC of a means of payment, the Issuer is typically a bank, for an identity VC the government, for a diploma VC a university, etc. Note that there can be several issuers and therefore several authorities 4 for different types of VC; - The individual is the Holder, the custodian of the VC (since he is the holder of the original document), which he can provide to the Verifier; - The merchant is the Verifier, he trusts the Issuer if a Holder presents him with a VC.

[0042] Reference can also be made to the page https: / / fr.wikipedia.org / wiki / Identifiants_v%C3 % A9rifiables.

[0043] In the present process, there are several verifiable identifiers of various types.

[0044] The primary verifiable identifier (primary VC) is a unique verifiable identifier for the implementation of the transaction. "Unique" means that two individuals will necessarily have different primary VCs, and "for the implementation of the transaction" means that this VC is essential. In the preferred embodiment of a payment transaction, it is a unique verifiable identifier of a payment method (referred to as a payment method VC), for example, a bank card. In this latter case, the VC includes, for example, a PAN or, preferably, a bank card token. Another example of a payment method VC is in the case of a bank transfer or an account-to-account transfer, and the VC may contain an AN IBAN and an SCT mandate, etc. Other payment methods are equally compatible, namely a cryptocurrency account, a payment method such as PayPal, Google Pay, Apple Pay, etc.

[0045] As an alternative to a means of payment VC, one can for example have: - a reservation VC (containing a unique identifier of a voucher, token, etc.), for example for access / collection of hotel keys, a rental car, etc. - VC of ownership (containing proof of ownership of the property, for example a unique identifier of notarial deed) for the rental of an apartment - VC of ownership (containing the unique number of the registration certificate) for the sale / rental of a car (especially between individuals); - VC of medical prescription and health insurance card for care (containing a unique identifier of the prescription or a PAN of the health insurance card); - Tax VC (containing a NIF) for aid applications.

[0046] The secondary verifiable identifier (secondary VC) is a verifiable identifier relating to an attribute of the individual's identity (on which the criterion to be verified is based) but not necessary for the implementation of the transaction. It is also referred to as an identity VC. It is understood that (1) an identity VC relates only to one attribute (and therefore one aspect) and not to the entire identity, so as to maintain maximum confidentiality regarding the other attributes, (2) it is not unique (several people can have the same attribute, for example, the same date of birth and therefore the same age), and (3) it does not participate in the implementation of the transaction, unlike the primary VC, i.e., the secondary VC. There is therefore a clear distinction between the primary VC and the secondary VC.

[0047] There is generally a single primary VC (note that there could be several in the case of a "multiple installment" transaction or subscription), and potentially a plurality of secondary VCs, particularly if there are several criteria to be verified.

[0048] In particular, secondary VCs relating to the following attributes of the identity can be used: - Date of birth / age (or possibly a simple boolean indicating whether the individual is of legal age or not) - Address (or even a simple boolean indicating whether the individual lives in a country, a municipality or a group of municipalities expected) - Size - Nationality - Family situation / relationship of parentage or marital status with another person - Diploma (type of diploma and / or year of graduation) - professional status (unemployment, employment, training, etc.) - Current employer - health insurance (status, including supplementary health insurance, universal health coverage, etc.) - disability (blindness, deafness, reduced mobility, etc.) - loyalty / discount card (giving access to a savings account or discounted rates) individuals) - Etc.

[0049] It should be noted that said primary and secondary verifiable identifiers are preferably chosen from a list of verifiable identifiers of said user issued by said authority 4 and stored by data storage means 12 of terminal 1, following prior enrollment.

[0050] Indeed, the present process advantageously begins with a preliminary step (aO) of transmitting to terminal 1 (still via the merchant server 2) a request for information to implement said transaction, expressing said criterion to be verified. Said request may be signed (with a private key of the merchant) and preferably includes - Descriptive information about the said transaction (type, merchant, amount, etc.); - The list of required VCs, or at least the relevant attributes; - Any required evidence / signatures / security elements.

[0051] Therefore, the method advantageously includes a step (a1a) (implemented on terminal side 1) in which the individual selects, on their terminal 1, said primary and secondary verifiable identifiers from said list of verifiable identifiers of said user. Indeed, since the VCs are all related to personal information, it is preferable that the individual make the final decision to agree to include these VCs in the first set VP1.

[0052] It should be noted that it is also possible for terminal 1 to automatically generate VP1 by selecting the necessary VCs (based on the received request), or to pre-select them and leave the final decision to the individual. This allows for a "one-click" transaction where the user only has to validate the transaction.

[0053] Preferably, step (a1a) further includes authenticating the individual on terminal 1 for the transmission of VP1, in particular by entering a PIN or by biometric authentication, so as to achieve strong (multi-factor) authentication, which is usually based on verifying the terminal 1 registered during an enrollment phase (possession factor, "what one possesses"), on a secret code (knowledge factor, "what one knows"), and / or on the user's biometrics (inherence factor, "who one is"). Indeed, it is preferable to ensure the individual's consent to implement the transaction / provide the VCs relating to the attributes.

[0054] Said first set of verifiable identifiers, denoted VP1, is what is called a "verifiable presentation," or VP. It is a VC container, signed by its issuer, terminal 1 (with its private key). Preferably, VP1 also includes said descriptive information of said transaction (retrieved from the request received at step (aO), in particular countersigned also with said private key). This countersigned information constitutes proof of the individual's consent, and preferably the countersigning of said descriptive information of said transaction is only implemented when the individual is authenticated (i.e., authentication triggers the signing and then the rest of the process).

[0055] In this respect, step (a1a) further includes the signing by the data processing means 11 of terminal 1 of said first set of verifiable identifiers VP1, before its transmission to the merchant server 2 in step (b). To rephrase again, because the VCs have been selected and the individual authenticated for the construction and signing of VP1, VP1 also certifies the user's consent for this transaction in the subsequent process.

[0056] Today, the processing of electronic transactions typically relies on complex and costly security protocols. Indeed, these electronic transactions are usually based on sensitive and sometimes personal data that the user must transmit to the merchant servers: it is therefore necessary to control and secure this data in order to process the transaction.

[0057] Furthermore, this personal and sensitive data is usually only identifiers that allow transactions to be processed from the correct user account. These identifiers do not carry any other information that could improve, change, or constrain the transaction processing.

[0058] Moreover, for highly secure transactions, these protocols very regularly include strong multi-factor authentication systems based on the deployment of an application on the user's terminal (often a mobile phone) which allows both user consent and user authentication to validate the electronic transaction.

[0059] This poses some difficulties and complexities: - The implementation of the security protocol involves a number of actors with whom there is a lot of electronic exchange which by default generates delays in response times and operating costs. - The implementation of the strong authentication application for user consent implies the maintenance of a high level of security for this application and, above all, the operation of the authentication servers. - The personal and sensitive data used by the user to make the transaction does not allow the addition of additional services such as limiting authorized merchants, restricting authorized times or dates for transactions. - Capturing consent and strong user authentication can only be done when connected to the Internet.

[0060] The present invention therefore cleverly improves these situations thanks to the multiple VP system.

[0061] Next, the process includes a step (b), always implemented by the merchant server 2, of verifying: - said signature; - the validity of each verifiable identifier; - each criterion relating to an attribute of the identity of said individual according to said verifiable identifier relating to said attribute of the identity of said individual.

[0062] The signature is verified in a conventional way, in particular with a public key of terminal 1.

[0063] Each VC is verified by the Issuer, in particular by verifying a signature of the VC by its Issuer (again by public key).

[0064] Each criterion is verified by a simple logical test such as a comparison: for example, if the criterion is "adult," then we will verify that one of the secondary VCs is indeed "proof of adulthood," which avoids having to ask for the person's age or even date of birth, information that is unnecessary and personal. We can also verify that a person's country of residence is indeed the one required for the delivery of the service or product. Note that, as explained, a secondary VC can ultimately be a boolean, and we simply check that it is equal to true. Note that the primary VC is not verified; in practice, this will be the role of server 3.

[0065] If one of the checks is rejected, it means that the user is potentially committing fraud with regard to the criterion (even if the payment information is correct).

[0066] Finally, the process includes a step (d) always implemented by the merchant server 2 of signing (with its private key) and of transmission to the validation server 3 of a second set of verifiable identifiers (a second verifiable presentation noted VP2) of which said main verifiable identifier and a verifiable identifier relating to said merchant.

[0067] This latter VC, called the merchant VC, is the equivalent of the main VC but for the merchant, i.e. it is a unique identifier for the implementation of the transaction, for example an identifier of a merchant's bank account in the case of a payment transaction, the unique identifier of a key for a car or room rental, etc.

[0068] Preferably, VP2 does not contain any secondary VCs: indeed, server 3 does not need them since, as mentioned above, they do not contain information necessary for the transaction, and the criterion or criteria have already been verified. However, VP2 also advantageously includes the descriptive information of said transaction from VP1 (note that it is countersigned by terminal 1, i.e., already signed by both terminal 1 and merchant server 4). It should be noted that this VP2 may contain the list of verified criteria or at least proof that the verification has been performed. Alternatively, VP2 may contain nothing other than said primary VCs and the descriptive information of the transaction.

[0069] And as with VP1, said second set (VP2) is preferentially signed by merchant server 2 (again with its private key). In this way, merchant server 2 certifies that the criteria have been verified.

[0070] At this stage, in an advantageous step (e), the data processing means 31 of server 3 verify VP2 in a similar manner to what server 2 did with VP1, i.e., verification of: - said signature (that of the merchant server); - the validity of each verifiable identifier.

[0071] If VP2 contains descriptive information of said countersigned transaction, its signatures are verified.

[0072] It is noted that server 3 has no means of knowing that a criterion has been verified or of knowing the attributes of the individual's identity that were used for this verification, which guarantees the privacy of the individual.

[0073] So, step (e) can include the classic implementation of the transaction (money transfer, etc.), in other words the "processing" of the transaction, since server 3 has all the information it needs in VP2, and is assured of the individual's consent. If the transaction involves a token, server 3 can, for example, implement the transaction by verifying the authenticity of the token and destroying it.

[0074] In a particularly preferred manner, the process includes a step (f) of receiving from the validation server 3 a third set of verifiable identifiers (a final VP denoted VP3), at least one of which is a verifiable identifier relating to the confirmation of the transaction. Again, said third set (VP3) is preferably signed by the validation server 3 (always with its private key).

[0075] Said verifiable identifier relating to the confirmation of the transaction is for example a VC of the bank containing a unique identifier of the transaction implemented.

[0076] VP3 can contain the descriptive information of said transaction from VP1 and VP2, countersigned again by the validation server 3. This allows VP3 to certify and trace the entire transaction from the sending of the VCs by terminal 1 to the actual implementation of the transaction, including the verification of the criteria. This descriptive information of said transaction, countersigned by all parties, can be retained as proof of the individual's consent.

[0077] Step (f) then includes, following this receipt which confirms that the transaction is completed, the triggering of an action corresponding to the counterpart of the transaction: the shipment of a product purchased online, the activation of an automatic dispenser, the unlocking of a car / room key, etc.

[0078] Note that VP3 can also be transmitted to terminal 1, which can retain it as final proof.

[0079] Server

[0080] According to a second aspect, the invention relates to the server 2 for the implementation of the method according to the first aspect.

[0081] The merchant server 2 includes data processing means 21 and data storage means 22.

[0082] The data processing means 21 are configured to: - To receive, from a terminal 1 of an individual originating a transaction with said merchant server 2 involving the verification of at least one criterion relating to an attribute of the identity of said individual, a first set of verifiable identifiers (VP1) of which at least one unique verifiable identifier for the implementation of said transaction, called primary verifiable identifier, and a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called secondary verifiable identifier, said first set being signed by the client terminal 1; - Check : • said signature of the first set of verifiable identifiers; • the validity of each verifiable identifier in the first set of verifiable identifiers; • each criterion relating to an attribute of the identity of said individual based on said verifiable identifier relating to said attribute of the identity of said individual; - Transmit, to a validation server 3 of said transaction, a second set of verifiable identifiers (VP2) including said main verifiable identifier and a verifiable identifier relating to said merchant.

[0083] According to a third aspect, the invention relates to the entire server 2 according to the second aspect and at least one terminal 1, and advantageously a validation server 3, connected via said network 20.

[0084] Computer program product

[0085] According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means 21 of the merchant server 2) of a method according to the first aspect for the implementation of a transaction with the merchant server 2 involving the verification of at least one criterion relating to an attribute of the identity of an individual originating said transaction; and a storage means (for example the data storage means 22 of the merchant server 2) on which this computer program product is located.

Claims

Demands

1. A method for implementing a transaction with a merchant server (2) involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction, characterized in that it comprises the implementation by data processing means (21) of said merchant server (2), of the steps of: a. Receiving from a terminal (1) of the individual a first set of verifiable identifiers (VP1), which is a verifiable presentation, of which at least one unique verifiable identifier for the implementation of the transaction, called the primary verifiable identifier, a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal (1); b.Verification of: - said signature of the first set of verifiable identifiers; - the validity of each verifiable identifier of the first set of verifiable identifiers; - each criterion relating to an attribute of the identity of said individual as a function of said verifiable identifier relating to said attribute of the identity of said individual; a. Transmission, to a validation server (3) of said transaction, of a second set of verifiable identifiers (VP2), which is a verifiable presentation, including said main verifiable identifier and a verifiable identifier relating to said merchant.

2. The method according to claim 1 includes a preliminary step (aO) of transmitting to the terminal (1) a request for information for the implementation of said transaction, expressing said criterion to be verified.

3. A method according to any one of claims 1 and 2, wherein said primary and secondary verifiable identifiers are chosen from a list of verifiable identifiers of said user issued by an authority and stored by data storage means (12) of the terminal (1).

4. Method according to claim 3, comprising a step (al) of selection by the individual on his terminal (1) of said primary and secondary verifiable identifiers in said list of verifiable identifiers of said user; and of signature by the data processing means (11) of the terminal (1) of said first set of verifiable identifiers (VP1).

5. A method according to claim 4, wherein step (a1a) further includes the authentication of the individual on the terminal (1) so as to prove his consent to implement the transaction.

6. A method according to any one of claims 1 to 5, wherein said transaction is of the payment type, and said primary verifiable identifier represents a unique identifier of an individual's means of payment.

7. A method according to any one of claims 1 to 6, wherein said second set of verifiable identifiers (VP2) does not include any secondary verifiable identifier from the first set of verifiable identifiers (VP1).

8. A method according to any one of claims 1 to 7, wherein said attribute is selected from the following list: date of birth / age, address, height, nationality, marital status, diploma, professional status, current employer, health insurance, disability, driver's license, date of obtaining driver's license, loyalty card identifier, loyalty points, access rights.

9. A method according to any one of claims 1 to 8, wherein the second set of verifiable identifiers (VP2) is signed by the merchant server (2) in step (d), the method comprising a step (e), implemented by data processing means (31) of the validation server (3) of said transaction, of verifying: - said signature of the second set of verifiable identifiers; - the validity of each verifiable identifier of the second set of verifiable identifiers;

10. A method according to any one of claims 1 to 9, comprising a step (f) of receiving, from the transaction validation server (3), a third set of verifiable identifiers (VP3) of which at least one verifiable identifier relates to the confirmation of the transaction.

11. A method according to claim 10, wherein the first set of verifiable identifiers (VP1) contains descriptive information of said transaction signed by the merchant server (2) and countersigned by the terminal (1), this descriptive information of said transaction being included in the second set of verifiable identifiers (VP2), then countersigned by the validation server (3) and included in the third set of verifiable identifiers (VP3).

12. Merchant server (2), characterized in that it comprises data processing means (21) configured to: - Receive, from a terminal (1) of an individual initiating a transaction with said merchant server (2) involving the verification of at least one criterion relating to an attribute of the identity of said individual, a first set of verifiable identifiers (VP1), which is a verifiable presentation, of which at least one unique verifiable identifier for the implementation of said transaction, called the primary verifiable identifier, and a verifiable identifier relating to said attribute of the identity of said individual but not necessary for the implementation of said transaction, called the secondary verifiable identifier, said first set being signed by the client terminal (D; - Verify: • said signature of the first set of verifiable identifiers;• the validity of each verifiable identifier in the first set of verifiable identifiers; • each criterion relating to an attribute of the identity of said individual based on said verifiable identifier relating to said attribute of the identity of said individual; - Transmit, to a validation server (3) of the transaction, a second set of verifiable identifiers (VP2), which is a verifiable presentation, including said main verifiable identifier and a verifiable identifier relating to said merchant.

13. The merchant server (2) according to claim 12 and at least one terminal (1).

14. Product computer program comprising code instructions for carrying out a method according to any one of claims 1 to 11 for carrying out a transaction with a merchant server (2) involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction, when said program is executed on a computer.

15. Computer-readable storage means on which is recorded a computer program product comprising code instructions for carrying out a process according to any one of claims 1 to 11 for carrying out a transaction with a merchant server (2) involving the verification of at least one criterion relating to an attribute of the identity of an individual initiating said transaction.

Images