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 the 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 the transaction, characterised in that the method comprises the implementation, by data processing means (21) of the merchant server (2), of the following steps: (b) receiving, from a terminal (1) of the individual, a first set of verifiable identifiers (VP1) including at least one unique verifiable identifier for implementing the transaction, referred to as the main verifiable identifier, and a verifiable identifier relating to the attribute of the identity of the individual but not required in order to implement the transaction, referred to as the secondary verifiable identifier, the first set being signed by the client terminal (1); (c) verifying: - the 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 the individual as a function of the verifiable identifier relating to the attribute of the identity of the individual; (d) transmitting, to a validation server (3) for validating the transaction, a second set of verifiable identifiers (VP2) including the main verifiable identifier and a verifiable identifier relating to the merchant.

Description

[0001] 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.

[0002] GENERAL TECHNICAL FIELD

[0003] 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.

[0004] STATE OF THE ART

[0005] 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.

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

[0007] For example, some products can only be purchased by adults (alcohol or cigarettes, for example), and the transaction requires verification that the individual is an adult. Similarly, if the transaction is a vehicle rental, it requires verification that the individual has a valid license. Another use case would be the use of an ATM reserved for guests of a residence or hotel.

[0008] Naturally, the user can declare on his honor that he meets the condition (for example by checking a box "I am over 18"), but a higher level of proof is desirable. 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:

[0010] - 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);

[0011] - You can no longer make a "one-click" payment, because you cannot just send the identity document with the payment information, since 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).

[0012] The present invention improves the situation.

[0013] PRESENTATION OF THE INVENTION

[0014] 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:

[0015] (b) Receiving from a terminal of the individual 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;

[0016] (c) Verification of:

[0017] - said signature of the first set of verifiable identifiers;

[0018] - the validity of each verifiable identifier of the first set of verifiable identifiers;

[0019] - 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;

[0020] (d) 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.

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

[0022] 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.

[0023] 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.

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

[0025] Step (a1) further comprises authenticating the individual on the terminal.

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

[0027] Said second set of verifiable identifiers does not include any secondary verifiable identifier of the first set of verifiable identifiers. Said attribute is chosen from the following list: date of birth / age, address, height, nationality, marital status, diploma, employment status, current employer, health insurance, disability, driver's license, date of obtaining driver's license, loyalty card identifier, loyalty points, access rights.

[0028] 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:

[0029] - said signature of the second set of verifiable identifiers;

[0030] - the validity of each verifiable identifier of the second set of verifiable identifiers;

[0031] 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.

[0032] 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.

[0033] According to a second aspect, the invention relates to a merchant server, characterized in that it comprises data processing means configured to:

[0034] - 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;

[0035] - Verify: o said signature of the first set of verifiable identifiers; o the validity of each verifiable identifier of the first set of verifiable identifiers; o 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;

[0036] - Transmit to a validation server a second set of verifiable identifiers including said primary verifiable identifier and a verifiable identifier relating to said merchant.

[0037] 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.

[0038] 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.

[0039] PRESENTATION OF THE FIGURES 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:

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

[0041] [Fig.2]Figure 2 is a flowchart illustrating the steps of an embodiment of the method according to the invention;

[0042] [Fig.3]Figure 3 illustrates the cooperation of the equipment during an embodiment of the method according to the invention.

[0043] DETAILED DESCRIPTION

[0044] Architecture

[0045] 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. 1.

[0046] 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 a PSP (payment service provider) in the case of a payment, to which the merchant has delegated the management of 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 said individual and the merchant, validated by said server 2.

[0047] 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 type transaction or a contactless payment type (via proximity wireless communication, preferably NFC or QR code, between terminal 1 and a merchant terminal 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.).

[0048] 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" purchases by purchasing tokens, and the transaction consists of using a token instead of their bank card. For example, in the same style, we can cite a transaction allowing access to a rental vehicle, a hotel room, etc. The transaction can also be the ordering of medication in exchange for a prescription / health card. We will see many examples later.

[0049] The transaction involves verifying at least one criterion relating to an attribute of the identity of an individual who initiated the transaction, which means that it is not free. In other words, the 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 correct. We will see later many possible criteria and the corresponding attributes.

[0050] 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).

[0051] 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 (smartwatch, wallet on a PC, etc.), and the merchant server 2 is typically an intermediary server called a PSP.

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

[0053] Process

[0054] 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.

[0055] 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 figure 1, 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:

[0056] - 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;

[0057] - 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;

[0058] - The merchant is the Verifier, he trusts the Issuer if a Holder presents him with a VC.

[0059] You can also refer to the page https: / / fr.wikipedia.org / wiki / ldentifiants v%C3%A9rifiables.

[0060] In the present method, we have several verifiable identifiers of various types.

[0061] The primary verifiable identifier (primary VC) is a unique verifiable identifier for the implementation of the transaction. By "unique" we mean that two individuals will necessarily have different primary VCs, and by "for the implementation of the transaction" we mean that this VC is essential. In the preferred embodiment of a payment-type transaction, this 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 direct debit or an account-to-account transfer, and the VC can contain an IBAN 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.

[0062] As an alternative to a payment method VC, we can for example have a:

[0063] - Reservation VC (containing a unique identifier of a voucher, token, etc.), e.g. for access / collection of hotel keys, rental car, etc. - Ownership VC (containing proof of ownership of the property, e.g. a unique identifier of a notarial deed) for renting an apartment

[0064] - VC of ownership (containing the unique registration number) for the sale / rental of cars (particularly between individuals);

[0065] - VC of medical prescription and vital card for care (containing a unique identifier of the prescription or a PAN of the vital card);

[0066] - VC fiscal (containing a NIF) for aid application.

[0067] 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 whole 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.

[0068] There is usually a single primary VC (note that there could be several in the case of a "multi-part" or subscription transaction), and potentially a plurality of secondary VCs, particularly if there are several criteria to verify.

[0069] In particular, secondary VCs relating to the following attributes of the identity can be used:

[0070] - Date of birth / age (or possibly a simple boolean indicating whether the individual is an adult or not)

[0071] - Address (or even a simple Boolean indicating whether the individual lives in an expected country, municipality or community of municipalities)

[0072] - Height - Nationality

[0073] - Family situation / filial or marital relationship with another person

[0074] - Diploma (type of diploma and / or year of award)

[0075] - professional status (unemployment, work, training, etc.)

[0076] - Current employer

[0077] - health insurance (status, including mutual insurance, CMU, etc.)

[0078] - disability (blindness, deafness, reduced mobility, etc.)

[0079] - loyalty / discount card (giving entitlement to a prize pool or special rates)

[0080] - Etc.

[0081] 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.

[0082] 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 includes

[0083] - Descriptive information of said transaction (type, merchant, amount, etc.);

[0084] - The list of required VCs, or at least the relevant attributes;

[0085] - Any required evidence / signatures / security elements.

[0086] Consequently, the method advantageously comprises a step (a1) (implemented on the terminal 1 side) of selection by the individual on his terminal 1 of said primary and secondary verifiable identifiers from said list of verifiable identifiers of said user. Indeed, to the extent that the VCs all relate to personal information, it is preferable that it is the individual who makes the final decision to agree to include these VCs in the first set VP1. Note that it remains possible alternatively for the 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.

[0087] 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 one possesses"), on a secret code (knowledge factor - "what one knows") and / or on the biometrics of the user (inherence factor - "who one is"). Indeed, it is preferable to ensure the consent of the individual to implement the transaction / provide the VCs relating to the attributes.

[0088] The 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).

[0089] A verifiable presentation advantageously contains several verifiable identifiers.

[0090] A verifiable presentation is a specific container of verifiable credentials. A verifiable presentation is tamper-proof and is encoded in such a way that the authorship of the data contained within the presentation can be relied upon after a cryptographic verification process.

[0091] Preferably, the VP1 also comprises said descriptive information of said transaction (retrieved from the request received in step (aO), 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 which triggers the signature and then the rest of the process).

[0092] In this respect, step (a1) 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.

[0093] Today, the processing of electronic transactions traditionally relies 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 process the transaction.

[0094] Additionally, 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.

[0095] 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 ensures both the user's consent and the latter's authentication to validate the electronic transaction.

[0096] This poses some difficulties and complexities:

[0097] - The implementation of the security protocol involves a number of actors with whom there are many electronic exchanges which generate by default delays in response times and operating costs. - The implementation of the strong authentication application for user consent involves maintaining a high level of security for this application and especially operating the authentication servers.

[0098] - 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.

[0099] - Capturing consent and strong user authentication can only be done while connected to the Internet.

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

[0101] Then, the method comprises a step (b), still implemented by the merchant server 2, of verifying:

[0102] - said signature;

[0103] - the validity of each verifiable identifier;

[0104] - 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.

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

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

[0107] 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 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.

[0108] If any of the checks are rejected, the user is potentially committing fraud with respect to the criterion (even if the payment information is correct).

[0109] Finally, the method comprises a step (d) still 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.

[0110] 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.

[0111] 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 may 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.

[0112] And similar to 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. 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:

[0113] - said signature (that of the merchant server);

[0114] - the validity of each verifiable identifier.

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

[0116] Note that server 3 has no way 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 individual's privacy.

[0117] Then, 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 concerns a token, server 3 can, for example, implement the transaction by verifying the authenticity of the token and destroying it.

[0118] 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 preferentially signed by the validation server 3 (still with its private key).

[0119] The 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.

[0120] VP3 may contain said descriptive information of said transaction from 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, including the verification of the criteria. Said descriptive information of said transaction countersigned by everyone may be kept as proof of the individual's consent.

[0121] Step (f) then includes, following this receipt 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.

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

[0123] Server

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

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

[0126] The data processing means 21 are configured to:

[0127] - 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;

[0128] - Verify: o said signature of the first set of verifiable identifiers; o the validity of each verifiable identifier of the first set of verifiable identifiers; o 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;

[0129] - 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.

[0130] 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.

[0131] Computer program product

[0132] 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

CLAIMS 1. 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: (b) Receiving from a terminal (1) of the individual a first set of verifiable identifiers (VP1), which is a verifiable presentation, 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); (c) 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; (d) 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. 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.

3. Method according to one of claims 1 and 2, in which said primary and secondary verifiable identifiers are chosen from a list 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 (a1) 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. Method according to 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, in which 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 implemented by data processing means (31) of the validation server (3) of said transaction, 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), which is a verifiable presentation, 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: o said signature of the first set of verifiable identifiers; o the validity of each verifiable identifier of the first set of verifiable identifiers; o 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 transaction validation server (3), 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. Assembly of the merchant server (2) according to claim 12 and at least one terminal (1).

14. 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, 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