Method and device for providing an attribute of a certified digital identity of a correspondent in an electronic communication.

Abstract

The invention relates to a method for providing at least one attribute of at least one certified digital identity of a correspondent in an electronic communication established or being established between at least one terminal of a first user and a second terminal of a second user, said method being implemented by a provisioning device and characterized in that the method comprises: a first step of obtaining a request for at least one attribute of at least one certified digital identity of said first user, said request being received from a communication module of said second terminal; a second step of obtaining said at least one attribute from a digital identity wallet; a third step of sending said at least one attribute to said communication module. Figure 1

Description

Title of the invention: Method and device for providing an attribute of a certified digital identity of a correspondent in an electronic communication.

[0001] 1. Scope of the invention

[0002] The invention relates to the field of telecommunications and more particularly to a method which makes it possible, during a communication, to verify the identity of the correspondent.

[0003] 2. Prior Art

[0004] Users of telecommunications services (telephone, videophone, SMS, RCS, instant messaging, email, etc.) are receiving an increasing number of unsolicited electronic communications, leading to numerous inconveniences. This is the case, for example, when they receive calls made during phishing campaigns.

[0005] We are thus observing an increase in telephone calls from fraudsters who incite their interlocutors to validate, to their detriment (for example, on their mobile device), banking transactions and / or access authorizations to their account (in the context of Payment Services Directive No. 2). During these malicious calls, the fraudster spoofs the caller's bank number in order to create the impression of a bank advisor. To do this, fraudsters may, for example, declare the bank's telephone number in the SIP FROM header of the SIP (Session Initiation Protocol) protocol used to establish the telephone connection.

[0006] Once communication is established, fraudsters use social engineering strategies (exploitation of personal data, building trust, emergency situation, unusual and / or off-peak hours...) in order, for example, to convince the caller to validate banking transactions by strong authentication.

[0007] Solutions exist to combat such activities. They are primarily based on mechanisms of so-called DNO (Do Not Original) lists, which compile the numbers of an organization / company that are never used for outgoing calls. This allows the caller's or recipient's operator to "block" a call that supposedly originates from such a number. This is a very partial solution, limited to verifying the authenticity of a few numbers held by the spoofed organization.

[0008] Another solution is to use the STIR / SHAKEN mechanisms associated with the SIP protocol, which aim to certify the caller ID by means of a certificate (signed by a cryptographic key mechanism) issued by a Trusted authority. However, this method is not robust enough to withstand certain international interconnections or changes in signaling protocols along the call path (e.g., SS7 / SIP). Therefore, its effective implementation for all calls remains a challenge at present.

[0009] There is therefore a need for a more reliable solution that allows one to know with certainty the identity of one's correspondent.

[0010] 3. Description of the invention

[0011] The invention improves upon the prior art and proposes a method for providing at least one attribute of at least one certified digital identity of a correspondent in an electronic communication established or being established between at least a first terminal of a first user and a second terminal of a second user, said method being implemented by a supply device and characterized in that the method comprises: - a first step of obtaining, a request for at least one attribute of at least one certified digital identity of said first user, said request being received from a communication module of said second terminal; - a second step of obtaining, from a digital identity portfolio, said at least one attribute; - a third emission step, to said communication module, of said at least one attribute.

[0012] Advantageously, according to the invention, a communication established between a sending terminal and a receiving terminal can be determined as fraudulent by the called party, i.e., issued by a malicious caller, when, for example, all or part of a certified identity of the caller received by the called party (the attribute or attributes within the meaning of the invention) is not in accordance with an uncertified identity of the caller presented to the called party at the time of the establishment of the communication (for example via a service allowing the presentation of the caller's number to the called party) or when all or part of a certified identity of the caller received is not known to the called party.

[0013] The invention also allows a caller to verify the identity of the called party when, for example, all or part of a certified identity of the called party received by the caller (the attribute or attributes within the meaning of the invention) does not match an uncertified identity of the called party, for example the telephone number of the called party, used when establishing the communication (case of a change of telephone number).

[0014] Thus, the process can advantageously be carried out in connection with the terminal of the called party or with the terminal of the caller.

[0015] In concrete terms, the method obtains a request for one or more attributes of a certified digital identity of a first correspondent / user. The request is issued by a second correspondent / user, and more specifically by a communication module of their terminal (the second terminal within the meaning of the invention), with the first and second correspondents involved in the same electronic communication. The method then obtains the requested certified identity attribute(s) from a digital identity wallet of the first correspondent. Once the attribute(s) are obtained, the method sends them to the second terminal and the second correspondent. Thus, the second correspondent can, for example, in the case of a call presentation, answer or decline the call depending on the value of the certified identity attribute(s) of the first correspondent received.

[0016] Note that the process can be performed by a supply device integrated into or connected to the second terminal. Alternatively, the process can be performed by a supply device integrated into or connected to the first terminal. Alternatively, the process can be distributed among several terminals and / or servers such as the first and second terminals.

[0017] A certified identity attribute is defined as one or more values ​​associated with an element / field of a digital identity document issued by a certified body such as a state or a company. An attribute may, for example, correspond to a surname, a first name, a position within a company, a location, etc.

[0018] Electronic communication is defined as communication in which information is transmitted using signals produced by electronic equipment. Examples of electronic communication include telephone calls, SMS, MMS, video conferencing, messaging, instant messaging, etc.

[0019] Note that electronic communication may involve a plurality of correspondents.

[0020] A communication module is understood to be a hardware or software module enabling communication with a third-party device.

[0021] A digital identity wallet is understood to mean software and / or hardware capable of securely managing and storing identity documents and official documents (for example, certified by a state or a company) in digital format.

[0022] According to a particular embodiment of the invention, a method as described above is characterized in that said request is included in or corresponds to a message of a signaling protocol enabling the establishment and maintenance of said electronic communication and in that the emission of said at least one attribute is carried out via said protocol.

[0023] This embodiment makes it possible to use the signaling protocol (for example SIP or H323) implemented during the establishment of the electronic communication between the first and second terminal to obtain a request for an attribute of a certified digital identity and to issue to the requester the attributes obtained from a digital identity portfolio.

[0024] According to a particular embodiment of the invention, a method as described above is characterized in that said first obtaining step is preceded by a first emission step, to said second terminal, of a message indicating that said first terminal is capable of providing said at least one attribute.

[0025] This embodiment allows the first terminal to declare to the second terminal, and more specifically to the second user, that the latter is capable of providing one or more attributes of an identity of the first user. In other words, that the first terminal possesses a wallet containing one or more digital identities of the first user. Thus, the second terminal can then, for example at the request of the second user, send a request to the first terminal for one or more attributes of a certified digital identity of the first user with the certainty that the request will be successful.

[0026] In the case of a telephone communication, the message sent by the first terminal indicating its ability to provide one or more attributes of a certified digital identity may, for example, be a SIP (Session Initiation Protocol) INVITE or UPDATE signaling message including a specific parameter indicating said ability (hereafter referred to as the offer parameter). The message or offer parameter may further include an email address of a software and / or hardware proxy capable of interacting with the first user's digital identity wallet.

[0027] Alternatively, the message emitted by the first terminal indicating its ability to provide one or more attributes of a certified digital identity may correspond to a specific message. In this case, the message may not include an offer parameter, and the information indicating the first terminal's ability to provide one or more attributes of a certified digital identity is then conveyed by the message itself.

[0028] According to a particular embodiment of the invention, a process as described above is characterized in that said first emission step is conditioned on the result of a validation of said first user at the level of a human-machine interface of said first terminal.

[0029] This embodiment makes it possible to offer the first user, via a human-machine interface rendered by their terminal (first terminal within the meaning of the invention), an option to condition the sending of a message indicating that said The first terminal is capable of providing at least one of these attributes as a result of validation by the first user. This option could, for example, take the form of a button in a graphical interface offering to send the message to the second terminal / second user.

[0030] According to a particular embodiment of the invention, a method as described above is characterized in that said first transmission step is preceded by a first reception step of an identification request of said first user issued by said second terminal.

[0031] This embodiment allows the second terminal and more particularly the second user to ensure that the first terminal is capable of providing one or more attributes of a certified digital identity of the first user.

[0032] In the case of a telephone communication, the identification request issued by the second terminal to the first terminal may, for example, correspond to a SIP (Session Initiation Protocol) INVITE or UPDATE signaling message including a particular parameter indicating the object of the request (i.e. the identification of the first user via one or more attributes of a certified digital identity of the first user).

[0033] Alternatively, the identification request may correspond to a specific message. In this case, the message may not include any parameters. The information indicating the nature of the request is conveyed by the message itself.

[0034] According to a particular embodiment of the invention, a process as described above is characterized in that said first reception step is conditioned on the result of a validation of said second user at the level of a human-machine interface of said second terminal.

[0035] This embodiment allows the second user, via a human-machine interface displayed on their terminal (second terminal as defined in the invention), to be offered an option to condition the sending of an identification request to the first user upon the result of a validation by the second user. This option could, for example, take the form of a button in a graphical interface that allows the message to be sent to the first terminal / first user.

[0036] According to a particular embodiment of the invention, a method as described above is characterized in that said request includes a request to execute a cryptographic challenge and in that said second obtaining step includes: - a second step of issuing said request to said digital identity wallet; - a second reception step, depending on the result of the execution of said cryptographic challenge, of said at least one attribute.

[0037] This embodiment allows for certification of received identity attributes by the first user. Specifically, a request to execute a cryptographic challenge is issued to the identity wallet along with the attribute request. The cryptographic challenge could, for example, be a username / password type challenge. Thus, before providing the requested identity attributes, the identity wallet requires the first user to validate their provision to the second terminal / user and also to solve the cryptographic challenge. If the first user validates the provision of the identity attributes and solves the cryptographic challenge, then the attributes obtained from the identity wallet are considered certified by the first user.Furthermore, the first user thereby provides their consent to supply this information and validates that they are indeed the holder of the identity portfolio and therefore of the issued attributes.

[0038] According to a particular embodiment of the invention, a method as described above is characterized in that said demand is encrypted.

[0039] This embodiment secures the exchanges between the digital identity wallet and the requester (i.e., the second terminal). Note that the encryption of the attribute request can, for example, be performed using a symmetric or asymmetric encryption method.

[0040] Note that the various modes or embodiments mentioned above can be added independently or in combination with each other to the supply process defined above.

[0041] The invention also relates to a device for providing at least one attribute of at least one certified digital identity of a correspondent in an electronic communication established or being established between at least a first terminal of a first user and a second terminal of a second user, said device being characterized in that it comprises: - a first module for obtaining, a request for at least one attribute of at least one certified digital identity of said first user, said request being received from a communication module of said second terminal; - a second module for obtaining, from a digital identity portfolio, said at least one attribute; - a third transmission module, intended for said communication module, of said at least one attribute.

[0042] The term module can refer to a software component, a hardware component, or a set of hardware and software components; a software component itself corresponding to one or more computer programs or subprograms, or more generally to any element of a program capable of implementing a function or set of functions as described for the modules concerned. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).

[0043] The invention also relates to a terminal comprising a supply device as described above.

[0044] The invention also relates to a computer program comprising instructions for implementing the above method according to any one of the particular embodiments described above, when said program is executed by a processor. The method can be implemented in various ways, including in hardwired or software form. This program can use any programming language and be in the form of source code, object code, or code intermediate between source and object code, such as in a partially compiled form, or in any other desirable form.

[0045] The invention also relates to a computer-readable recording or information medium containing instructions for a computer program as described above. The aforementioned recording media can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive. Furthermore, the recording media may be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The programs according to the invention can, in particular, be downloaded from a network such as the Internet.

[0046] Alternatively, the recording media may correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0047] This supply device and computer program have characteristics and advantages similar to those described previously in relation to the supply method.

[0048] 4. List of figures

[0049] Other features and advantages of the invention will become more apparent upon reading the following description of particular embodiments, given by way of simple illustrative and non-limiting examples, and the accompanying drawings, among which:

[0050] [Fig-1] Fig. 1 illustrates an example of an implementation environment according to a a particular embodiment of the invention,

[0051] [Fig.2] Fig.2 illustrates the hardware architecture of a device configured to implement the supply process according to a particular embodiment of the invention,

[0052] [Fig.3] Fig.3 illustrates steps in the supply process according to a first particular embodiment of the invention.

[0053] [Fig.4] Fig.4 illustrates steps in the supply process according to a second particular embodiment of the invention.

[0054] 5. Description of an embodiment of the invention

[0055] Figure 1 illustrates an example of an implementation environment for the invention according to a particular embodiment of the invention. The implementation environment comprises a first terminal 101 of a user U1 connected to a telecommunications network 100, adapted to establish or receive communications with a second terminal 105 of a user U2 connected to a telecommunications network 103 according to the prior art. The terminals 101 and 105 are, for example, mobile terminals, fixed terminals, connected objects, voice assistants, or any other terminal capable of establishing and receiving communications.

[0056] Telecommunications networks 100 and 103 are respectively operated by the telecommunications operators of users U1 and U2.

[0057] Servers 102 and 104 are application servers located respectively in telecommunications networks 100 and 103 capable of relaying and supporting communication between terminals 101 and 105.

[0058] It should be noted that the environment described in support of [Fig. 1] consists of two telecommunications networks. However, in a particular embodiment of the invention, networks 100 and 103 may be a single telecommunications network operated by a single telecommunications operator. Furthermore, the environment may include more than two telecommunications networks and, for example, a third interconnection network enabling communication between networks 100 and 103.

[0059] Figure 2 illustrates the hardware architecture of a DISP device configured to implement the supply method according to a particular embodiment of the invention. In the embodiment described herein, this device has the hardware architecture of a mobile terminal. It includes, in particular, a PROC processor, a RAM MV, a ROM MEM, and a non-volatile flash memory MF. Such components are known per se and are not described in further detail here. The ROM constitutes a storage medium according to the invention, readable by the PROC processor, on which a computer program PG according to the invention is stored. This program comprises instructions for implementing the steps of the supply method as described above, when the The program is executed by the PROC processor. At initialization, the code instructions of the computer program PG are, for example, loaded into memory before being executed by the PROC processor. The PROC processor of the processing unit UT implements, in particular, the steps of the supply process according to any of the specific embodiments described in relation to Figures 1, 3, and 4, according to the instructions of the computer program PG.

[0060] The DISP device also includes a first OBT1 acquisition module capable of obtaining signaling messages from a communication via, for example, an IP network. The OBT1 acquisition module is used, for example, to obtain, from a terminal, for example terminal 105 or terminal 101, a request for at least one attribute of at least one certified digital identity of the user U1.

[0061] The DISP device also includes a second OBT2 acquisition module capable of obtaining from a digital identity portfolio one or more attributes of at least one certified digital identity of the user U1.

[0062] According to a particular embodiment of the invention, the DISP device may include one or more digital identity wallets (WALL1) of the user U1.

[0063] The DISP device further includes an SND transmission module capable of transmitting to the device / terminal which issued the request received by the OBT1 acquisition module, one or more attributes of at least one certified digital identity of the user U1.

[0064] Figure 3 illustrates steps in the supply process according to a particular embodiment of the invention. Figure 3 uses the same environment as that described in support of Figure 1.

[0065] In a first step E10, user U1 initiates communication with user U2. More specifically, terminal 101 of user U1 sends a SIP INVITE message to an identifier of user U2. The identifier is, for example, a telephone number (MSISDN), an email address, or any other identifier that allows U2 to be contacted. The SIP INVITE message sent by terminal 101 to an identifier of user U2 is, as is known, a message initiating communication with user U2. An identity of user U1, referred to as an uncertified identity, is included in the call signaling, in the FROM field present in the header of the SIP INVITE message. The uncertified identity of user U1 is an identity declared by the user and / or terminal 101 such as an MSISDN, an email address, an IP address or any other string of characters and / or binary data.

[0066] It is noted that, in a known manner, the various pieces of information placed in the headers of the SIP INVITE message belong to or constitute the call signaling.

[0067] Note that the signaling protocol used to initiate and establish communication can also be H.323, MGCP, ISUP (ISDN Signalling User Part), BICC (Bearer Independent Call Control), SIP-I (Session Initiation Protocol - ISUP), WebRTC (Web Real Time Communication), or any other signaling protocol (for example, proprietary) capable of initiating / establishing communication. In the remainder of this description, the signaling messages exchanged between terminals 101 and 105 will be SIP messages.

[0068] Once the SIP INVITE message is sent by terminal 101, it is received and then taken care of by server 102 of telecommunications network 100. Upon receipt of the SIP INVITE message, server 102 can modify the signaling of the message, for example the SIP P-Asserted-Id field and / or modify the uncertified identity already present.

[0069] Note that the 102 server can also modify other fields of the SIP INVITE message signaling such as the SIP PRIVACY field in the case where the caller (Ul) has subscribed with his telecommunications operator to a service of the type OIR (Originating Identification Restriction) allowing the masking of his identity during a communication.

[0070] The SIP INVITE message is then sent to server 104 located within the telecommunications network 103 of user U2's telecommunications operator. Upon receiving the SIP INVITE message, server 104 can modify the signaling of the SIP INVITE message, for example, by modifying the SIP DISPLAY parameter of the FROM field in the SIP INVITE message. Once processed by server 104, the SIP INVITE message is then sent to terminal 105.

[0071] At step E40, the terminal receives and processes the SIP INVITE message and then returns to user U2, for example graphically or audibly, a caller ID contained in the SIP INVITE message, i.e., an ID of user UL.

[0072] As is known and following what has been described previously, the terminal can return different IDs depending on its configuration, the configuration of the called party's (U2) network, and / or the services subscribed to by users UL and U2 with their telecommunications operator. Thus, terminal 105 can return to user U2 a fictitious ID (for example, one provided by a hacker), an erroneous ID, or an altered ID (for example, one created by a malfunctioning network server). The ID presented can also be a so-called "technical" ID, such as a string of characters like a prefix or a predefined telephone number, associated with a telecommunications service.

[0073] For all these reasons, it can be reassuring for the called party to know / obtain with certainty all or part of the attributes of a certified identity of their correspondent, independently of that declared orally or electronically. Thus, depending on the certified identity attribute(s) obtained, the called party can decide whether or not to proceed with establishing the communication or with the communication itself.

[0074] Communication initialization then continues during step E41 when terminal 105 responds to the SIP INVITE message received via a SIP 180 Ringing message. The SIP 180 Ringing message is then received by terminal 101 during step Eli.

[0075] In a first scenario, we will assume that the user terminal U1 (101) is capable of providing one or more attributes of a certified identity of the user Ul. More precisely, that terminal 101 executes, at the request of the user Ul or not, the provisioning process according to the invention in order to offer the called party (U2) the opportunity to obtain and verify all or part of a certified identity of the caller (Ul) before the communication begins. We will also assume that the exchanges enabling the implementation of the provisioning process according to the invention will be carried out using the SIP signaling protocol. Alternatively, the exchanges enabling the implementation of the provisioning process according to the invention may be carried out using a proprietary protocol.

[0076] Alternatively, the supply method according to the invention is carried out by terminal 105 or a server (not shown).

[0077] Alternatively, the supply method according to the invention is carried out in a distributed manner between several terminals and / or servers including, for example, all or part of terminals 101 and 105 and servers 102 and 104.

[0078] During step E10, terminal 101 declares to terminal 105, and more specifically to user U2, that it is capable of providing one or more attributes of a certified identity of user U1, that is, that it possesses a wallet containing one or more certified digital identities of user U1. To do this, terminal 101 of user U1, more specifically its DIALL1 communication software, can modify the SIP INVITE message sent during step E10 to include a parameter (hereafter referred to as the offer parameter) allowing terminal 101 to declare its ability to provide all or part of a certified identity of user U1.

[0079] According to a particular embodiment, in addition to the offer parameter, the SIP INVITE message may include an email address of a software and / or hardware proxy (STUB1) capable of interacting with the certified digital identity portfolio (WALL1) of the UL user. Note that the proxy's email address may be obtained beforehand from the proxy itself or pre-provisioned within the DIALL1 communication software.

[0080] Alternatively or cumulatively, the offer parameter is included in or corresponds to a message exchanged during the communication established between terminals 101 and 105, for example, via a proprietary IP message or a SIP UPDATE signaling message.

[0081] According to a particular embodiment, the transmission of the offer parameter by terminal 101 is previously validated via a human-machine interface of terminal 101 by the user Ul. This human-machine interface can, for example, take the form of a component of a graphical interface (button, checkbox, etc.) rendered on the screen of terminal 101 by the DIALL1 communication software.

[0082] During step E40, terminal 105 receives the SIP INVITE signaling message and the offer parameter. Terminal 105 (for example, the DIALL2 communication software) then sends (E42) a request for one or more attributes of a certified identity of user U1 to terminal 101.

[0083] According to a particular embodiment, the sending of the request for one or more attributes of a certified identity of the user U1 by the terminal 105 (E42) can be conditioned on the result of a validation request returned to the user U2 via a human-machine interface of his terminal 105. This human-machine interface can for example take the form of a component of a graphical interface (button, checkbox, etc.) returned at the level of the screen of the terminal 105 by the DIALL2 communication software.

[0084] Note that user U2 can also, prior to terminal 105 sending the request for one or more attributes of a certified identity of user Ul (E42), specify / choose the desired identity attribute(s) of user U1. This choice can, for example, be made via a human-machine interface (graphical or voice) of terminal 105.

[0085] The request for one or more attributes of a certified identity of the user U1 is then received by the proxy STUB1 during step E32. In the case described in support of [Fig.3], this request is received by a server (for example server 102 or server 104) capable of executing the application logic of the proxy STUB1.

[0086] Alternatively, the STUB1 proxy is executed by terminal 105 or terminal 101.

[0087] Alternatively, the request is received by the DIALL1 communication software run by terminal 101.

[0088] According to a particular embodiment, the DIALL1 communication software and the STUB1 agent are one and the same entity.

[0089] Once the attribute request is received from terminal 105, the proxy STUB1 retransmits it (E33) to the WALL1 certified digital identity wallet of user UL

[0090] According to a particular embodiment, the WALL1 certified digital identity wallet is included in or associated with terminal 101. The certified digital identity wallet can, for example, be included in a secure element (SIM card for Subscriber Identity / Identification Module, eSIM for embedded SIM, iSIM for integrated SIM, TEE for Trusted Execution Environment, etc.) connected or integrated with terminal 101.

[0091] According to a particular embodiment, the attribute request may include a request to execute a cryptographic challenge.

[0092] The identity wallet WALL1 receives the attribute request during step E23. In step E24, the identity wallet WALL1 executes the cryptographic challenge when it is included in the attribute request. The cryptographic challenge is, for example, a username / password challenge returned to user U1 via a human-machine interface of terminal 101. This embodiment allows user U2 to verify that it is indeed the holder of the identity wallet WALL1, i.e., user Ul, who is the originator of the issuance of the identity attributes of user UL.

[0093] Alternatively or cumulatively, the WALL1 identity wallet returns to user U1, via a human-machine interface of terminal 101, the list of requested identity attributes (i.e., the label of the requested attribute(s) included in the attribute request received during step E23). This embodiment allows user U1 to review the requested identity attributes and, if necessary, validate their submission in whole or in part.

[0094] During step E24, the identity wallet WALL1 retrieves an identity of the user U1 (for example from memory or an internal database) and then issues the requested identity attributes of the user Ul to the proxy STUB1.

[0095] According to a particular embodiment, the execution of this step E24 can be conditioned on the result of the cryptographic challenge solved by the user UL

[0096] According to a particular embodiment, the execution of this step E24 can be conditioned on the result of the validation by user U1 of the emission of the requested identity attributes to terminal 105.

[0097] According to a particular embodiment, the exchanges between the identity wallet WALL1 and the proxy STUB1 are encrypted. Note that the encryption can be implemented using a symmetric or asymmetric encryption algorithm, depending on the state of the art.

[0098] At step E34 the identity attributes are received by the agent STUB1 and then re-transmitted (E35) to terminal 105 and more particularly to its communication software DIALL2.

[0099] Once the identity attributes of user U1 are received, terminal 105 can present them (for example, graphically or audibly) to user U2 via a human-machine interface. Thus, the user can choose whether or not to answer the call based on the identity attributes of user U1 received. If the user wishes to answer the call, terminal 105 sends (E46, E16) a SIP 200 OK message to terminal 101 and then receives (E17, E47) a SIP ACK message from terminal 101 indicating that the RTP session, and therefore the communication, will begin.

[0100] Advantageously, this scenario allows the caller to offer the called party, at the time of call setup and before the communication is effective (i.e. before the called party accepts the communication), the opportunity for the called party to obtain and verify a certified identity of the caller.

[0101] In a second scenario we will assume that the called party, i.e. user U2, wishes to explicitly request the caller's terminal 101 (Ul) to obtain, for verification, all or part of a certified identity of the caller (Ul) before the communication begins.

[0102] The process and the advantages remain identical to those set out for the first case except for the adaptations described below.

[0103] In this second scenario, the SIP INVITE message sent during step E10 corresponds to a standard SIP INVITE message according to the state of the art (i.e., a message that does not include an offer parameter). It is received by terminal 105 and more specifically by the DIALL2 communication software during step E40. During step E41, terminal 105 responds with a SIP 180 RINGING message according to the state of the art.

[0104] During step E40_l, terminal 105, whether or not requested by user Ul, sends a SIP UPDATE message that includes a request for user UL identification. The request is, for example, represented by a specific parameter included in the SIP UPDATE message. During step E10_l, the SIP UPDATE message is received by terminal 101, and more specifically by the DIALL1 communication software. When DIALL1 detects the presence of the identification request and is able to respond favorably to the request, it sends a SIP UPDATE message during step E11_l. This message includes an offer parameter that declares terminal 101's ability to provide all or part of a certified identity for user UL II. This message is then received by terminal 105 during step E41_l.

[0105] According to a particular embodiment, in addition to the offer parameter, the SIP UPDATE message may include an email address of the software and / or hardware proxy (STUB1) capable of interacting with the UL user's certified digital identity wallet (WALL1). Note that the proxy's email address may to be obtained by the DIALL1 communication software prior to step El 1_1 from the agent himself or pre-provisioned within him.

[0106] The rest of the process remains identical to that described for the first scenario.

[0107] Figure 4 illustrates steps in the supply process according to another particular method. of implementation of the invention. [Fig.4] uses the same environment as that described in support of [Fig.1].

[0108] During a first step E400, user U1 initiates communication with user U2. More specifically, terminal 101 of user U1 sends a SIP INVITE message to terminal 105. The SIP INVITE message sent during step E400 is modified to include a request for user U2's identification. The request is, for example, implemented by a specific parameter included in the SIP INVITE message.

[0109] During step E100, the SIP INVITE message is received by terminal 105 and more specifically by the DIALL2 communication software. When the latter detects the presence of the identification request and is able to respond favorably to the request, it sends during step E100 a SIP 180 Ringing message including an offer parameter allowing the terminal 105 to declare the ability to provide all or part of a certified identity of user U2.

[0110] Alternatively, the offer parameter is included in a SIP UPDATE message issued after the SIP 180 Ringing message.

[0111] According to a particular embodiment, in addition to the offer parameter, the SIP 180 Ringing or SIP UPDATE message may include an email address of a software and / or hardware proxy (STUB2) capable of interacting with the certified digital identity wallet (WALL2) of the user U2. Note that the email address of the STUB2 proxy may be obtained beforehand from the proxy itself or pre-provisioned within the DIALL2 communication software.

[0112] According to a particular embodiment, the emission by terminal 105 of the offer parameter is previously validated by the user U2 via a human-machine interface of terminal 105. This human-machine interface can for example take the form of a component of a graphical interface (button, checkbox, etc.) rendered at the level of the screen of terminal 105 by the DIALL2 communication software.

[0113] During step E410, terminal 101 receives the SIP 180 Ringing signaling message and the offer parameter. Terminal 101 (for example, the DIALL1 communication software) then sends (E420) a request for one or more attributes of a certified identity of user U1 to terminal 105.

[0114] According to a particular embodiment, the issuance of a request for one or more attributes of a certified identity of user U2 by terminal 101 (E420) may be conditioned by the result of a validation request returned to the user U1 via a human-machine interface of his terminal 101. This human-machine interface can for example take the form of a component of a graphical interface (button, checkbox, etc.) returned at the level of the screen of terminal 101 by the communication software DIALL1.

[0115] Note that user U1 can also, prior to terminal 101 sending the request for one or more attributes of a certified identity of user U2 (E420), specify the desired identity attribute(s) of user U2. This choice can, for example, be made via a human-machine interface (graphical or voice) of terminal 101.

[0116] The request for one or more attributes of a certified identity of the user U2 is then received by the proxy STUB2 during step E320. In the case described in support of [Fig.4], this request is received by a server (for example server 102 or server 104) capable of executing the application logic of the proxy STUB2.

[0117] Alternatively, the STUB2 proxy is executed by terminal 101 or terminal 105.

[0118] Alternatively, the request is received by the DIALL2 communication software run by terminal 105.

[0119] According to a particular embodiment, the DIALL2 communication software and the STUB2 agent are one and the same entity.

[0120] Once the attribute request is received from terminal 101, the STUB2 proxy re-sends it (E330) to the WALL2 certified digital identity wallet of user U2.

[0121] According to a particular embodiment, the WALL2 certified digital identity wallet is included in or associated with terminal 101. The certified digital identity wallet can, for example, be included in a secure element (SIM card for Subscriber Identity / Identification Module, eSIM for embedded SIM, iSIM for integrated SIM, TEE for Trusted Execution Environment, etc.) connected or integrated with terminal 101.

[0122] According to a particular embodiment, the attribute request may include a request to execute a cryptographic challenge.

[0123] The WALL2 identity wallet receives the attribute request at step E230. At step E240, the WALL2 identity wallet executes the cryptographic challenge when it is included in the attribute request. The cryptographic challenge is, for example, a username / password challenge returned to user U2 via a human-machine interface of terminal 105. This embodiment allows user U1 to verify that they are indeed the identity wallet holder. WALL2, that is, user U2, who is at the origin of the emission of the identity attributes of user U2.

[0124] Alternatively or cumulatively, the WALL2 identity wallet returns to user U2, via a human-machine interface of terminal 105, the list of requested identity attributes (i.e., the label of the requested attribute(s) included in the attribute request received during step E230). This embodiment allows user U2 to review the requested identity attributes and, if necessary, validate their partial or complete submission.

[0125] During step E240, the identity wallet WALL2 retrieves an identity of user U2 (for example from memory or an internal database) and then issues the requested identity attributes of user U2 to the proxy STUB2.

[0126] According to a particular embodiment, the execution of this step E240 can be conditioned on the result of the cryptographic challenge solved by user U2.

[0127] According to a particular embodiment, the execution of this step E240 can be conditioned on the result of the validation by user U2 of the emission of the requested identity attributes to terminal 101.

[0128] According to a particular embodiment, the exchanges between the WALL2 identity wallet and the STUB2 proxy are encrypted. Note that the encryption can be implemented using a symmetric or asymmetric encryption algorithm, depending on the state of the art.

[0129] At step E340 the identity attributes are received by the agent STUB2 and then re-sent (E350) to terminal 101 and more particularly to its communication software DIALL1 (received during step E450).

[0130] Once the identity attributes of user U2 are received, terminal 101 can present them (for example, graphically or audibly) to user U1 via a human-machine interface. Then, terminal 101 sends (E460, E160) a SIP 200 OK message to terminal 105 and then receives (E170, E470) a SIP ACK message from terminal 105 indicating that the RTP session, and therefore the communication, will begin.

Claims

[Claim 1] Demands Computer program comprising instructions for implementing the steps of a method for providing at least one attribute of at least one certified digital identity of a correspondent of an electronic communication established or being established between at least a first terminal (101) of a first user (U1) and a second terminal (105) of a second user (U2) when said program is executed by a processor, said method comprising the following steps: - a first step of obtaining (E32) a request for at least one attribute of at least one certified digital identity of said first user, said request being received from a communication module of said second terminal; - a second step of obtaining (E34), from a digital identity portfolio (WALL1), said at least one attribute; - a third emission stage (E35), to said communication module, of said at least one attribute.

Images