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 at the origin of 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 at the origin of said transaction, characterized in that it comprises the implementation by data processing means (21) of said merchant server (2), of steps of: Receiving from a terminal (1) of the individual a first set of verifiable identifiers (VP1) including at least one unique verifiable identifier for the implementation of the transaction, called the main 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); Verifying: 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 based on 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 at the origin of said transaction.

[0001] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of dematerialized transactions. More specifically, it relates 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 at the origin of 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 feature (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 an adult. Similarly, if the transaction is the rental of a vehicle, it involves verifying that the individual has a 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 honour that he meets the condition (for example by ticking a box "I am over 18"), but a higher level of proof is desirable.

[0008] For this, 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, if necessary signed by a trusted entity.

[0009] However, this poses 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 privacy is unnecessarily exposed (privacy problem); - You can no longer make a “one-click” payment, because you can’t just send the identity document with the payment information, in the since it is not the banking 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, according to 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 at the origin of said transaction, characterized in that it comprises the implementation by data processing means of said merchant server, of steps of: a. Reception from an individual terminal of a first set of verifiable identifiers including at least one unique verifiable identifier for the implementation of the transaction, called the main 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; 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 based on 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 primary verifiable identifier and a verifiable identifier relating to said merchant.

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

[0013] The method comprises a prior 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 data storage means of the terminal.

[0015] The method comprises a step (al) of selection by the individual on his terminal of said main and secondary verifiable 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 comprises authenticating the individual on the terminal.

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

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

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

[0020] The second set of verifiable identifiers is signed by the merchant server in step (d), the method comprising a step (e), implemented by data processing means of a server for validating 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;

[0021] The method comprises a step (f) of receiving, from a transaction validation server, a third set of verifiable identifiers including at least one 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: - Receive, from a terminal of an individual at the origin of 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 main 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 in function of 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 said primary verifiable identifier and a verifiable identifier relating to said merchant.

[0024] According to a third aspect, the invention relates to an assembly of the merchant server 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 executing a method according to the first aspect 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 at the origin of said transaction; and a storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for executing a method according to the first aspect 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 at the origin of said transaction. PRESENTATION OF FIGURES

[0026] Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

[0027] [Fig.l] [Fig.l] 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 method according to the invention;

[0029] [Fig.3] [Fig.3] illustrates the cooperation of the equipment during an embodiment of the method 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 at the origin of said transaction, in a system such as represented in [Fig.l].

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

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

[0034] It should be noted that the transaction is not, however, limited to a payment (money transfer), and it could very well be, for example, any transaction allowing one to claim a reservation, a contract, a property, or rights in general (access rights, social rights, medical rights, etc.). For example, in the case where the merchant operates an ATM, the individual may have "prepaid" for purchases by purchasing tokens, and the transaction consists of using a token instead of their bank card. For example, in the same style, a transaction allowing access to a rental vehicle, a hotel room, etc. could be cited. The transaction could also be the ordering of medication in exchange for a prescription / health card. We will see many examples later.

[0035] The transaction involves the verification of at least one criterion relating to an attribute of the identity of an individual at the origin of 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 could have been good. We will see later many possible criteria and the corresponding attributes.

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

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

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

[0039] Method

[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 terminal 1 of the individual a first set of verifiable identifiers (denoted VP1) including at least one unique verifiable identifier for the implementation of the transaction, called the main 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" is meant a specific object, well known to those skilled in the art, in English under the name of VC (Verifiable Credential), which is a digital representation signed by a trusted entity of all or part of a credential of the individual, 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.l], we see a "triangle" called Holder-Issuer-Verifier (Holder-Issuer-Verifier) ​​representing the trust relationships which allow the use of a VC to have the same value as an original document: - The authority entity 4 is the Issuer at the origin of the VC, which it entrusts to the Holder at the latter's request. For a payment method VC, the Issuer is typically a bank, for an identity VC the government, for a diploma VC a university, etc. Note that there may be several issuers and therefore several authorities 4 for different types of VC; - The individual is the Holder, the holder 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] We can also refer to the page https: / / fr.wikipedia.org / wiki / Identifiants_v%C3%A9rifiables.

[0043] In the present method, 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. By "unique" is meant that two individuals will necessarily have different primary VCs, and by "for the implementation of the transaction" is meant that this VC is essential. In the preferred embodiment of a payment type transaction, it is a unique verifiable identifier of a means of payment (we speak of means of payment VC), for example a bank card. In the latter case the VC includes for example a PAN or preferably a token of the bank card. Another example of means of payment VC is in the case of a bank debit or an account-to-account transfer, and the VC can contain an IB AN and an SCT mandate, etc. Other means of payment are just as compatible, namely a cryptocurrency account, a means of payment such as Paypal, Google Pay, Apple Pay, etc.

[0045] Alternatively 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 / recovery of hotel keys, a rental car, etc. - VC of ownership (containing proof of ownership of the property, for example a unique notarial deed identifier) ​​for the rental of an apartment - VC of ownership (containing the unique registration number) for the sale / rental of cars (particularly between individuals); - VC of medical prescription and vital card for care (containing a unique identifier of the prescription or a PAN of the vital card); - VC fiscal (containing a NIF) for aid applications.

[0046] The secondary verifiable identifier (secondary VC) is a verifiable identifier relating to said attribute of the identity of said individual (on which the criterion to be verified relates) but not necessary for the implementation of said transaction. We also speak of identity VC. We understand that (1) an identity VC is only relative to one attribute (and therefore one aspect) and not the entire identity so as to maintain maximum confidentiality on 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 said transaction unlike the main VC, i.e. the secondary VC. There is therefore a clear distinction between the main VC and the secondary VC.

[0047] There is generally a single primary VC (note that there could be several in the case of a “multi-time” or subscription transaction), and potentially a plurality of secondary VCs, in particular if there are several criteria to check.

[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 an adult or not) - Address (or even a simple Boolean indicating whether the individual lives in an expected country, municipality or community of municipalities) - Size - Nationality - Family situation / filial or marital relationship with another person - Diploma (type of diploma and / or year of award) - professional status (unemployment, work, training, etc.) - Current employer - health insurance (status, including mutual insurance, CMU, etc.) - disability (blindness, deafness, reduced mobility, etc.) - loyalty / discount card (giving access to a prize pool or special rates) - 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 the terminal 1, following prior enrollment.

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

[0051] Consequently, the method advantageously comprises a step (al) (implemented on the terminal 1 side) of selection by the individual on his terminal 1 of said main and secondary verifiable identifiers in said list of verifiable identifiers of said user. Indeed, insofar as the VCs are all relative to personal information, it is preferable that it is the individual who makes the final decision to accept to include these VCs in the first set VP1.

[0052] Note that it remains possible alternatively for terminal 1 to automatically generate VP1 by selecting the necessary VCs (thanks to the request received), or even preselect them and leave the final word to the individual. This makes it possible to operate a “one click” transaction where the user only has to validate the transaction.

[0053] Preferably, step (a1) further comprises the authentication of the individual on the terminal 1 for the transmission of the VP1, in particular by entering a PIN code or by biometric authentication, so as to achieve strong authentication (multi-factor based), which is usually based on the verification of the terminal 1 registered during an enrollment phase (possession factor, "what we possesses”), on a secret code (knowledge factor - “what we know”) and / or on the user’s biometrics (inherence factor - “who we are”). Indeed, it is preferable to ensure the individual’s consent to implement the transaction / provide the VC relating to the attributes.

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

[0055] In this respect, step (al) further comprises the signing by the data processing means 11 of the terminal 1 of said first set of verifiable identifiers VP1, before its transmission to the merchant server 2 in step (b). To reformulate further, because there has been the selection of the VCs and the authentication of the individual for the construction and signing of the VP1, the VP1 also certifies the user's consent for this transaction in the rest of the process.

[0056] Today, the processing of electronic transactions is traditionally based on complex and costly security protocols to implement. 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 them in order to be able 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 transaction processing.

[0058] In addition, 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) which makes it possible to ensure both the user's consent and the latter's authentication to validate the electronic transaction.

[0059] This poses some difficulties and complexities: - The implementation of the security protocol involves a certain number of actors with whom there are many electronic exchanges which by default generate delays in response times and operating costs. operation. - Implementing the strong authentication application for user consent requires maintaining a high level of security for this application and, above all, operating 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, constraining the times or dates authorized for transactions. - Capturing consent and strong user authentication can only be done while connected to the Internet.

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

[0061] Then, the method comprises a step (b), still 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 based on said verifiable identifier relating to said attribute of the identity of said individual.

[0062] The signature is verified in a conventional manner, 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 "major", then we will verify that one of the secondary VCs is indeed "proof of adult age", which means that we do not have to ask for the age or even the date of birth of the person, information which is not necessary and personal. We can also verify that the country of residence of a person is indeed the one necessary for the delivery of the service or product. Note that as explained, a secondary VC can ultimately be a boolean and we just verify that it is equal to true. We note that the main VC is not verified, this will in practice be the role of server 3.

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

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

[0067] This last VC, called 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, the VP2 does not contain any secondary VC: in fact, the server 3 does not need them since it is repeated that they do not contain information necessary for the transaction, and the criterion(s) have already been verified. On the other hand, the VP2 also advantageously includes said descriptive information of said transaction of the VP1 (it is noted that they are countersigned by the terminal 1, i.e. already signed by each of the terminal 1 and the merchant server 4). Note that this VP2 can contain the list of verified criteria or at least proof that the verification has been carried out. Alternatively, the VP2 may contain nothing other than said main VC and the descriptive information of the transaction.

[0069] And like what is done for VP1, said second set (VP2) is preferentially signed by the merchant server 2 (still with its private key). In this way, the 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 the server 3 verify the VP2 in a similar manner to what the server 2 did with the VP1, i.e. verification of: - said signature (that of the merchant server); - the validity of each verifiable identifier.

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

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

[0073] Then, step (e) can comprise the classic implementation of the transaction (money transfer, etc.), in other words the “processing” of the transaction, since the server 3 has all the information it needs in the VP2, and is assured of the individual's consent. If the transaction concerns a token, the 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 method comprises a step (f) of receiving from the validation server 3 a third set of verifiable identifiers (a last VP noted VP3) including at least one verifiable identifier relating to the confirmation of the transaction. Once 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 said descriptive information of said transaction of VP1 and VP2 again countersigned by the validation server 3. This allows this VP3 to certify and trace the entire transaction from the sending of the VCs by the terminal 1 to the effective implementation of the transaction via the verification of the criteria. Said descriptive information of said transaction countersigned by everyone can be kept as proof of the individual's consent.

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

[0078] Note that the VP3 can also be transmitted to terminal 1, the latter can keep it as final proof.

[0079] Server

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

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

[0082] The data processing means 21 are configured to: - Receive, from a terminal 1 of an individual at the origin of 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) including at least one unique verifiable identifier for the implementation of said transaction, called the main 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; - 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 at the origin of 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 found.

Claims

1.

2.

3. Claims 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 at the origin of said transaction, characterized in that it comprises the implementation by data processing means (21) of said merchant server (2), of steps of: a. Reception from a terminal (1) of the individual of a first set of verifiable identifiers (VP1) including at least one unique verifiable identifier for the implementation of the transaction, called the main 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 based on 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) including said main verifiable identifier and a verifiable identifier relating to said merchant. Method according to claim 1 comprises a prior step (aO) of transmitting to the terminal (1) a request for information for the implementation of said transaction, expressing said criterion to be verified. Method according to one of claims 1 and 2, in which 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 main 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. The method of claim 4, wherein step (a1) further comprises authenticating the individual on the terminal (1) so as to prove his consent to implement the transaction.

6. Method according to one of claims 1 to 5, in which said transaction is of payment type, and said main verifiable identifier represents a unique identifier of a means of payment of the individual.

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

8. Method according to one of claims 1 to 7, wherein said attribute is chosen from the following list: date of birth / age, address, height, nationality, family situation, diploma, professional status, current employer, health insurance, disability, driving license, date of obtaining driving license, loyalty card identifier, loyalty points, access rights.

9. Method according to one of claims 1 to 8, in which 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 verification of: - said signature of the second set of verifiable identifiers; - the validity of each verifiable identifier of the second set of verifiable identifiers;

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

11. Method according to claim 10, in which 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 at the origin of 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) including at least one unique verifiable identifier for the implementation of said transaction, called the main 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); - Verify: • 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 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) including said main verifiable identifier and a verifiable identifier relating to said merchant.;

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

14. Computer program product comprising code instructions for executing a method according to one of claims 1 to 11 for the implementation of 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 at the origin of said transaction, when said program is executed on a computer.

15. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 11 for the implementation of 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 at the origin of said transaction.

Images