An identity information acquisition method, an operation service end and a system

Abstract

The embodiment of the present disclosure discloses an identity information acquisition method, an operation service end and a system. The method comprises the following steps: a digital currency system generates a pull parameter acquisition request; the digital currency system sends the pull parameter acquisition request to an operation service end associated with a user wallet, so that the operation service end generates a ticket identifier acquisition message, and acquires a ticket identifier from an identity authentication service end based on the ticket identifier acquisition message; the digital currency system acquires an authorization code from the identity authentication service end according to a pull parameter response; the operation service end sends an encrypted access token acquisition request and an encrypted identity information acquisition request to the identity authentication service end, so that the identity authentication service end returns identity information of the user wallet according to a to-be-acquired identity information list. The embodiment of the present disclosure uses the mechanism of "authorization code" and "access token", effectively acquires user identity information, and guarantees the safe and stable operation of the digital currency system.

Description

Technical Field

[0001] This disclosure relates to a method for obtaining identity information, an operating server, a system, an electronic device, and a readable medium. Background Technology

[0002] In the widespread application and promotion of digital currencies, identity verification plays a crucial role. Digital currency transactions involve the transfer of large sums of money and the exchange of value, and accurate and reliable identity verification is the cornerstone of ensuring transaction security and preventing financial risks. Through accurate and efficient identity verification, the identity of each entity participating in digital currency transactions can be clearly identified, ensuring the legality and traceability of transactions, thereby maintaining the healthy order of the entire digital currency ecosystem.

[0003] Therefore, identity verification is crucial for digital currency systems in practical applications. However, current technologies face difficulties in efficiently verifying the identities of users outside the operating area. Different countries and regions have their own unique identity recognition systems, varying greatly in document types, formats, and information recording methods. Furthermore, due to the lack of unified international identity verification standards and effective cross-border data sharing mechanisms, it is difficult to find a clear identity verification path when a digital currency system needs to verify the identity of other residents. For example, when conducting digital currency transactions with residents of certain countries or regions, the system struggles to obtain their true and valid identity information for verification. This provides opportunities for criminals to exploit identity vulnerabilities for illegal transactions, seriously threatening the security and stability of the digital currency system.

[0004] One possible approach is to establish a trusted identity verification server for users outside the operating area through the digital currency system. However, due to the two-tier operating system of the digital currency system, directly establishing an identity verification server can be achieved by either having the operating server hold the key or by having the digital currency system transmit information. However, having different operating server keys will pose significant security risks, while the information transmission method is very cumbersome and inefficient. Summary of the Invention

[0005] This disclosure provides an identity information acquisition method, an operation server, a system, an electronic device, and a readable medium, which can achieve secure and efficient acquisition of identity information under a two-tier digital currency operation system.

[0006] To achieve the above technical objectives, the embodiments of this disclosure adopt the following technical solutions:

[0007] In a first aspect, embodiments of this disclosure provide a method for obtaining identity information, the method comprising:

[0008] The digital currency system generates a pull-up parameter retrieval request, which includes a user wallet identifier to indicate the user wallet whose identity information is to be retrieved.

[0009] The digital currency system sends a pull-up parameter acquisition request to the operation server associated with the user's wallet, so that the operation server generates a ticket identifier acquisition message, and obtains the ticket identifier from the identity verification server based on the ticket identifier acquisition message, and associates the user's wallet identifier with the ticket identifier. The ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired.

[0010] The digital currency system receives a pull-up parameter response generated by the operation server based on the bill identifier, and obtains an authorization code from the identity verification server based on the pull-up parameter response;

[0011] Upon receiving the authorization code from the digital currency system, the operations server sends an encrypted access token acquisition request to the identity verification server and receives the access token and tokenized identity identifier returned by the identity verification server.

[0012] The operations server sends an encrypted identity information retrieval request to the identity verification server, so that the identity verification server can return the user's wallet identity information based on the list of identity information to be retrieved.

[0013] In some possible implementations, the parameter retrieval request may also include business scenario code, and the operations server determines the list of identity information to be retrieved based on the business scenario code.

[0014] In some possible implementations, the step of generating the pull-up parameter response includes:

[0015] Upon receiving the ticket identifier, the operation server generates a status parameter and then generates a pull-up parameter response based on the ticket identifier and the status parameter.

[0016] In some possible implementations, the method further includes:

[0017] The operations server responds by receiving the user's wallet identity information from the identity verification server and then compares and verifies the identity information with the locally stored identity information.

[0018] In some possible implementations, the digital currency system includes a digital currency application and a digital currency back-end system, and the identity verification server includes the identity verification application.

[0019] Before the step of generating a request to retrieve pull-up parameters in the digital currency system, the method also includes:

[0020] The digital currency application responds to the user-triggered authentication command by determining whether an authentication application is installed locally.

[0021] If it is determined that an authentication application is installed locally, the digital currency backend system generates a request to retrieve the launch parameters.

[0022] In some possible implementations, the digital currency system also includes a digital currency interoperability system, through which the digital currency back-end system connects to one or more operating servers.

[0023] Secondly, this disclosure provides a method for obtaining identity information, applied to an operation server, the method comprising:

[0024] In response to receiving a pull-up parameter retrieval request from the digital currency system, a bill identifier retrieval message is generated. The pull-up parameter retrieval request includes a user wallet identifier, which indicates the user wallet whose identity information is to be retrieved. The bill identifier retrieval message includes a pre-stored operation server identifier and a list of identity information to be retrieved.

[0025] Send a ticket identifier retrieval message to the authentication server;

[0026] Receive the ticket identifier returned by the authentication server, associate the user wallet identifier with the ticket identifier, and generate a pull-up parameter response based on the ticket identifier;

[0027] Send a pull-up parameter response to the digital currency system so that the digital currency system can obtain an authorization code from the identity verification server based on the pull-up parameter response;

[0028] In response to receiving the authorization code sent by the digital currency system, it sends an encrypted access token acquisition request to the identity verification server and receives the access token and tokenized identity identifier returned by the identity verification server.

[0029] Send an encrypted identity information retrieval request to the identity verification server so that the identity verification server can return the user's wallet identity information based on the list of identity information to be retrieved.

[0030] In some possible implementations, the parameter retrieval request may also include business scenario code, based on which a list of identity information to be retrieved is determined.

[0031] In some possible implementations, the step of generating the pull-up parameter response includes:

[0032] In response to receiving the ticket identifier, generate status parameters and generate a pull-up parameter response based on the ticket identifier and status parameters.

[0033] In some possible implementations, the method further includes:

[0034] In response to receiving the user's wallet identity information returned by the identity verification server, the identity information is compared and verified with the locally stored identity information.

[0035] Thirdly, this disclosure provides an operation server for obtaining identity information, the operation server including:

[0036] The pull-up parameter acquisition module is configured to, in response to receiving a pull-up parameter acquisition request sent by the digital currency system, generate a ticket identifier acquisition message, wherein the pull-up parameter acquisition request includes a user wallet identifier, used to indicate the user wallet whose identity information is to be acquired; the ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired; send the ticket identifier acquisition message to the identity verification server; receive the ticket identifier returned by the identity verification server, associate the user wallet identifier with the ticket identifier, and generate a pull-up parameter response based on the ticket identifier;

[0037] The authorization code acquisition module is configured to send a pull-up parameter response to the digital currency system, so that the digital currency system can obtain the authorization code from the identity verification server based on the pull-up parameter response;

[0038] The access token acquisition module is configured to, in response to receiving an authorization code sent by the digital currency system, send an encrypted access token acquisition request to the identity verification server, and receive the access token and tokenized identity identifier returned by the identity verification server.

[0039] The identity information acquisition module is configured to send an encrypted identity information acquisition request to the identity verification server, so that the identity verification server can return the user's wallet identity information based on the list of identity information to be acquired.

[0040] Fourthly, embodiments of this disclosure provide an identity information acquisition system, the system comprising:

[0041] Such as the operating server and digital currency system of the third aspect of this disclosure;

[0042] The digital currency system is configured as follows:

[0043] Generate a pull-up parameter retrieval request, which includes a user wallet identifier to indicate the user wallet whose identity information is to be retrieved;

[0044] Send a pull-up parameter retrieval request to the operation server associated with the user's wallet, so that the operation server generates a ticket identifier retrieval message, retrieves the ticket identifier from the identity verification server based on the ticket identifier retrieval message, and associates the user's wallet identifier with the ticket identifier. The ticket identifier retrieval message includes a pre-stored operation server identifier and a list of identity information to be retrieved.

[0045] Receive the pull-up parameter response generated by the operation server based on the ticket identifier, and obtain the authorization code from the authentication server based on the pull-up parameter response.

[0046] Fifthly, embodiments of this application provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the methods as described in the first and second aspects.

[0047] Sixthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the methods of the first and second aspects.

[0048] The first aspect of the technical solution provided by the embodiments of this disclosure brings at least the following beneficial effects: the digital currency system generates a pull-up parameter acquisition request; the digital currency system sends the pull-up parameter acquisition request to the operation server associated with the user's wallet, so that the operation server generates a bill identifier acquisition message, and obtains the bill identifier from the identity verification server based on the bill identifier acquisition message, and associates the user's wallet identifier with the bill identifier; the digital currency system receives the pull-up parameter response generated by the operation server based on the bill identifier, and obtains an authorization code from the identity verification server based on the pull-up parameter response; in response to receiving the authorization code sent by the digital currency system, the operation server sends an encrypted access token acquisition request to the identity verification server, and receives the access token and tokenized identity identifier returned by the identity verification server; the operation server sends an encrypted identity information acquisition request to the identity verification server, so that the identity verification server returns the user's wallet identity information based on the list of identity information to be acquired. This disclosure describes an embodiment that designs the interaction process between the digital currency system, the operation server, and the identity verification server in a two-tier digital currency operation system. It obtains an "authorization code" through the digital currency system and an "access token" through the operation server, enabling the operation server to complete user identity verification and obtain user identity information without having to hold its own private key. This ensures both verification efficiency and system security. The use of mechanisms such as "authorization codes" and "access tokens" effectively prevents information leakage and unauthorized access, guaranteeing the safe and stable operation of the digital currency system.

[0049] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0050] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments of this disclosure will be briefly described below. Clearly, the drawings described below only relate to some embodiments of this disclosure and are not intended to limit the scope of this disclosure.

[0052] Figure 1 A schematic diagram illustrating the structure of an identity information acquisition system according to at least one embodiment of the present disclosure is shown;

[0053] Figure 2 A schematic diagram illustrating the main steps of an identity information acquisition method according to at least one embodiment of the present disclosure is shown.

[0054] Figure 3 A flowchart illustrating an identity information acquisition method according to at least one embodiment of the present disclosure is shown;

[0055] Figure 4 A schematic diagram of the main modules of an operation server according to at least one embodiment of the present disclosure is shown;

[0056] Figure 5 An interactive flowchart of an identity information acquisition method according to at least one embodiment of the present disclosure is shown;

[0057] Figure 6 A schematic diagram of an electronic device according to at least one embodiment of the present disclosure is shown;

[0058] Figure 7 A schematic diagram of a computer-readable medium according to at least one embodiment of the present disclosure is shown. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0060] In the following text, any methods, apparatus, examples, and contents that do not fully correspond to the scope defined by the claims are not derived from the present invention. Such methods, apparatus, examples, and contents, as well as all subsequent descriptions, are for illustrative purposes only, or to highlight specific aspects or features of the claims.

[0061] Note that the examples described below are merely specific examples and are not intended to limit the embodiments of this disclosure to the specific shapes, hardware, connections, operations, values, conditions, data, sequences, etc., shown and described. Those skilled in the art can utilize the concepts of this disclosure to construct further embodiments not mentioned herein by reading this specification.

[0062] The terminology used in this disclosure is that which is currently widely used in the art in consideration of the functionality of this disclosure; however, these terms may vary depending on the intent, precedent, or new technology of those skilled in the art. Furthermore, specific terms may be chosen by the applicant, and in such cases, their detailed meanings will be described in the detailed description of this disclosure. Therefore, the terminology used in this specification should not be construed as simple names, but rather based on the meaning of the terms and the overall description of this disclosure.

[0063] To better understand the embodiments of this disclosure, the relevant terms involved in this disclosure will first be defined and explained.

[0064] A digital currency system comprises a digital currency application client and a digital currency back-end system. The digital currency application client, also known as a "digital currency app," is a mobile application that provides full lifecycle management of a digital currency wallet. During use, it can communicate and interact with the digital currency back-end system. The "Digital RMB App" for the digital yuan is an example of a "digital currency app."

[0065] Operating institutions, or operating service providers, refer to commercial banks and other financial institutions that participate in the operation of digital currencies and provide exchange and circulation services to the public under the digital currency system.

[0066] The Digital Currency Interoperability System, or Interoperability System for short, is a platform that supports the transfer, clearing, and message exchange of digital currencies / electronic payments between the central bank and various operating institutions, enabling interconnection between the central bank and various operating institutions.

[0067] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solutions disclosed herein all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security, network security, and national security.

[0068] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0069] Figure 1 A schematic diagram illustrating the structure of an identity information acquisition system according to at least one embodiment of the present disclosure is shown. Figure 1 As shown, the identity information acquisition system includes an identity information acquisition system and an identity verification server 13. The identity information acquisition system includes a digital currency system 11 and one or more operational servers (operational server A 121, operation server B 122, operation server C 123, etc.). The digital currency system 11 and the operational servers together constitute a two-tiered digital currency operation system. Specifically, the digital currency system 11 is responsible for issuing digital currency to commercial banks (acting as operational servers) and managing its entire lifecycle. The operational servers and related commercial institutions are responsible for providing digital currency exchange and circulation services to the public. Specifically, the digital currency system 11 may further include a digital currency application terminal 111, a digital currency back-end system 112, and a digital currency interconnection system 113. The digital currency back-end system 112 can forward and process information and instructions transmitted between the digital currency application terminal 111 and the digital currency interconnection system 113. The identity verification server 13 includes an identity verification application terminal 131 and an identity verification back-end system 132. The digital currency application terminal 111 and the identity verification application terminal 131 can be installed on mobile devices. The digital currency interconnection system 113 communicates with the operation server to forward and process digital currencies; alternatively, a separate digital currency interconnection system 113 may not be set up, and the digital currency back-end system 112 may communicate directly with the operation server.

[0070] Mobile devices can be user terminal devices. Mobile devices may have a digital currency application (111) installed, such as a digital currency app, and may also have an identity verification application (131) installed. For example, when verifying the identity of Hong Kong residents, the Smart Convenience app can be used. In this case, the identity verification application (131) is the Smart Convenience app, and the digital currency app pulls the Smart Convenience app for identity verification. Mobile devices may include hardware devices such as security chips, fingerprint recognition modules, front-facing cameras, and touchscreens. User confirmation or identity verification can be performed using these hardware devices through passwords, device features, or biometric methods such as facial recognition or fingerprint recognition.

[0071] In at least one embodiment of this disclosure, when a user uses a digital currency app, user identity verification is required to ensure the security of funds and information. Verification scenarios include opening or upgrading a user wallet, conducting large transactions, querying user's real-name wallet information, and retrieving passwords. For some overseas users, there is a lack of efficient identity verification methods. Especially under a two-tier operating system, taking Hong Kong residents as an example, if a digital currency app pulls a smart app for user identity verification, the system still has operating servers. Key issues that urgently need to be addressed include how different operating servers can obtain user identity information and ensure its security (user identity information cannot be shared among multiple operating servers or digital currency systems), how to ensure the security of the keys used by different operating servers during user identity verification (operating servers cannot be required to entrust their keys to the digital currency system for encryption and decryption), and the convenience and efficiency of the identity verification process. This disclosure designs the interaction process between the digital currency system 11 and the operation server during the identity verification process. The digital currency system 11 communicates with the identity verification application 131 to obtain the authorization code, and the operation server communicates with the identity verification application 131 to further obtain the access token and user identity information, effectively solving the problems of information security and verification efficiency in the identity verification process.

[0072] Figure 2 A schematic diagram illustrating the main steps of an identity information acquisition method according to at least one embodiment of the present disclosure is shown. Figure 3 A flowchart illustrating an identity information acquisition method according to at least one embodiment of the present disclosure is shown. The method includes:

[0073] In step S210, the digital currency system 11 generates a pull-up parameter acquisition request. The pull-up parameter acquisition request includes a user wallet identifier, which is used to indicate the user wallet whose identity information is to be acquired.

[0074] Due to business needs, such as opening or upgrading user wallets, conducting large transactions, querying user's real-name wallet information, and retrieving passwords, the digital currency system 11 requires user identity verification. Taking wallet upgrade as an example, the four types of anonymous wallets in the digital currency app can be upgraded to three types of real-name wallets. Scenarios that trigger wallet upgrades include business scenarios such as wallet management, wallet top-up, bank deposit, money transfer, and cashier. At this time, in order to verify the real-name user, it is necessary to launch the identity verification server 13. For example, for Hong Kong resident identity verification, the Smart Convenience App can be launched. To implement the launch step, the digital currency system 11 will first send a launch parameter acquisition request to the operation server (e.g., operation server A121) (step S301). The launch parameter acquisition request includes the user wallet identifier (i.e., wallet ID), which is used to indicate the user wallet whose identity information is to be obtained.

[0075] In some possible implementations, for example, the digital currency system includes a digital currency application client 111 and a digital currency backend system 112, or further includes a digital currency interconnection system 113. The digital currency backend system 112 (hereinafter referred to as the wallet backend) is connected to one or more operating servers through the digital currency interconnection system 113. The authentication server 13 includes an authentication application client 131 (e.g., a web page or mobile application, collectively referred to as the authentication app). In response to receiving an authentication command triggered by a user, the digital currency application client 111 determines whether the authentication application client 131 is installed locally. If the authentication application client 131 is installed locally, it requests the digital currency backend system 112 to generate a pull-up parameter retrieval request. For example, when a user performs a business operation requiring authentication on the digital currency app, an authentication command is triggered. Based on this command, the digital currency app first determines whether the authentication app is installed locally. If the authentication app is installed locally, it generates a request containing relevant information for this authentication, such as the user's wallet ID and the request source, and then sends the request to the wallet backend via network protocols such as HTTP / HTTPS. After receiving the request, the wallet backend first performs a preliminary verification to ensure the legality and completeness of the request. Next, according to the predefined rules for connecting with the operations server, the request undergoes message format conversion and necessary information supplementation. Based on the received request, a pull-up parameter retrieval request is generated. In some possible implementations, the pull-up parameter retrieval request also includes a business scenario code, indicating whether the identity information retrieval is for registration, login, wallet upgrade, or other specific business operations. The operations server can determine the list of identity information to be retrieved based on the business scenario code.

[0076] Understandably, if it is determined that the authentication application client 131 is not installed locally, the system may optionally prompt the user that the authentication failed or prompt the user to install the authentication application client 131.

[0077] In step S220, the digital currency system 11 sends a pull-up parameter acquisition request to the operation server associated with the user's wallet, so that the operation server generates a ticket identifier acquisition message, and obtains the ticket identifier from the identity verification server 13 based on the ticket identifier acquisition message, and associates the user's wallet identifier with the ticket identifier. The ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired.

[0078] Since the digital currency system 11 can communicate with multiple operating servers, after generating a request to retrieve startup parameters in the wallet backend, it will send the request to the operating server to which the user's wallet belongs. For example, if the user's wallet is opened at bank A (operating server A 121), the request to retrieve startup parameters will be sent to bank A through the wallet backend; or the wallet backend will send it to bank A through the digital currency interconnection system 113.

[0079] After receiving the pull-up parameter retrieval request, Bank A parses and checks the validity of the request. If the request is valid, Bank A further generates a ticket identifier retrieval message to obtain the ticket identifier (i.e., ticket ID) from the authentication server 13 (step S302). It is understood that the ticket identifier retrieval message includes pre-stored identifiers (ClientIDs) for each operating server. Based on these ClientIDs, the authentication server 13 can identify the source of the message. Different operating servers have different ClientIDs and keys, and the ClientIDs of each operating server are also pre-stored in the authentication backend system 132 of the authentication server 13. Thus, Bank A uses communication protocols such as HTTP or HTTPS to send the ticket identifier retrieval message to the interface provided by the authentication server 13 via the network. When the authentication server 13 receives the ticket identifier retrieval message, it can determine that the source of the message is Bank A based on the ClientID stored internally. The authentication server 13 can further parse and verify the message parameters to confirm the validity of the request.

[0080] In addition to determining the message source, it is also necessary to determine which fields of the specific identity information to be authenticated include. For example, Bank A can use the "profileFields" field to specify the user information it needs to obtain from the authentication server 13, such as name, ID number, gender, and date of birth. The profileFields field is a parameter used to specify the user information fields to be obtained. For example, ["name","phone","email"] indicates that it wants to obtain the user's name, mobile phone number, and email address. Bank A can determine which fields to obtain from the authentication server 13 based on factors such as Bank A's internal KYC requirements, the authentication requirements of the digital currency system, or the specific business scenarios of the user. The specific business scenarios of the user can be associated with the business scenario code in the parameter retrieval request. For example, wallet upgrades or identity verification involve different business scenarios and require different identity information fields. Using the profileFields field allows for precise specification of the user information to be obtained, avoiding the acquisition of too much unnecessary data, improving the efficiency and targeting of data processing, and better protecting user privacy.

[0081] After receiving the ticket identifier retrieval message from Bank A, the authentication server 13 assigns a unique "ticket ID" to this request based on the ClientID and "profileFields" fields. For example, a UUID algorithm can be used to ensure its uniqueness. This "ticket ID" is used for authentication and information association in subsequent processes. The authentication server 13 then sends the "ticket ID" to Bank A.

[0082] After receiving the "ticket ID" returned by the identity verification server 13, Bank A processes and verifies the content. If it is correct, it can proceed with further processing. For example, it associates the user wallet identifier (user wallet ID) with the ticket identifier "ticket ID" (step S303). In this way, after receiving user identity information based on "ticket ID", it can subsequently associate the user identity information with the user wallet ID.

[0083] Optionally, a state parameter (state) can be generated. `state` is a random string used to prevent cross-site request forgery (CSRF) attacks and track request status. After generating the state, Bank A can store it locally and carry it in subsequent requests for verification when the authentication server 13 returns a result, ensuring its legitimacy.

[0084] Understandably, Bank A generates a pull-up parameter response based on the "ticket ID" (step S304). For example, if Bank A receives the "ticket ID" returned by the authentication server 13, Bank A can append other necessary parameters to the "ticket ID" to encapsulate it into a URL, thus generating the pull-up parameter response. For instance, when Bank A generates the state, the state can be added to the URL, as shown in the example below:

[0085] app_HK_auth_url="https: / / app-HK.com / auth?ticket_id=12345&state=abcdef"

[0086] In step S230, the digital currency system 11 receives the pull-up parameter response generated by the operation server based on the bill identifier, and obtains the authorization code from the identity verification server 13 based on the pull-up parameter response.

[0087] The digital currency system 11 receives a pull-up parameter response (e.g., URL) from bank A. The digital currency app can then call the interface or protocol provided by the authentication server 13 to launch the authentication application 131 (authentication app) to obtain an authorization code (step S305). For example, the user completes user confirmation and / or authentication operations in the authentication app according to system prompts, which may include entering personal information, performing biometric verification (e.g., fingerprint, facial recognition), etc. The authentication server's authentication backend system 132 verifies and processes the URL and the user's operations, such as verifying the validity and authenticity of the "ticket ID," checking whether the "ticket ID" was generated by the authentication server 13, and whether it is within its validity period. After successful verification, a temporary "authorization code" (auth code) is generated. The "authorization code" is a short-term valid credential used to obtain an access token later. After receiving the "authorization code," the digital currency app can send the "authorization code" to the operation server (e.g., bank A) through the wallet backend.

[0088] In step S240, the operation server responds to the authorization code sent by the digital currency system 11 by sending an encrypted access token acquisition request to the identity verification server 13, and receives the access token and tokenized identity identifier returned by the identity verification server 13.

[0089] After receiving the "authorization code" returned by the identity verification server 13, the digital currency system 11 sends it to the operation server (step S306). Upon receiving the "authorization code", the operation server checks its legality to ensure the validity and authenticity of the "authorization code".

[0090] The operation server uses the received "authorization code" to send an access token acquisition request to the identity verification server 13 (step S307). In this request, the operation server carries the "authorization code" and other necessary fixed parameters to prove the legitimacy of the request. To ensure information security during transmission, the sent access token acquisition request should be encrypted using the operation server's key. It is understood that the specific encryption rules can be configured between the operation server and the identity verification server 13 before the start of each step of identity information acquisition; therefore, in this embodiment, the keys of each operation server do not need to be held in escrow by the digital currency system 11.

[0091] After receiving the access token retrieval request from the operations server, the authentication server 13 verifies the "authorization code". Upon successful verification, the authentication server 13 generates a long-term valid "access token" and a "tokenized ID" (i.e., open ID). The "access token" is used for subsequent access to resources on the authentication server 13, while the "tokenized ID" is the user's unique identifier on the authentication server 13. The authentication server 13 encapsulates the "access token" and "tokenized ID" in a response and returns it to the operations server.

[0092] In step S250, the operation server sends an encrypted identity information retrieval request to the identity verification server 13, so that the identity verification server 13 returns the user's wallet identity information based on the list of identity information to be retrieved.

[0093] After receiving the "access token" and "tokenized identity identifier" returned by the authentication server 13, the operation server decrypts the received information to obtain the "access token" and "tokenized identity identifier". Based on the decrypted "access token" and "tokenized identity identifier", it generates an encrypted identity information retrieval request, which includes the "access token" and "tokenized identity identifier". The user identity information is then retrieved from the authentication server 13 by calling the interface (step S308). Specifically, after receiving the identity information retrieval request, the authentication server 13 verifies the request. Optionally, the verification information includes the "access token". After successful verification, the authentication server 13 retrieves the user information corresponding to the profileFields field from the database based on the "tokenized identity identifier", encapsulates this information in a response, and returns it to the operation server.

[0094] In some possible implementations, the method further includes: in response to receiving the user's wallet identity information returned by the identity verification server, if the operation server has already stored the user's identity information, comparing and verifying the identity information obtained this time with the locally stored identity information.

[0095] Optionally, the operations server can further return the identity information acquisition results to the digital currency app via the interconnection system and wallet backend.

[0096] Figure 4 A schematic diagram of the main modules of an operation server according to at least one embodiment of the present disclosure is shown. The operation server for obtaining identity information includes:

[0097] The pull-up parameter acquisition module 1211 is configured to, in response to receiving a pull-up parameter acquisition request sent by the digital currency system 11, generate a bill identifier acquisition message, wherein the pull-up parameter acquisition request includes a user wallet identifier, used to indicate the user wallet whose identity information is to be acquired; the bill identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired; send the bill identifier acquisition message to the identity verification server 13; receive the bill identifier returned by the identity verification server 13, associate the user wallet identifier with the bill identifier, and generate a pull-up parameter response based on the bill identifier;

[0098] The authorization code acquisition module 1212 is configured to send a pull-up parameter response to the digital currency system 11 so that the digital currency system 11 can obtain the authorization code from the identity verification server 13 according to the pull-up parameter response;

[0099] The access token acquisition module 1213 is configured to send an encrypted access token acquisition request to the identity verification server 13 in response to receiving the authorization code sent by the digital currency system 11, and to receive the access token and tokenized identity identifier returned by the identity verification server 13.

[0100] The identity information acquisition module 1214 is configured to send an encrypted identity information acquisition request to the identity verification server 13, so that the identity verification server 13 returns the user's wallet identity information based on the list of identity information to be acquired.

[0101] In some possible implementations, the pull-up parameter acquisition request also includes business scenario code, and the pull-up parameter acquisition module 1211 of the operation server determines the list of identity information to be acquired based on the business scenario code.

[0102] In some possible implementations, the step of generating the pull-up parameter response includes:

[0103] The pull-up parameter acquisition module 1211 of the operation server responds to the receipt of the ticket identifier to generate status parameters, and generates a pull-up parameter response based on the ticket identifier and status parameters.

[0104] In some possible implementations, the method further includes:

[0105] The identity information acquisition module 1214 of the operation server responds to the identity information of the user's wallet returned by the identity verification server and compares and verifies the identity information with the identity information stored locally.

[0106] This disclosure also provides an identity information acquisition system, which includes: an operation server and a digital currency system 11;

[0107] Digital currency system 11, configured as follows:

[0108] Generate a pull-up parameter retrieval request, which includes a user wallet identifier to indicate the user wallet whose identity information is to be retrieved;

[0109] Send a pull-up parameter acquisition request to the operation server associated with the user wallet, so that the operation server generates a ticket identifier acquisition message, and obtains the ticket identifier from the identity verification server 13 based on the ticket identifier acquisition message, and associates the user wallet identifier with the ticket identifier. The ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired.

[0110] Receive the pull-up parameter response generated by the operation server based on the ticket identifier, and obtain the authorization code from the authentication server based on the pull-up parameter response.

[0111] In some possible implementations, the digital currency system includes a digital currency application and a digital currency back-end system, and the identity verification server includes the identity verification application.

[0112] Before the step of generating a request to retrieve pull-up parameters in the digital currency system, the method also includes:

[0113] The digital currency application of the digital currency system responds to the user-triggered authentication command by determining whether the authentication application is installed locally.

[0114] If it is determined that an authentication application is installed locally, the digital currency backend system generates a request to retrieve the launch parameters.

[0115] In some possible implementations, the digital currency system also includes a digital currency interoperability system, through which the digital currency back-end system connects to one or more operating servers.

[0116] Figure 5 An interactive flowchart of an identity information acquisition method according to at least one embodiment of the present disclosure is shown. Taking the example of the Digital Currency App calling the Smart Convenience App to obtain user identity information, the specific steps are as follows:

[0117] Step S501: The Digital Currency App receives the identity verification command triggered by the user and determines whether the Smart Convenience App is installed locally.

[0118] Step S502: If the Smart Convenience App is installed locally, generate a request to verify relevant information and send the request to the wallet backend;

[0119] Step S503: The wallet backend receives the request, generates and sends a pull-up parameter acquisition request to the interoperability system;

[0120] Step S504: The interconnection system forwards the request to the operating agency;

[0121] Step S505: The operating institution reads its own "Client ID", assembles and generates a bill identifier acquisition message, and sends the bill identifier acquisition message to the smart backend through the interface;

[0122] Step S506: The system conveniently provides the ticketID to the backend.

[0123] Step S507: The operating organization generates a state, associates the user's wallet ID with the ticket ID, and generates a pull-up parameter response.

[0124] Step S508: The operator sends a pull-up parameter response to the interconnection system;

[0125] Step S509: The interconnection system sends a pull-up parameter response to the wallet backend;

[0126] Step S510: The wallet backend sends a pull-up parameter response to the digital currency app;

[0127] Step S511: The Digital Currency App launches the Smart Convenience App to obtain the authorization code;

[0128] Step S512: The Smart Convenience App performs user confirmation.

[0129] Step S513: The Smart Convenience App sends an authorization code acquisition request to the Smart Convenience backend;

[0130] Step S514: The intelligent system performs a business check in the backend. Once the check is passed, an authorization code is returned.

[0131] Step S515: The Smart Convenience App returns the authorization code to the Digital Currency App;

[0132] Step S516: The digital currency app forwards the authorization code to the wallet backend, and the interconnection system forwards it to the operating institution.

[0133] Step S517: The operating organization generates an encrypted access token acquisition request based on the authorization code and sends it to the Smart Convenience backend.

[0134] Step S518: The intelligent backend returns the access token and tokenized identity identifier;

[0135] Step S519: The operating organization decrypts the data and generates an encrypted identity information acquisition request, which is then sent to the intelligent backend.

[0136] Step S520: The system conveniently returns the user's wallet identity information to the backend.

[0137] Step S521: The operating institution decrypts the information and returns the identity information acquisition result to the Digital Currency App via the interconnection system and wallet backend.

[0138] This disclosure describes an embodiment that designs the interaction process between the digital currency system, the operation server, and the identity verification server in a two-tier digital currency operation system. It obtains an "authorization code" through the digital currency system and an "access token" through the operation server, enabling the operation server to complete user identity verification and obtain user identity-related information without having to custody its own keys, thus ensuring system security. The use of mechanisms such as "authorization codes" and "access tokens" effectively prevents information leakage and unauthorized access, ensuring the safe and stable operation of the digital currency system.

[0139] It should be noted that the above application scenarios are merely exemplary, intended to describe one or more aspects of this disclosure in specific scenarios. However, these aspects are not essential, and various modifications can be made to the application scenario. It is readily understood that the specific application scenarios described in this disclosure are not limited.

[0140] At least some embodiments of this disclosure also provide an electronic device. Figure 6 A schematic diagram of an electronic device 600 according to at least one embodiment of the present disclosure is shown.

[0141] like Figure 6 As shown, the electronic device 600 includes one or more processors 610 and a memory 620. The memory 620 includes one or more computer program modules 621. The one or more computer program modules 621 are stored in the memory 620 and are executed by the processor 610. These computer program modules 621 include instructions for executing an identity information acquisition method and its additional aspects according to at least one embodiment of the present disclosure. When executed by the processor 610, they can perform one or more steps of the identity information acquisition method and its additional aspects according to at least one embodiment of the present disclosure. The memory 620 and the processor 610 can be interconnected via a bus system and / or other forms of connection mechanisms (not shown). For example, the bus can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0142] For example, processor 610 may be a central processing unit (CPU), a digital signal processor (DSP), or other processing unit with data processing and / or program execution capabilities, such as a field-programmable gate array (FPGA). Processor 610 may be a general-purpose processor or a special-purpose processor, capable of controlling other components in electronic device 600 to perform desired functions.

[0143] Exemplarily, memory 620 may include any combination of one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, flash memory, etc. One or more computer program modules 621 may be stored on the computer-readable storage medium, and processor 610 may run one or more computer program modules 621 to implement various functions of electronic device 600. The computer program modules include multiple computer-executable instructions. Various application programs and various data, as well as various data used and / or generated by the application programs, may also be stored in the computer-readable storage medium.

[0144] For example, electronic device 600 may also include input devices such as touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, and gyroscopes; output devices such as liquid crystal displays, speakers, and vibrators; storage devices such as magnetic tapes and hard disks (HDDs or SDDs); and communication devices such as network interface cards like LAN cards and modems. The communication devices allow electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data and perform communication processing via networks such as the Internet. A drive is connected to the I / O interface as needed. Removable storage media, such as disks, optical disks, magneto-optical disks, and semiconductor memories, are installed on the drive as needed so that computer programs read from them can be installed into the storage device as required.

[0145] For example, the electronic device 600 may further include a peripheral interface (not shown in the figure). This peripheral interface can be various types of interfaces, such as a USB interface, a Lightning interface, etc. The communication device can communicate wirelessly with networks and other devices, such as the Internet, intranets and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). Wireless communication can use any of a variety of communication standards, protocols, and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wi-Fi (e.g., based on IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n standards), Voice over Internet Protocol (VoIP), Wi-MAX, protocols for email, instant messaging, and / or Short Message Service (SMS), or any other suitable communication protocol.

[0146] The electronic device 600 may be, for example, a system-on-a-chip (SOC) or a device including the SOC. It can be any device such as a mobile phone, tablet computer, laptop computer, e-reader, game console, television, digital photo frame, navigator, home appliance, communication base station, industrial controller, server, etc., or any combination of data processing devices and hardware. The embodiments of this disclosure do not limit this. The specific functions and technical effects of the electronic device 600 can be found in the description above of the identity information acquisition method and its additional aspects according to at least one embodiment of this disclosure, and will not be repeated here.

[0147] Figure 7 A schematic diagram of a readable storage medium 700 according to at least one embodiment of the present disclosure is shown.

[0148] like Figure 7 As shown, a computer program 710 is stored on a readable storage medium 700, which is a computer-readable storage medium. When the computer program 710 is executed by a processor, it performs one or more steps of the above-described method for obtaining identity information and its additional aspects.

[0149] For example, when the program code is read by a computer, the computer can execute the program code stored in the computer storage medium to perform one or more steps to implement, for example, the identity information acquisition method and its additional aspects according to at least one embodiment of the present disclosure.

[0150] For example, the readable storage medium may include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), flash memory, and other readable storage media or any combination thereof. The readable storage medium 700 may be a non-transitory readable storage medium.

[0151] At least some of the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0152] It should be noted that, in this disclosure, relational terms such as "first," "second," etc., are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0153] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved; that is, the preceding or following operations are not necessarily executed precisely in sequence. Instead, various steps may be processed in reverse order or simultaneously as needed. Furthermore, other operations may be added to these processes, or one or more operations may be removed from these processes.

[0154] The units described in the embodiments of this disclosure can be implemented in software or hardware. The described units can also be located in a processor. The names of these units do not, in some cases, constitute a limitation on the unit itself.

[0155] The following points should be noted regarding this disclosure:

[0156] (1) The accompanying drawings of the embodiments of this disclosure only involve the structures involved in the embodiments of this disclosure. Other structures can be referred to the general design.

[0157] (2) Where there is no conflict, the embodiments of this disclosure and the features in the embodiments can be combined with each other to obtain new embodiments.

[0158] The above are merely exemplary embodiments of this disclosure and are not intended to limit the scope of protection of this disclosure, which is determined by the appended claims.

Claims

1. A method for obtaining identity information, characterized in that, The method includes: The digital currency system generates a pull-up parameter acquisition request, which includes a user wallet identifier to indicate the user wallet whose identity information is to be acquired. The digital currency system sends the pull-up parameter acquisition request to the operation server associated with the user wallet, so that the operation server generates a ticket identifier acquisition message, acquires the ticket identifier from the identity verification server based on the ticket identifier acquisition message, and associates the user wallet identifier with the ticket identifier. The ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired. The digital currency system receives a pull-up parameter response generated by the operation server based on the bill identifier, and obtains an authorization code from the identity verification server based on the pull-up parameter response; In response to receiving the authorization code sent by the digital currency system, the operation server sends an encrypted access token acquisition request to the identity verification server and receives the access token and tokenized identity identifier returned by the identity verification server. The operation server sends an encrypted identity information acquisition request to the identity verification server, so that the identity verification server returns the user's wallet identity information based on the list of identity information to be acquired. The key of the operation server does not need to be held in custody by the digital currency system.

2. The method according to claim 1, characterized in that, The request to retrieve the pull-up parameters also includes business scenario code, and the operation server determines the list of identity information to be retrieved based on the business scenario code.

3. The method according to claim 1, characterized in that, The step of generating the pull-up parameter response includes: The operation server responds to receiving the ticket identifier generation status parameter by generating the pull-up parameter response based on the ticket identifier and the status parameter.

4. The method according to claim 1, characterized in that, The method further includes: The operation server responds to the user's wallet identity information returned by the identity verification server by comparing and verifying the identity information with the locally stored identity information.

5. The method according to claim 1, characterized in that, The digital currency system includes a digital currency application terminal and a digital currency back-end system, and the identity verification server includes an identity verification application terminal. Before the step of generating a request to obtain the pull-up parameters in the digital currency system, the method further includes: The digital currency application responds to receiving an authentication command triggered by the user by determining whether the authentication application is installed locally. If the authentication application is determined to be installed locally, the digital currency backend system generates the request to obtain the launch parameters.

6. The method according to claim 5, characterized in that, The digital currency system also includes a digital currency interconnection system, through which the digital currency back-end system connects to one or more of the operating servers.

7. A method for obtaining identity information, characterized in that, Applied to the operation server, the method includes: In response to receiving a pull-up parameter acquisition request from the digital currency system, a bill identifier acquisition message is generated, wherein the pull-up parameter acquisition request includes a user wallet identifier, used to indicate the user wallet whose identity information is to be acquired; the bill identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired; Send the ticket identifier acquisition message to the authentication server; Receive the ticket identifier returned by the authentication server, associate the user wallet identifier with the ticket identifier, and generate a pull-up parameter response based on the ticket identifier; Send the pull-up parameter response to the digital currency system so that the digital currency system can obtain the authorization code from the identity verification server based on the pull-up parameter response; In response to receiving the authorization code sent by the digital currency system, an encrypted access token acquisition request is sent to the identity verification server, and the access token and tokenized identity identifier returned by the identity verification server are received. Send an encrypted identity information retrieval request to the identity verification server so that the identity verification server returns the user's wallet identity information based on the list of identity information to be retrieved; The key of the operation server does not need to be held in custody by the digital currency system.

8. The method according to claim 7, characterized in that, The request to retrieve pull-up parameters also includes business scenario code, and the list of identity information to be retrieved is determined based on the business scenario code.

9. The method according to claim 7, characterized in that, The step of generating the pull-up parameter response includes: In response to receiving the ticket identifier to generate status parameters, the pull-up parameter response is generated based on the ticket identifier and the status parameters.

10. The method according to claim 7, characterized in that, The method further includes: In response to receiving the user's wallet identity information returned by the identity verification server, the identity information is compared and verified with the locally stored identity information.

11. An operation server for obtaining identity information, the operation server comprising: The pull-up parameter acquisition module is configured to, in response to receiving a pull-up parameter acquisition request sent by the digital currency system, generate a ticket identifier acquisition message, wherein the pull-up parameter acquisition request includes a user wallet identifier, used to indicate the user wallet whose identity information is to be acquired; the ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired; send the ticket identifier acquisition message to the identity verification server; receive the ticket identifier returned by the identity verification server, associate the user wallet identifier with the ticket identifier, and generate a pull-up parameter response based on the ticket identifier; The authorization code acquisition module is configured to send the pull-up parameter response to the digital currency system, so that the digital currency system can obtain the authorization code from the identity verification server based on the pull-up parameter response; The access token acquisition module is configured to, in response to receiving the authorization code sent by the digital currency system, send an encrypted access token acquisition request to the identity verification server, and receive the access token and tokenized identity identifier returned by the identity verification server. The identity information acquisition module is configured to send an encrypted identity information acquisition request to the identity verification server, so that the identity verification server returns the identity information of the user's wallet according to the list of identity information to be acquired. The key of the operation server does not need to be held in custody by the digital currency system.

12. An identity information acquisition system, the system comprising: The operation server and digital currency system as described in claim 11; The digital currency system is configured as follows: Generate a pull-up parameter retrieval request, the pull-up parameter retrieval request including a user wallet identifier, used to indicate the user wallet whose identity information is to be retrieved; Send the pull-up parameter acquisition request to the operation server associated with the user wallet, so that the operation server generates a ticket identifier acquisition message, and obtains the ticket identifier from the identity verification server based on the ticket identifier acquisition message, and associates the user wallet identifier with the ticket identifier, wherein the ticket identifier acquisition message includes a pre-stored operation server identifier and a list of identity information to be acquired; Receive the pull-up parameter response generated by the operation server based on the ticket identifier, and obtain the authorization code from the authentication server based on the pull-up parameter response.

13. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-10.

14. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-10.

Images