CN116452204A - DID-based payment method and device, readable storage medium and electronic equipment - Google Patents

Abstract

The specification relates to a DID-based payment method, a DID-based payment device, a DID-based payment storage medium and an electronic device, wherein the DID-based payment method comprises the following steps: generating a payment request; acquiring a to-be-authenticated biological characteristic input by a user; comparing the biological characteristics to be authenticated with pre-stored DID standard biological characteristics; and when the obtained first local comparison results are the same, signing the payment request by adopting a pre-stored DID private key so as to realize the payment function through the DID.

Description

Payment method, device, readable storage medium and electronic equipment based on DID

technical field

This specification relates to the field of decentralized identity, and more specifically relates to a DID-based payment method, device, readable storage medium and electronic equipment.

Background technique

Decentralized Identity (DID) is a kind of digital identity, which is derived and derived from the traditional centralized identity. In the DID system, each entity (including individuals, organizations, devices, etc.) A DID identifier, a DID identifier is a character string in a specific format used to represent the digital identity of an entity. Each DID identifier corresponds to a DID document. The DID system can be decentralized, so it is more secure and private, and has application prospects in the payment field.

In the DID system, the disclosure, display, and transfer of all DID-based physical assets (verifiable statement VC, carbon data, etc.) must be authorized by the DID private key signature before it can be completed. Therefore, whoever controls the DID private key holds the DID and can enjoy related rights and interests. If the DID private key is stolen by an attacker during the payment process, property losses will result.

Therefore, how to ensure that the DID private key is not stolen so as to ensure the security of payment is a technical problem to be solved urgently by those skilled in the art.

Contents of the invention

One of the purposes of this manual is to provide a payment method based on DID, which can realize biometric authentication locally, and after the authentication is passed, use the DID private key to sign the payment request, thereby realizing the payment function through DID, ensuring safety.

Based on the above purpose, this specification provides a DID-based payment method, the method is applied to a payment application, the payment application is installed on the mobile terminal, and the payment application is embedded with a DID SDK, and the method includes:

generate payment requests;

Obtain the biometrics input by the user to be authenticated;

Using the DID SDK to compare the biometrics to be authenticated with the DID standard biometrics pre-stored in the TEE by the DID SDK;

When the first local comparison result is obtained through the DID SDK and the first local comparison result is the same, the DID SDK uses the pre-stored DID private key to sign the payment request, so as to realize the payment function through the DID.

In some embodiments, before generating the payment request, it also includes:

Receive a DID biometric authentication activation request through the DID SDK;

Obtain the payment standard biometric feature stored in the TEE by the payment application;

The payment standard biometric feature is stored in the TEE as a DID standard biometric feature through the DID SDK.

In some embodiments, also include:

Receive a DID biometric authentication update request through the DID SDK;

Obtaining the first biometric feature input by the user;

Comparing the first biometric feature with the DID standard biometric feature through the DID SDK to obtain a second local comparison result;

When the second local comparison result is the same, acquire a second biological feature input by the user;

The second biometric feature is stored in the TEE as a DID standard biometric feature through the DID SDK.

In some implementation manners, when the DID SDK cannot obtain the first local comparison result, it further includes:

Send the biometrics to be authenticated to the DID server through the DID SDK, so that the DID server compares the biometrics to be authenticated with the pre-stored DID standard biometrics to obtain the comparison result of the server, and send The comparison result of the server is sent to the DID SDK;

receiving the comparison result of the server through the DID SDK;

When the comparison result of the server is the same, the DID SDK uses the pre-stored DID private key to sign the payment request, so as to realize the payment function through the DID.

Another purpose of this manual is to provide a payment device based on DID, which can realize biometric authentication locally, and after the authentication is passed, use the DID private key to sign the payment request, so as to realize the payment function through DID and ensure security sex.

Based on the above purpose, this specification provides a DID-based payment device, the device is applied to a payment application, the payment application is installed on a mobile terminal, and the payment application is embedded with a DID SDK, and the device includes:

A generating module for generating payment requests;

An acquisition module, configured to acquire the biometrics input by the user to be authenticated;

A comparison module, used to compare the biological characteristics to be authenticated with the DID standard biological characteristics pre-stored in the TEE by the DID SDK through the DID SDK;

A signature module, configured to use the DID SDK to sign the payment request with the pre-stored DID private key when the first local comparison result is obtained through the DID SDK and the first local comparison result is the same, so as to pass DID realizes the payment function.

In some embodiments, the device further includes an opening module, and the opening module is used for:

Receive a DID biometric authentication activation request through the DID SDK;

Obtain the payment standard biometric feature stored in the TEE by the payment application;

The payment standard biometric feature is stored in the TEE as a DID standard biometric feature through the DID SDK.

In some embodiments, the device also includes an update module, the update module is used for:

Receive a DID biometric authentication update request through the DID SDK;

Obtaining the first biometric feature input by the user;

Comparing the first biometric feature with the DID standard biometric feature through the DID SDK to obtain a second local comparison result;

When the second local comparison result is the same, acquire a second biological feature input by the user;

The second biometric feature is stored in the TEE as a DID standard biometric feature through the DID SDK.

In some embodiments, the device also includes a server-side comparison module, and the server-side comparison module is used for:

When the DID SDK fails to obtain the first local comparison result, send the biometrics to be authenticated to the DID server through the DID SDK, so that the DID server compares the biometrics to be authenticated with the pre-stored compare the DID standard biometrics, obtain the server-side comparison result, and send the server-side comparison result to the DIDSDK;

receiving the comparison result of the server through the DID SDK;

When the comparison result of the server is the same, the DID SDK uses the pre-stored DID private key to sign the payment request, so as to realize the payment function through the DID.

Another object of this specification is to provide a readable storage medium on which a computer program is stored, and when the computer program is executed in the computer, the computer is made to execute the steps of the above-mentioned DID-based payment method.

Another purpose of this specification is to provide an electronic device, which includes a memory and a processor, and executable code is stored in the memory. When the processor executes the executable code, it performs the steps of the above-mentioned DID-based payment method .

Description of drawings

Fig. 1 is the flow chart of the payment method based on DID according to the embodiment of this description;

Fig. 2 is a schematic structural diagram of a DID-based payment device according to an embodiment of the present specification.

Detailed ways

The preferred embodiments of this specification are given and described in detail below in conjunction with the accompanying drawings.

In the DID system, each entity (including individuals, organizations, devices, etc.) is identified by a DID, which is a character string in a specific format used to represent the digital identity of the entity. Each DID identifier corresponds to a DID document. The DID identifier can be used as a uniform resource identifier (URI) for locating a DID document. The DID identifier includes a scheme (Scheme), a DID method, and a DID method specific string (DID method specific string), where the scheme is fixed and is used to indicate that the string is a DID identifier string, and the DID method indicates that the DID identifier is Which set of methods are used to define and operate, and the DID method-specific string is used to represent the unique identification string under the DID method. Each DID identifier corresponds to a DID document. The DID identifier can be used as a uniform resource identifier (URI) for locating a DID document. A DID document is a descriptive text including a preset format (for example, JSON-LD) about the DID identity and the owner of the DID. A DID document may include various attributes such as context, DID subject, public key, authentication, authorization and delegation, service endpoint, creation, update, attestation, extensibility, other suitable attributes, or any combination thereof. A DID document can define or point to a resource that defines a number of operations that can be performed with respect to the DID. In the DID system, the DID private key of each entity is saved by each entity itself, and the DID document of each entity is stored in the blockchain. The corresponding DID document can be queried in the blockchain through the DID identification of the entity.

In the DID-based payment process, if entity A has a payment demand, entity A will generate a payment request through the payment application installed on it, then sign the payment request with the DID private key, and then send the signed payment request Send it to entity B, where the payment application server is installed on entity B to authenticate the signed payment request, and complete the payment function according to the payment request after the authentication is passed. Since entity A and entity B are both members of the DID system, they both have a unique DID identifier. After entity B receives the signed payment request sent by entity A, entity B will first use the DID identifier of entity A to pay in the area. Query the corresponding DID document in the block chain, and then use the public key in the DID document to verify the signature of the signed payment request. If the verification is passed, it means that the payment request is issued by entity A, and the payment application on entity B The server will complete the payment operation according to the payment request to realize the payment function; if the signature verification fails, it means that the signed payment request is not issued by entity A, and the payment application server on entity B will not perform the payment operation, so Unable to implement the payment function. It can be seen from the above that the DID private key is the prerequisite for ensuring safe payment. If the DID private key is stolen by an attacker, the attacker can sign a forged payment request through the DID private key, and then realize the payment function, resulting in property loss.

In order to ensure the security of the DID private key, in some ways, the DID private key can be protected by a password key, that is, when generating the DID private key, set a password key, and when it is necessary to use the DID private key to sign, enter The preset password is used to obtain the right to use the DID private key, but the password key is easy to forget, and there is no retrieval mechanism, so the cost of use is high. In other ways, biometrics can be used instead of password keys. For example, when generating a DID private key, attach a statement that the DID private key can only be used after passing biometric authentication. When the DID private key needs to be used, first obtain the The biometrics entered by the user, and then sent to the biometric authentication server for authentication, if passed, the DID private key can be used, otherwise, the DID private key cannot be used; but this method requires a centralized biometric authentication server to Biometrics are used for authentication, so it must be connected to the Internet, which limits the use of some offline or weak network scenarios. Moreover, since the key can only be used after being approved by the centralized biometric authentication server, it contradicts the decentralization of the DID system.

Based on this, the embodiment of this specification provides a DID-based payment method, which can realize biometric authentication locally, and after the authentication is passed, use the DID private key to sign the payment request, thereby realizing the payment function through DID, ensuring safety.

As shown in Figure 1, the embodiment of this specification provides a DID-based payment method, the method is applied to a payment application, the payment application is installed on a mobile terminal, and the payment application is embedded with a DID SDK, and the method includes step:

S100: Generate a payment request.

In some embodiments, the payment application may be a payment application. The payment request may be triggered by the user operating the payment application, or by the user operating a third-party application linked to the payment application. For example, the payment application can be Alipay, and the third-party application can be Meituan, Ele.me, etc. The payment request can be initiated directly by the user through Alipay, or initiated by the third-party application through Alipay.

S200: Obtain the biometric feature input by the user to be authenticated.

The payment application can realize the collection of biometrics by calling the system API (application programming interface). Specifically, after a payment request is generated, the payment application can call the system API for collecting biometrics and invoke the collection interface. The user inputs the biometrics to be authenticated through the biometric sensor on the mobile terminal, and the payment application obtains the biometrics to be authenticated through the system API. .

In some embodiments, the biometric acquisition and authentication can be implemented based on the Internet Finance Authentication Alliance (IFAA). The IFAA Alliance is committed to launching a "financial-level, full-link, standardized" industry security solution around identity authentication technology, and establishing a trusted connection for the Internet of Everything. IFAA is a financial-grade mobile biometric product. It uses the computing power embedded in the hardware encryption area of the mobile terminal, combined with the native fingerprint, face recognition and other biometric capabilities of the device, to perform financial-level and hardware-level identity authentication.

In some embodiments, an IFAA SDK (Software Development Kit) may be embedded in the payment application, and the payment application may implement biometric functions by calling the IFAA SDK, such as obtaining the biometrics input by the user, and identifying the biometrics or authentication and so on.

S300: Using the DID SDK, compare the biometrics to be authenticated with the DID standard biometrics pre-stored in the TEE (Trusted Execution Environment) by the DID SDK.

DID SDK is used to implement DID functions, including DID registration, generation of verifiable statement (VC), storage of DID private key, encryption of data with DID private key, etc. After obtaining the biometrics to be authenticated, the payment application can use the DIDSDK to compare the biometrics to be authenticated with the DID standard biometrics pre-stored in the TEE by the DID SDK (that is, authentication), so as to determine whether the DID private key can be used according to the comparison result.

S400: When the first local comparison result is obtained through the DID SDK and the first local comparison result is the same, the DID SDK uses the pre-stored DID private key to sign the payment request, so as to realize the payment function through the DID.

When the DID SDK obtains the local first comparison result, and the local first comparison result is the same, it means that the biometrics to be authenticated are the same as the DID standard biometrics. After passing the authentication, the DID private key can be used, so the pre-stored one can be used through the DID SDK. The DID private key signs the payment request to realize the payment function through DID. If the local first comparison result obtained by the DID SDK is different, it means that the biometrics to be authenticated are different from the DID standard biometrics, and the user cannot use the DID private key, so he will not use the DID private key to sign the payment request. The payment function cannot be realized through DID, thereby realizing the protection of the DID private key, and because the DID standard biometric feature is pre-stored in the local TEE, the entire comparison process is completed locally, and it can be realized without networking (extended without network or weak network usage scenarios), and there is no dependence on centralized biometric authentication servers (decentralization).

In some scenarios, the mobile terminal may not support local comparison. At this time, the authentication can also be completed through the centralized biometric authentication server. In some embodiments, when the DID SDK cannot obtain the first local comparison result, the method further includes:

The payment application can send the biometrics to be authenticated to the DID server through the DID SDK, and the DID server will compare the biometrics to be authenticated with the DID standard biometrics pre-existing in the DID server to obtain the server comparison result, and then compare the server The result is sent to the DID SDK; the payment application receives the server-side comparison result through the DID SDK. If the server-side comparison result is the same, it means that the biometrics to be authenticated are the same as the DID standard biometrics. If the authentication is passed, the payment application can use the pre-stored DID through the DID SDK The private key signs the payment request to realize the payment function through DID; if the comparison result of the server is different, it means that the biometrics to be authenticated are different from the DID standard biometrics, the authentication fails, and the DID private key cannot be used. At this time, the DID server acts as a biometric authentication server to achieve centralized authentication.

In some embodiments, DID standard biometrics can be obtained through a provisioning process, which includes steps:

S402: Receive a DID biometric authentication activation request through the DID SDK;

S404: Obtain the payment standard biometric feature stored in the TEE by the payment application itself;

S406: Store the payment standard biometric feature in the TEE as the DID standard biometric feature through the DID SDK.

That is to say, the DID biometric authentication function needs to be enabled before the biometric feature can be used to protect the DID private key from being stolen. The above-mentioned activation process is usually completed before payment.

Since the biometric authentication function is a mature function on the mobile terminal, the method in this specification can be implemented on the basis of the existing biometric authentication function. In some embodiments, the biometric authentication SDK is embedded in the payment application (the following uses the IFAA SDK as an example), and the IFAA SDK can realize the payment biometric authentication of the payment application. On this basis, the method of this specification can realize the DID private key Biometric authentication without having to modify the underlying framework of the biometric authentication function of the mobile terminal. For example, after receiving the DID biometric authentication activation request, the payment application can obtain the payment standard biometrics stored in the TEE by the IFAA SDK through the IFAA SDK, and then send the payment standard biometrics to the IFAA server through the IFAA SDK, and the IFAA server The payment standard biometrics will be sent to the DID server, and the DID server will store the payment standard biometrics as the DID standard biometrics, and then send the payment standard biometrics to the DID SDK, which will be stored in the TEE by the DID SDK as the DID standard biometrics. In this way, both the DID server and the local store have DID standard biometrics, and the activation process is completed.

If the payment application itself has not enabled biometric authentication during the activation process, then in step S404, the payment standard biometric feature cannot be obtained. At this time, it is necessary to enable the biometric authentication of the payment application first, that is, obtain the biometric input entered by the user through the IFAA SDK. characteristics, which are then stored in the TEE as payment standard biometrics via the IFAA SDK.

In some embodiments, the method may also include an update process, so that users can update the DID standard biometrics according to their own needs, and the update process includes steps:

S502: Receive a DID biometric authentication update request through the DID SDK;

S504: Obtain the first biological feature input by the user;

S506: Using the DID SDK to compare the first biometric feature with the DID standard biometric feature to obtain a second local comparison result;

S508: Acquire a second biological feature input by the user when the second local comparison result is the same;

S510: Using the DID SDK, store the second biometric feature in the TEE as a new DID standard biometric feature.

When the user wants to update the DID standard biometric feature, the biometric authentication update request can be triggered through the DID SDK, and then the payment application will obtain the user's first biometric feature for authentication to ensure that the update process is triggered by the user corresponding to the DID standard biometric feature After passing the authentication, you can enter the new DID standard biometrics to complete the update.

In the DID-based payment method of the embodiment of this specification, the DID private key can be used to sign the payment request after the biometric authentication is passed, so as to ensure that the DID private key is not stolen, thereby ensuring payment security; the biometric authentication can be completed locally, Instead of relying on a centralized server or network.

As shown in FIG. 2 , another embodiment of this specification provides a DID-based payment device, including a generation module 10 , an acquisition module 20 , a comparison module 30 and a signature module 40 .

The generating module 10 is used for generating payment requests.

In some embodiments, the payment application may be a payment application. The payment request may be triggered by the user operating the payment application, or by the user operating a third-party application linked to the payment application. For example, the payment application can be Alipay, and the third-party application can be Meituan, Ele.me, etc. The payment request can be initiated directly by the user through Alipay, or initiated by the third-party application through Alipay.

The obtaining module 20 is used to obtain the biometric feature input by the user to be authenticated.

The payment application can realize the collection of biometrics by calling the system API (application programming interface). Specifically, after a payment request is generated, the payment application can call the system API for collecting biometrics and invoke the collection interface. The user inputs the biometrics to be authenticated through the biometric sensor on the mobile terminal, and the payment application obtains the biometrics to be authenticated through the system API. .

In some embodiments, the IFAA SDK can be embedded in the payment application, and the payment application can implement biometric functions by calling the IFAA SDK, such as obtaining the biometric features input by the user, identifying or authenticating the biometric features, and so on.

The comparison module 30 is used to compare the biometrics to be authenticated with the DID standard biometrics pre-stored in the TEE (Trusted Execution Environment) by the DID SDK.

The signature module 40 is used to sign the payment request with the pre-stored DID private key through the DID SDK when the first local comparison result is obtained through the DID SDK and the first local comparison result is the same, so as to realize the payment function through the DID.

When the DID SDK obtains the local first comparison result, and the local first comparison result is the same, it means that the biometrics to be authenticated are the same as the DID standard biometrics. After passing the authentication, the DID private key can be used, so the pre-stored one can be used through the DID SDK. The DID private key signs the payment request to realize the payment function through DID. If the local first comparison result obtained by the DID SDK is different, it means that the biometrics to be authenticated are different from the DID standard biometrics, and the user cannot use the DID private key, so he will not use the DID private key to sign the payment request. The payment function cannot be realized through DID, thereby realizing the protection of the DID private key, and because the DID standard biometric feature is pre-stored in the local TEE, the entire comparison process is completed locally, and it can be realized without networking (extended without network or weak network usage scenarios), and there is no dependence on centralized biometric authentication servers (decentralization).

In some scenarios, the mobile terminal may not support local comparison. At this time, the authentication can also be completed through the centralized biometric authentication server. In some embodiments, the device also includes a server-side comparison module. When the DID SDK cannot obtain the first local comparison result, the server-side module can send the biological characteristics to be authenticated to the DID server through the DID SDK, so that the DID service The terminal compares the biometrics to be authenticated with the DID standard biometrics pre-existed in the DID server, obtains the comparison result of the server, and then sends the comparison result of the server to the DID SDK; the server module receives the comparison result of the server through the DID SDK, if the service The comparison result of the terminal is the same, indicating that the biometrics to be authenticated are the same as the DID standard biometrics. If the authentication is passed, the server module can use the pre-stored DID private key to sign the payment request through the DID SDK, so as to realize the payment function through DID; if the server The comparison result is different, indicating that the biometrics to be authenticated are different from the DID standard biometrics, the authentication fails, and the DID private key cannot be used. At this time, the DID server acts as a biometric authentication server to achieve centralized authentication.

In some embodiments, the DID standard biometric feature can be obtained through a provisioning process, and the device can include a provisioning module, the provisioning module is used for:

Receive DID biometric authentication activation request through DID SDK;

Obtain the payment standard biometrics stored in the TEE by the payment application itself;

The payment standard biometrics are stored in the TEE as DID standard biometrics through the DID SDK.

In some embodiments, the IFAA SDK is embedded in the payment application, which is used to realize the payment biometric authentication of the payment application. For example, after receiving the DID biometric authentication activation request, the activation module can obtain the payment standard biometrics stored in the TEE by the IFAA SDK through the IFAA SDK, and then send the payment standard biometrics to the IFAA server through the IFAA SDK, and the IFAA server The payment standard biometrics will be sent to the DID server, and the DID server will store the payment standard biometrics as the DID standard biometrics, and then send the payment standard biometrics to the DID SDK, which will be stored in the TEE by the DID SDK as the DID standard biometrics. In this way, both the DID server and the local store have DID standard biometrics, and the activation process is completed.

If the payment application itself has not enabled biometric authentication during the activation process, then in step S404, the payment standard biometric feature cannot be obtained. At this time, it is necessary to enable the biometric authentication of the payment application first, that is, obtain the biometric input entered by the user through the IFAA SDK. characteristics, which are then stored in the TEE as payment standard biometrics via the IFAA SDK.

In some embodiments, the device may also include an update module, so that users can update the DID standard biometrics according to their own needs, and the update module is used for:

Receive DID biometric authentication update request through DID SDK;

Obtaining the first biometric feature input by the user;

Comparing the first biometric feature with the DID standard biometric feature through the DID SDK to obtain a second local comparison result;

When the second local comparison result is the same, acquire a second biological feature input by the user;

The second biological feature is stored in the TEE as a new DID standard biological feature through the DID SDK.

The biological features involved in the biometric authentication described in the embodiments of this specification may include, for example, eye features, voiceprints, fingerprints, palmprints, heartbeat, pulse, chromosomes, DNA, human teeth bite marks, and the like. The eye pattern may include biological characteristics such as iris and sclera.

The DID-based payment device in the embodiment of this specification can only use the DID private key to sign the payment request after the biometric authentication is passed, so as to ensure that the DID private key is not stolen, thereby ensuring payment security; the biometric authentication can be completed locally, Instead of relying on a centralized server or network.

Another embodiment of this specification provides a readable storage medium on which a computer program is stored. When the computer program is executed in a computer, the computer is made to execute the steps of the DID-based payment method in the above-mentioned embodiments of this specification.

Another embodiment of this specification provides an electronic device, which includes a memory and a processor, and executable code is stored in the memory. When the processor executes the executable code, it executes the DID-based payment method in the above-mentioned embodiments of this specification. A step of.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or Combinations of any of these devices.

For the convenience of description, when describing the above devices, functions are divided into various units and described separately. Of course, when implementing this specification, the functions of each unit can be implemented in one or more pieces of software and/or hardware.

Those skilled in the art should understand that the embodiments of this specification may be provided as methods, systems, or computer program products. Accordingly, this description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The specification is described with reference to flowcharts and/or block diagrams of methods, devices (systems), and computer program products according to embodiments of the specification. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic tape cartridge, tape magnetic disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

Those skilled in the art should understand that the embodiments of this specification may be provided as methods, systems or computer program products. Accordingly, this description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The present description may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, refer to part of the description of the method embodiment.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

The above descriptions are only preferred embodiments of this specification, and are not intended to limit the scope of this specification. Various changes can also be made to the above embodiments of this specification. That is to say, all simple and equivalent changes and modifications made according to the claims of the application in this specification and the content of the specification fall within the scope of protection of the claims of the patent in this specification. Everything that is not described in detail in this manual is conventional technical content.

Claims (10)

1. A DID-based payment method applied to a payment application installed on a mobile terminal, the payment application having a DID SDK embedded therein, the method comprising:

generating a payment request;

acquiring a to-be-authenticated biological characteristic input by a user;

comparing the to-be-authenticated biological characteristics with DID standard biological characteristics of a TEE pre-stored in the DID SDK through the DID SDK;

and when a first local comparison result is obtained through the DID SDK and the first local comparison result is the same, signing the payment request through the DID SDK by adopting a pre-stored DID private key so as to realize a payment function through the DID.

2. The DID-based payment method of claim 1, further comprising, prior to generating the payment request:

receiving a DID biometric authentication opening request through the DID SDK;

acquiring a payment standard biometric of the payment application stored in the TEE;

and storing the payment standard biometric as a DID standard biometric in the TEE by the DID SDK.

3. The DID-based payment method according to claim 2, further comprising:

receiving a DID biometric update request through the DID SDK;

acquiring a first biological characteristic input by a user;

comparing the first biological characteristic with the DID standard biological characteristic through the DID SDK to obtain a second local comparison result;

when the second local comparison result is the same, acquiring a second biological feature input by the user;

the second biometric feature is stored as a DID standard biometric feature in the TEE by the DID SDK.

4. The DID-based payment method of claim 1, further comprising, when the DID SDK fails to obtain the first local comparison result:

the to-be-authenticated biological feature is sent to a DID server through the DID SDK, so that the DID server compares the to-be-authenticated biological feature with a pre-stored DID standard biological feature to obtain a server comparison result, and the server comparison result is sent to the DID SDK;

receiving the server side comparison result through the DID SDK;

and when the comparison results of the server are the same, signing the payment request by adopting a pre-stored DID private key through the DID SDK so as to realize the payment function through the DID.

5. A DID-based payment device applied to a payment application installed on a mobile terminal, the payment application having a DID SDK embedded therein, the device comprising:

the generation module is used for generating a payment request;

the acquisition module is used for acquiring the to-be-authenticated biological characteristics input by the user;

the comparison module is used for comparing the to-be-authenticated biological characteristics with DID standard biological characteristics of the DID SDK pre-stored in a TEE through the DID SDK;

and the signature module is used for signing the payment request by adopting a pre-stored DID private key through the DID SDK when a first local comparison result is obtained through the DID SDK and the first local comparison result is the same, so that the payment function is realized through the DID.

6. The DID-based payment device of claim 5, further comprising an provisioning module to:

receiving a DID biometric authentication opening request through the DID SDK;

acquiring a payment standard biometric of the payment application stored in the TEE;

and storing the payment standard biometric as a DID standard biometric in the TEE by the DID SDK.

7. The DID-based payment device of claim 6, further comprising an update module to:

receiving a DID biometric update request through the DID SDK;

acquiring a first biological characteristic input by a user;

comparing the first biological characteristic with the DID standard biological characteristic through the DID SDK to obtain a second local comparison result;

when the second local comparison result is the same, acquiring a second biological feature input by the user;

the second biometric feature is stored as a DID standard biometric feature in the TEE by the DID SDK.

8. The DID-based payment device of claim 5, further comprising a server side comparison module configured to:

when the DID SDK cannot obtain the first local comparison result, the to-be-authenticated biological feature is sent to a DID server through the DID SDK, so that the DID server compares the to-be-authenticated biological feature with a pre-stored DID standard biological feature to obtain a server comparison result, and the server comparison result is sent to the DID SDK;

receiving the server side comparison result through the DID SDK;

and when the comparison results of the server are the same, signing the payment request by adopting a pre-stored DID private key through the DID SDK so as to realize the payment function through the DID.

9. A readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the steps of the DID-based payment method as claimed in any one of claims 1 to 4.

10. An electronic device comprising a memory and a processor, the memory having executable code stored therein, which when executed by the processor performs the steps of the DID-based payment method of any one of claims 1-4.