Information transmission method, and communication apparatus and storage medium

Abstract

The present application relates to the technical field of communications. Provided are an information transmission method, and a communication apparatus and a storage medium, which can allow a digital identity to be published in a distributed ledger on the basis of a telecommunication network. The method comprises: a first apparatus sending verification request information of a digital identity to a second apparatus, and receiving verification response information of the digital identity from the second apparatus, wherein the verification request information comprises a public key of the digital identity of the first apparatus and a first signature, and the first signature is obtained by means of signing the verification request information on the basis of a private key of the digital identity; and when the verification response information indicates that the first signature is successfully verified on the basis of the public key of the digital identity, the first apparatus further sending publishing request information of the digital identity, and receiving publishing response information of the digital identity, wherein the publishing request information comprises the public key of the digital identity and a second signature, and the second signature is obtained by means of signing the publishing request information on the basis of the private key of the digital identity.

Description

Information transmission methods, communication devices and storage media

[0001] This application claims priority to Chinese Patent Application No. 202510084595.1, filed on January 17, 2025, entitled "Information Transmission Method, Communication Device and Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, specifically to an information transmission method, communication device, and storage medium. Background Technology

[0003] Currently, users need to maintain multiple independent identities across various business sectors, including communication technology (CT), information technology (IT), and offline services. Service providers also need to maintain identity information for all users within their respective service scopes. The difficulty in interoperability between identities across different services creates management and maintenance costs for both users and service providers. With the development of digital technology, decentralized identity trust frameworks are gaining increasing attention in the industry. How to create user identities is a question worth considering. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this application provide an information transmission method, a communication device, and a storage medium, which enable the creation of user identities.

[0005] Firstly, an information transmission method is provided. This method can be executed by a first device, a component of the first device (such as its processor, chip, or chip system), or a logic module or software capable of implementing all or part of the first device. The following description uses the execution of this method by the first device as an example. The information transmission method includes: the first device sending a digital identity verification request to a second device and receiving a digital identity verification response from the second device. The verification request includes the public key of the first device's digital identity and a first signature, which is obtained by signing the verification request based on the private key of the digital identity. If the verification response indicates successful verification of the first signature based on the public key of the digital identity, the first device further sends a digital identity credential request to a third device and receives a digital identity credential response. The credential request includes the public key of the digital identity, and the credential response includes information about a first credential, which is obtained by signing the digital identity based on the private key of the third device.

[0006] In the information transmission method provided in this application embodiment, the first device can request the second device to verify the digital identity of the first device based on verification request information. If the verification of the first signature based on the public key of the digital identity is successful, that is, if the verification of the digital identity held by the first device based on the verification request information is successful, the first device sends a credential request information for the digital identity to the third device. This allows the first credential (i.e., a credential obtained by signing the digital identity based on the private key of the third device) issued by the third device to obtain information from the third device. In other words, the third device endorses the digital identity, and the issuance of the first credential is completed online, thereby realizing the creation of a user identity. Furthermore, in the information transmission method described in this application embodiment, the first credential is issued only after the second device successfully verifies the digital identity held by the first device based on the verification request information, rather than being issued arbitrarily. This improves the security of issuing the first credential.

[0007] In conjunction with the first aspect above, in one possible implementation, the credential request information is further used to request the publication of a digital identity on the distributed ledger, and the credential response information is further used to indicate that the digital identity has been successfully published on the distributed ledger, so that the first device can clearly know through the credential response information that the digital identity has been successfully published on the distributed ledger, so that the first device can use the digital identity to achieve interoperability and mutual trust in the future.

[0008] In conjunction with the first aspect above, in one possible implementation, the verification request information further includes one or more of the following: credential information of the manufacturer of the user identification module of the first device, the public key credential of the user identification module, or a third signature; the third signature is obtained by signing the verification request information based on the private key of the user identification module; the manufacturer's credential information is used to verify the public key credential of the user identification module, and the public key in the public key credential of the user identification module is used to verify the third signature.

[0009] In other words, in this implementation, after receiving the verification request information, the second device can not only verify the first signature based on the public key of the digital identity, but also verify the public key certificate of the user identification module based on the credential information of the manufacturer of the user identification module of the first device, and verify the third signature based on the public key in the public key certificate of the user identification module. In this way, multiple verifications can be performed on the digital identity of the first device, thereby improving the accuracy of the verification results of the digital identity of the first device.

[0010] In conjunction with the first aspect above, in one possible implementation, sending the credential request information for the digital identity includes: the first device sending the credential request information to the third device through the network to which the second device belongs, in order to request the third device to trigger the publication of the digital identity, and the third device can be an authoritative institution, thus enabling the publication of the digital identity on the distributed ledger through the authoritative institution.

[0011] In conjunction with the first aspect above, in one possible implementation, the verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs. In this way, the first device can obtain the first token through the verification response information and carry the first token when sending credential request information to the third device through the network to which the second device belongs. This allows the receiving end (e.g., the third device) to determine whether the digital identity is a digital identity that is allowed to access the network to which the second device belongs by verifying the first token, thereby ensuring the security of the credential request information.

[0012] In conjunction with the first aspect above, in one possible implementation, the credential request information also includes the user's real-person verification information, so that the receiving end (e.g., a third device) can verify the user's true identity based on the user's real-person verification information, thereby ensuring the legitimacy of the digital identity; and / or, the credential request information also includes the user's subscription permanent identifier (SUPI), so that a correspondence between the user's SUPI and the digital identity can be established through the user's SUPI, thereby facilitating the operator network to trace the corresponding digital identity through the user's SUPI and thus determine the user's identity.

[0013] In conjunction with the first aspect above, in one possible implementation, the first device sends a digital identity publication request message and receives a digital identity publication response message. The publication request message includes a first credential and is used to request the publication of the digital identity on the distributed ledger. The publication response message is also used to indicate that the digital identity has been successfully published on the distributed ledger. In this way, the first device can directly request the publication of the digital identity on the distributed ledger through the first credential to know that the digital identity has been successfully published on the distributed ledger, so that the first device can use the digital identity to achieve interoperability and mutual trust in the future.

[0014] In conjunction with the first aspect above, in one possible implementation, after receiving the credential response information of the digital identity, the method provided in this application embodiment further includes: the first device sending a contract request information and receiving a contract response information, wherein the contract request information includes information of the first credential, the first credential being used to verify the digital identity, so that the first device can sign a contract with the network to which the second device belongs through the first credential, so that the first device can subsequently use the services provided by the network to which the second device belongs.

[0015] Secondly, an information transmission method is provided. This method can be executed by a second device, or by a component of the second device, such as a processor, chip, or chip system, or by a logic module or software capable of implementing all or part of the second device. The following description uses the execution of this method by a second device as an example. The information transmission method includes: the second device receiving verification request information of a digital identity from a first device. The verification request information includes the public key of the digital identity of the first device and a first signature, wherein the first signature is obtained by signing the verification request information based on the private key of the digital identity. The second device verifies the first signature based on the public key of the digital identity and sends verification response information of the digital identity to the first device. The verification response information indicates that the verification of the first signature based on the public key of the digital identity was successful.

[0016] In conjunction with the second aspect above, in one possible implementation, the verification request information further includes the public key credential of the user identification module of the first device and a third signature, wherein the third signature is obtained by signing the verification request information based on the private key of the user identification module; the method provided in this application embodiment further includes: the second device verifying the third signature based on the public key in the public key credential of the user identification module.

[0017] In conjunction with the second aspect above, in one possible implementation, the digital authentication request information further includes the credential information of the manufacturer of the user identification module of the first device and the public key credential of the user identification module; the method provided in this application embodiment further includes: the second device verifying the public key credential of the user identification module based on the credential information of the manufacturer.

[0018] In conjunction with the second aspect above, in one possible implementation, the method provided in this application embodiment further includes: a second device receiving credential request information for a digital identity from a first device and sending the credential request information to a third device; wherein the credential request information includes the public key of the digital identity; the second device receiving credential response information for a digital identity from a third device, the credential response information including information of a first credential, and sending the credential response information to the first device, wherein the first credential is obtained by signing the digital identity based on the private key of the third device.

[0019] In conjunction with the second aspect above, in one possible implementation, the credential request information is also used to request the publication of a digital identity on the distributed ledger, and the credential response information is also used to indicate that the digital identity has been successfully published on the distributed ledger.

[0020] In conjunction with the second aspect above, in one possible implementation, the verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs.

[0021] In conjunction with the second aspect described above, in one possible implementation, after sending the digital identity verification response information to the first device, the method provided in this application embodiment further includes: the second device receiving signing request information from the first device, the signing request information including information about a first credential, the first credential being obtained by signing the digital identity based on the private key of a third device. The second device verifies the first credential based on the public key of the third device, and sends signing response information to the first device based on the verification result.

[0022] The technical effects of the second aspect or any of its implementations can be found in the technical effects of the corresponding implementations of the first aspect, and will not be repeated here.

[0023] Thirdly, an information transmission method is provided. This method can be executed by a third device, or by a component of the third device, such as a processor, chip, or chip system of the third device, or by a logic module or software capable of implementing all or part of the third device. The following description uses the execution of this method by a third device as an example. The information transmission method includes: the third device receiving credential request information for a digital identity from a first device; the credential issuance request information includes the public key of the digital identity of the first device. The third device signs the digital identity using its private key to obtain a first credential, and sends credential response information for the digital identity to the first device, the credential response information including information about the first credential.

[0024] In conjunction with the third aspect above, in one possible implementation, the method provided in this application embodiment further includes: a third device triggering the publication of a digital identity on a distributed ledger, the digital identity including a first credential; credential response information is further used to indicate that the digital identity has been successfully published on the distributed ledger.

[0025] In conjunction with the third aspect above, in one possible implementation, the credential request information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs, and the method further includes: verifying the first token.

[0026] In conjunction with the third aspect above, in one possible implementation, receiving the credential request information for the digital identity from the first device includes receiving the credential request information for the digital identity from the first device sent through the network to which the second device belongs; sending the credential response information for the digital identity to the first device includes sending the credential response information for the digital identity to the first device through the network to which the second device belongs.

[0027] In conjunction with the third aspect mentioned above, in one possible implementation, the credential request information includes a second signature. Sending credential response information of the digital identity to the second device includes: if the verification of the second signature based on the public key of the digital identity is successful, the third device sends credential response information to the second device to verify whether the first device is the holder of the public key of the digital identity. If the verification of the second signature based on the public key of the digital identity is successful, the third device sends credential response information to the first device. This can ensure the security of the first credential request process as much as possible.

[0028] The technical effects of the third aspect or any of the implementation methods in the third aspect can be referred to the technical effects of the corresponding implementation methods in the first aspect, and will not be repeated here.

[0029] Fourthly, an information transmission method is provided. This method can be executed by a first device, or by a component of the first device, such as a processor, chip, or chip system of the first device, or by a logic module or software capable of implementing all or part of the first device. The following description uses the execution of this method by the first device as an example. The information transmission method includes: the first device sending a credential request message for its digital identity to a third device, and receiving a credential response message for its digital identity from the third device. The credential request message includes the public key of the first device's digital identity; the credential response message includes information about a first credential, which is obtained by signing the digital identity based on the private key of the third device.

[0030] In the information transmission method provided in this application embodiment, the first device sends a digital identity credential request information to the third device so that the first credential (i.e., the credential obtained by signing the digital identity based on the third device's private key) issued by the third device can be obtained from the third device. In other words, the third device completes the endorsement of the digital identity, and then completes the issuance of the first credential online, thereby realizing the creation of the user identity.

[0031] In conjunction with the fourth aspect above, in one possible implementation, the method provided in this application embodiment further includes: a first device sending a digital identity publication request information and receiving a digital identity publication response information, wherein the publication request information is used to request the publication of the first device's digital identity on the distributed ledger, and the publication request information includes the public key of the first device's digital identity.

[0032] In conjunction with the fourth aspect above, in one possible implementation, the digital identity of the first device published on the distributed ledger is used to verify the credential request information. This allows the credential request information to be verified again before the digital identity is published on the distributed ledger, further ensuring the security of the digital identity published on the distributed ledger.

[0033] In conjunction with the fourth aspect above, in one possible implementation, a response message is published to indicate that the digital identity has been successfully published on the distributed ledger.

[0034] In conjunction with the fourth aspect above, in one possible implementation, sending a digital identity publication request message includes: the first device sending the publication request message to nodes in the distributed ledger network.

[0035] In conjunction with the fourth aspect above, in one possible implementation, the first device sends a contract request message and receives a contract response message, wherein the contract request message includes information about a first credential, which is used to verify the digital identity.

[0036] The technical effects of the fourth aspect or any of its implementations can be found in the technical effects of the corresponding implementations of the first aspect, and will not be repeated here.

[0037] Fifthly, an information transmission method is provided. This method can be executed by nodes in a distributed ledger network, or by components of nodes in the distributed ledger network, such as processors, chips, or chip systems of nodes in the distributed ledger network, or by logic modules or software capable of implementing all or part of the nodes in the distributed ledger network. The following description uses the execution of this method by nodes in a distributed ledger network as an example. The information transmission method includes: a node in the distributed ledger network receiving credential request information for a digital identity from a first device, and responding to the credential response information for the digital identity of the first device, wherein the credential request information includes the public key of the digital identity of the first device. Optionally, the credential request information may further include a second signature, which is obtained by signing the publication request information based on the private key of the digital identity.

[0038] In conjunction with the fifth aspect above, in one possible implementation, the credential response information is used to indicate the successful issuance of a digital identity on the distributed ledger.

[0039] The technical effects of the fifth aspect or any of the implementation methods of the fifth aspect can be seen in the technical effects of the corresponding implementation methods of the first aspect and / or the technical effects of the corresponding implementation methods of the fourth aspect, and will not be repeated here.

[0040] Sixthly, an information transmission method is provided. This method can be executed by a third device, or by a component of the third device, such as a processor, chip, or chip system of the third device, or by a logic module or software capable of implementing all or part of the third device. The following description uses the execution of this method by a third device as an example. The information transmission method includes: the third device receiving credential request information for a digital identity from a first device, the credential request information including the public key of the digital identity of the first device; the third device signing the digital identity according to its private key to obtain a first credential, and sending credential response information for the digital identity to the first device, the credential response information including information about the first credential.

[0041] In conjunction with the sixth aspect above, in one possible implementation, after receiving the credential request information and before sending the credential response information, the third device verifies that the digital identity has been successfully published on the distributed ledger.

[0042] In conjunction with the sixth aspect above, in one possible implementation, after obtaining the first credential, the method further includes: a third device triggering the publication of the first credential information on the distributed ledger to update the digital identity-related information in the distributed ledger, so that subsequent verifiers can obtain the first credential information from the distributed ledger.

[0043] The technical effects of the sixth aspect or any of its implementations can be found in the technical effects of the corresponding implementations of the first aspect and / or the corresponding implementations of the fourth aspect, and will not be repeated here.

[0044] In a seventh aspect, a communication device is provided for implementing the various methods described above. This communication device may be a first device under the first aspect, or any implementation thereof; or, it may be a second device under the second aspect, or any implementation thereof; or, it may be a third device under the third aspect, or any implementation thereof; or, it may be a first device under the fourth aspect, or any implementation thereof; or, it may be a node in a distributed ledger network under the fifth aspect, or any implementation thereof; or, it may be a third device under the sixth aspect, or any implementation thereof. The communication device includes modules, units, or means corresponding to the methods described above, which may be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0045] In some possible designs, the communication device may include a processing module and a transceiver module. The transceiver module, also referred to as a transceiver unit, is used to implement the transmission and / or reception functions in any of the above aspects and their possible implementations. The transceiver module may consist of transceiver circuits, transceivers, transceivers, or communication interfaces. The processing module can be used to implement the processing functions in any of the above aspects and their possible implementations.

[0046] In some possible designs, the transceiver module includes a sending module and a receiving module, which are used to implement the sending and receiving functions in any of the above aspects and any possible implementation methods.

[0047] Eighthly, a communication device is provided, comprising: a processor and a memory; the memory being configured to store computer instructions, which, when executed by the processor, enable the communication device to be a first device according to the first aspect above, or any implementation thereof; or, the communication device to be a second device according to the second aspect above, or any implementation thereof; or, the communication device to be a third device according to the third aspect above, or any implementation thereof; or, the communication device to be a first device according to the fourth aspect above, or any implementation thereof; or, the communication device to be a node in a distributed ledger network according to the fifth aspect above, or any implementation thereof; or, the communication device to be a third device according to the sixth aspect above, or any implementation thereof.

[0048] In one possible implementation, the processor and memory are integrated together.

[0049] A ninth aspect provides a communication device, comprising: at least one processor; the processor being configured to execute a computer program or instructions stored in a memory, and / or to configure, via logic circuitry, the communication device to be a first device of the first aspect or any implementation thereof; or, the communication device to be a second device of the second aspect or any implementation thereof; or, the communication device to be a third device of the third aspect or any implementation thereof; or, the communication device to be a first device of the fourth aspect or any implementation thereof; or, the communication device to be a node in a distributed ledger network of the fifth aspect or any implementation thereof; or, the communication device to be a third device of the sixth aspect or any implementation thereof.

[0050] A tenth aspect provides a communication device, comprising: a processor and a communication interface; the communication interface being configured to communicate with a module outside the communication device; the processor being configured to execute computer programs or instructions such that the communication device may be a first device according to the first aspect above, or any implementation thereof; or, the communication device may be a second device according to the second aspect above, or any implementation thereof; or, the communication device may be a third device according to the third aspect above, or any implementation thereof; or, the communication device may be a first device according to the fourth aspect above, or any implementation thereof; or, the communication device may be a node in a distributed ledger network according to the fifth aspect above, or any implementation thereof; or, the communication device may be a third device according to the sixth aspect above, or any implementation thereof.

[0051] Eleventhly, a computer-readable storage medium is provided, which stores a computer program or instructions that, when executed on a communication device, cause the method of any of the above aspects or any implementation thereof to be implemented.

[0052] In a twelfth aspect, a computer program product containing instructions is provided that, when run on a communication device, enables the communication device to execute any of the above aspects or any implementation thereof.

[0053] In a thirteenth aspect, a communication device is provided (e.g., the communication device may be a chip (such as a modem chip, also known as a baseband chip) or a chip system (such as a system-on-chip (SoC) chip containing a modem core or a system-in-package (SIP) chip)), the communication device including a processor for implementing the functions involved in any of the above aspects or any implementation thereof.

[0054] In some possible designs, the communication device includes a memory for storing necessary program instructions and data.

[0055] In some possible designs, when the device is a chip system, it can be composed of chips or contain chips and other discrete components.

[0056] It is understood that when the communication device provided by any of the seventh to thirteenth aspects is a chip, the aforementioned transmitting action / function can be understood as an output, and the aforementioned receiving action / function can be understood as an input.

[0057] In a fourteenth aspect, an information transmission method is provided, comprising the method of the first aspect or any implementation thereof, and the method of the second aspect or any implementation thereof.

[0058] In a fifteenth aspect, a communication system is provided, comprising the first means, the second means, the third means, and a node in the distributed ledger network described above.

[0059] The technical effects of any of the implementation methods in aspects seven through fifteen can be found in the technical effects of the corresponding implementation method in aspect one, and will not be repeated here.

[0060] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0061] Figure 1 is a schematic diagram of a VC data model proposed by the World Wide Web Consortium (W3C) according to an embodiment of this application;

[0062] Figure 2 is a schematic diagram of constructing a digital identity blockchain on a telecommunications network according to an embodiment of this application;

[0063] Figure 3 is a schematic diagram of a possible, non-limiting communication system provided in an embodiment of this application;

[0064] Figure 4 is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0065] Figure 5 is a schematic flowchart of an information transmission method provided in an embodiment of this application;

[0066] Figure 6 is a schematic flowchart of another information transmission method provided in an embodiment of this application;

[0067] Figure 7 is a schematic flowchart of another information transmission method provided in an embodiment of this application;

[0068] Figure 8 is a schematic flowchart of another information transmission method provided in an embodiment of this application;

[0069] Figure 9 is a schematic flowchart of another information transmission method provided in an embodiment of this application;

[0070] Figure 10 is a schematic flowchart of another information transmission method provided in an embodiment of this application;

[0071] Figure 11 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0072] To facilitate understanding of the technical solutions provided in the embodiments of this application, a brief introduction to the relevant technologies of this application is given first. The brief introduction is as follows:

[0073] To better understand the methods provided in this application, a brief explanation of some of the terms used in this application is provided below.

[0074] 1. Distributed Ledger (DL)

[0075] A distributed ledger is a database maintained by multiple nodes, recording transactions between nodes in a distributed ledger network to ensure data consistency and security. Unlike traditional centralized databases, distributed ledgers do not require an authoritative institution to manage the data. Instead, they rely on each node in the distributed ledger network to jointly verify, store, and update the data, thus improving data transparency, security, and immutability.

[0076] 2. Blockchain

[0077] Blockchain is a form of distributed ledger technology. It generates and stores data in units of blocks, linking them chronologically into a chain-like data structure, and using cryptography to ensure the data's immutability and tamper-proof nature. Any blockchain can run (or be deployed) on multiple blockchain nodes. In other words, a blockchain can be maintained by multiple blockchain nodes, which can share the ledger and participate in transactions, block storage, verification, and forwarding. When a new block is created in the blockchain, it needs consensus confirmation from multiple blockchain nodes and is broadcast throughout the blockchain to synchronize data. After that, the block cannot be changed or deleted, thus ensuring the blockchain's immutability.

[0078] 3. Smart Contracts (SC)

[0079] The immutability, consensus mechanism, and distributed nature of blockchain have spurred the development of SC (Signal Controller) technology. SC is a computer protocol that can be deployed on a blockchain to disseminate, verify, or execute contracts in an informational manner. By declaring business logic within SC, corresponding operations can be executed. SC allows for trusted transactions without a third party; these transactions are traceable and irreversible. Specifically, SC is a piece of executable code that can be installed and run on blockchain nodes. Leveraging the characteristics of blockchain, this executable code can be deployed on an account address on the blockchain. When a call transaction is initiated to this address, the transaction is verified and the corresponding program code is executed within the blockchain network under the constraints of the consensus mechanism, thus ensuring the determinism and uniqueness of the execution result.

[0080] Understandably, blockchain's decentralized nature allows code built on top of SC to become a decentralized application (DApp). The emergence of DApps has changed the architecture of internet applications, shifting application deployment from a centralized, single-service-provider model to a decentralized, distributed one. Currently, several decentralized versions of internet applications already exist.

[0081] 4. Digital Identity

[0082] Digital identity includes identifiers (IDs), documents, and visual identity (VCs). Documents and VCs can be collectively referred to as an overview. A detailed explanation follows:

[0083] An identifier can be used to identify the subject of the digital identity. This ID can be a globally unique identifier. For example, the ID format can be a universally unique identifier (UUID), or a format specified by the Hypertext Transfer Protocol (HTTP), or a Uniform Resource Identifier (URI), or a subscriber permanent identifier (SUPI), or an international mobile subscriber identity (IMSI), or an international mobile equipment identity (IMEI), a permanent equipment identifier (PEI), or a subscription concealed indenter (SUCI), or other formats specified by the 3rd Generation Partnership Project (3GPP). The ID can also be a DID, or an identifier for a client in a distributed ledger, etc., as included but not limited to these in this application. The ID can be generated by the subject of the digital identity, or it can be generated by an issuer (such as an operator). This application does not impose any restrictions on this. The digital identity can be stored on the distributed ledger in the form of key-value pairs. At this point, the ID can be used as an index for digital identity, and can be used to find the document and VC corresponding to that ID in the distributed ledger.

[0084] The document includes publicly disclosed descriptive information about the holder of this digital identity. This includes, but is not limited to, the following information:

[0085] The subject can include the name of the terminal holder, such as a company or department.

[0086] Subject type is used to represent the type of subject of digital identity, such as terminal, digital human, IoT device, network function (NF), radio access network (RAN) node, organization, etc.

[0087] The subject controller is used to represent the actual controller of the subject of the digital identity. For example, user 1 controls the digital identity of subject 1. In this case, the identifier of the digital identity can be the identifier of subject 1, and the identifier of the subject controller can be the identifier of user 1.

[0088] Verification methods are used for different verification purposes / relationships (e.g., authentication, assertion and key protocols, authorization, etc.) to verify the key used to authenticate a user's identity. Generally, the entity that generates the identifier of the digital identity can also generate the corresponding key for authentication. For example, if the entity generates an asymmetric key, the public key can be placed in this field.

[0089] A VC can include public key credentials. A public key credential (PK credential) refers to a public key certificate issued by a trusted third party and held by the holder of the digital identity, such as a certificate issued by an operator for a user, or a certificate issued by an authoritative institution for a user. The above is an exemplary description of a VC; other credentials may also be included in a VC, and this application embodiment does not limit this.

[0090] The above is a brief introduction to the relevant technologies of this application.

[0091] With the development of digital technology, decentralized identity trust frameworks have gradually attracted industry attention. Decentralized identity trust frameworks are based on asymmetric keys, where users generate their own identity information locally and then authenticate this information with a service provider / organization to obtain a verifiable credential (VC). The verification process of this credential typically does not require the real-time participation of the issuer. Instead, the issuer can publish its own verification tool (e.g., an issuer's public key certificate), and any third party can verify the VC based on this tool. For multiple different verifiers, such as different operators or third parties, users can use the corresponding VC from their digital identity for verification. Therefore, users can flexibly create identities for different occasions, or use the same identity in different situations. Identity is managed and controlled autonomously by the user, no longer restricted to binding to a specific business / identity provider.

[0092] The decentralized identity trust framework has the following key features: First, compared to existing centralized identity management methods, neither issuers nor verifiers centrally store user identity information (e.g., usernames and passwords). Instead, identity information and VCs are stored locally by the user, thus avoiding the risks of sensitive data leakage and single points of failure. Second, based on a publicly trusted database (e.g., blockchain), issuers with multiple participants only need to publish verification tools. The publication and management of these tools are independent and publicly available, achieving decoupling between issuers and verifiers and enabling cross-domain, multi-party identity verification. More importantly, users truly manage their own identity information, selectively creating different identity information and VCs as needed, decoupling user identity from issuers. Furthermore, users can present their VCs to any service provider as needed, enabling cross-domain, multi-party service access and truly realizing digital identity sovereignty.

[0093] Figure 1 is a schematic diagram of the VC data model proposed by the World Wide Web Consortium (W3C). This model illustrates the issuer, holder, verifier, and verifiable data registry platform. The user (i.e., the holder) generates a public-private key pair. The issuer can issue the user's public key certificate (i.e., public key credential) based on the user's public key. The issuer can sign the user's public key with its own private key to obtain a VC and provide it to the user. The holder can package the public key certificate with other identity information to form a decentralized identity (DID) document. This DID document can be stored on the verifiable data registry platform and assigned a unique DID. Various VCs can also be associated with the DID. The issuer of the VC also possesses its decentralized identity, and the verifier can verify the holder's VC using the issuer's DID's public key, thus forming a trusted closed loop.

[0094] As can be seen from the above, issuers can provide VC to users, but issuers usually provide VC to users offline, which will cause great inconvenience to the verification of user identity. Furthermore, in general technology, there is no clear and explicit limitation on how issuers issue VC to users.

[0095] Based on industry-leading digital identity technologies, telecommunications networks, as ubiquitous global connectivity infrastructure, can serve as the infrastructure for digital identity, enabling the construction of a telecommunications network blockchain to support digital identity services. Figure 2 is a schematic diagram illustrating the construction of a digital identity blockchain on a telecommunications network according to an embodiment of this application. As shown in Figure 2, the digital identity blockchain connects multiple trusted institutions, including but not limited to operators (OPs), device manufacturers (DMs), card manufacturers (e.g., embedded UICC (eUICC) manufacturers (EUM)), social authorities (SAs), and trusted third parties (3rd parties) (e.g., hospitals, universities, enterprises). These social authorities form a trusted alliance and publish the public key certificates of the trusted institutions (e.g., the operator's public key certificate) to the blockchain.

[0096] The user's digital identity can include an identifier and an overview. For example, the user can generate their own public-private key pair, using a public key hash or a unified identifier issued by a social authority as the identifier of their digital identity. The overview can include a VC issued (or signed) by various trusted institutions. For instance, a VC issued by a social authority can prove that the user is a legal citizen; a VC issued by a mobile operator can prove that the user is the holder of a mobile phone number; and a VC issued by a university can prove that the user is a student of that university. These VCs can be obtained by a trusted institution signing them using its own private key, and they can also be verified by the trusted institution using its own public key. Since the trusted institution's public key certificate is published on the blockchain, the user's VC can be universally verified, thereby achieving interoperability and mutual trust in identity.

[0097] Based on digital identities, users can access the telecommunications network and use a unified card across multiple operators. Users can also flexibly choose their network operator based on their current location, signal strength, and billing status, achieving ubiquitous access. Operators can improve service quality and gain a better user experience through fair competition. Users can customize verifiable minimal disclosure credentials, endorsed by trusted institutions (such as operators), protecting user privacy. IT services, CT services, and offline services do not require maintaining large amounts of user data, reducing security risks and increasing user trust. IT services can achieve rapid authentication based on telecommunications network software development kits (SDKs) or contactless network access. Operators transform from contracted user identity managers to unified identity maintainers and user trust endorsers. Higher trust levels allow participation in trust building and monetization.

[0098] As previously mentioned, user identities can be published via telecommunications networks, enabling ubiquitous verification of user identity verification (VCs) and thus achieving identity interoperability and mutual trust. However, if issuers and holders publish user identities separately via telecommunications networks, this can lead to a significant amount of redundant information in databases such as distributed ledgers.

[0099] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0100] To facilitate understanding of the embodiments of this application, the following points will be explained before introducing the embodiments of this application.

[0101] 1. In the embodiments of this application, for ease of description, when numbering is involved, it can start from 1 and be numbered consecutively, or it can start from 0 and be numbered from any parameter. It should be understood that the above are settings made for the convenience of describing the technical solutions provided in the embodiments of this application, and are not intended to limit the scope of the embodiments of this application.

[0102] 2. The “protocol” (which may also be referred to as a technical specification or standard) involved in the embodiments of this application can refer to standard protocols in the field of communications, such as the Long Term Evolution (LTE) protocol, the New Radio (NR) protocol, the 3rd Generation Partnership Project (3GPP) protocol, and related protocols applied to future communication systems. The embodiments of this application do not limit this.

[0103] 3. In the embodiments of this application, the descriptions such as "when," "under the circumstances," "if," and "if" all refer to the fact that the device (e.g., the second device, the first device, or the third device) will perform corresponding processing under certain objective circumstances. They are not time limits, nor do they require the device (e.g., the second device, the first device, or the third device) to have a judgment action when it is implemented, nor do they mean that there are other limitations.

[0104] 4. In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. The "and / or" in the embodiments of this application is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Furthermore, in the description of the embodiments of this application, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a to b, a to c, b to c, or a to b to c, where a, b, and c can be single or multiple. Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0105] The method provided in this application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, Frequency Division Duplex (FDD) systems, Time Division Duplex (TDD) systems, 5th Generation (5G) mobile communication systems, or New Radio Access Technology (NR). Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networks.

[0106] The technical solutions provided in this application can also be applied to machine-type communication (MTC), long-term evolution-machine (LTE-M) technology, device-to-device (D2D) networks, machine-to-machine (M2M) networks, Internet of Things (IoT) networks, or other networks. IoT networks, for example, can include vehicle-to-everything (V2X) networks. The communication methods in V2X systems are collectively referred to as vehicle-to-other-device (V2X) systems, where X can represent anything. For example, V2X can include vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-pedestrian (V2P) communication, or vehicle-to-network (V2N) communication. The technical solutions provided in this application can also be applied to future communication systems. This application does not impose any limitations on this application.

[0107] Furthermore, the communication architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of communication architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0108] Figure 3 is a schematic diagram of the architecture of a communication system applicable to the method provided in this application. The communication system includes a terminal-side device 301, a RAN-side device 302, a core network-side device 303, and a third-party device 304. The terminal-side device 301 can communicate with the core network-side device 303 through the RAN-side device 302. The third-party device 304 can act as a node in a distributed ledger network. Other nodes in the distributed ledger network can also be included in the communication system; these other nodes can be used to publish user information in the distributed ledger, but this embodiment does not limit this.

[0109] In this device, terminal-side device 301 (e.g., mobile phones, drones, smart cars, or virtual digital humans, digital assistants, software phones, cloud phones, etc.) holds a digital wallet. This digital wallet can be embedded in a universal integrated circuit card (UICC) or installed on the terminal as software (an application, APP). The terminal (or UICC) can generate public and private keys to serve as the public and private keys for this digital wallet.

[0110] The core network side device 303 may include, but is not limited to, identity management (IDM) network elements, distributed ledger enable function (DLEF), archive node, network function (NF), ledger anchor function (LAF) network elements, security edge protection proxies (SEPP), etc.

[0111] In this system, the IDM can be responsible for signing and endorsing user information. For example, after the user-generated public key is sent to the network, the IDM can use the operator's private key to sign and generate a user public key certificate endorsed by the operator. Furthermore, the IDM can also be responsible for the user's contract with the operator's network, and other network elements can also be responsible for this contract; this application does not impose any limitations on this.

[0112] DLEF is a node in a distributed ledger that can receive digital identity information from IDMs or terminal vendors and publish this information to the distributed ledger. DLEF can store all the data in the distributed ledger. For example, in a digital identity blockchain, DLEF can store all the blockchain data.

[0113] Ledger nodes can be private nodes of the operator. They can work with the distributed ledger to complete data storage and can also be used to store private information.

[0114] SEPP is a crucial component of the 5G roaming security architecture. Located at the network edge, it ensures secure interoperability between users and other operators' networks during roaming. It is responsible for message filtering and policy management at the control plane interfaces between operators. SEPP acts as a bridge between the control planes of different operators.

[0115] The interface definitions between the various network elements are as follows:

[0116] The IDM has an interface with the terminal and can manage the identity and credentials from the terminal. For example, the terminal can register or publish digital identity information with the DLEF through the IDM, which includes the terminal's digital identity and credentials (such as VC); the terminal can also apply to the IDM for the issuance or revocation of credentials, such as the terminal requesting a public key certificate from the IDM (i.e., an example of applying for the issuance of credentials); the terminal can also apply to the IDM to process or compute verifiable presentations (VPs) on behalf of others.

[0117] IDM also has interfaces with other network functions (NFs). When the holder of identity and credentials is an NF, IDM can be responsible for managing the identity and credentials of that NF.

[0118] The IDM also has an interface with the DLEF. The IDM is responsible for sending digital identity information to the DLEF for the terminal or NF. The IDM can also query information stored in the distributed ledger from the DLEF.

[0119] DLEF has an interface with the terminal. As a storage network element (such as a blockchain node) in the distributed ledger, DLEF can be responsible for the publication of the terminal's digital identity information and the terminal's query for information stored in the distributed ledger.

[0120] DLEF also has an interface with NF, and when the holder of digital identity information is an NF, it is responsible for publishing the digital identity information of that NF.

[0121] DLEF also has an interface with IDM, and DLEF is responsible for receiving digital identity information of terminals or NFs issued by IDM.

[0122] DLEF also has an interface with Security Edge Protection Proxies (SEPP). In this embodiment, DLEF needs to share data with its peer DLEF through the interface with SEPP.

[0123] It should be understood that Figure 3 is merely an example, illustrating some network elements in the core network. These network elements are divided from a functional perspective; in actual deployment, they can be independent or integrated. This application does not impose any restrictions on this.

[0124] Furthermore, although not shown in the diagram, it should be understood that DLEF is only one possible form of deploying the DLE module as an independent entity in the core network. The DLE module can also be an internal module, deployed in terminal-side devices, RAN-side devices, or core network-side devices.

[0125] Third-party device 304 may include trusted institutions, such as authoritative institutions, included in the digital identity blockchain shown in Figure 2 above. The third-party device is primarily responsible for endorsing the user's digital identity. For example, after the public key of the user's generated digital identity is sent to the third-party device, the third-party device can use its private key to sign the user's digital identity, obtaining a public key certificate of the user's digital identity endorsed by the operator.

[0126] However, for the first, second, and third devices described in the embodiments of this application, for example, referring to FIG3, the first device may correspond to a terminal-side device, RAN-side device, or NF in the core network-side device that wishes to publish its digital identity in the distributed ledger. The second device may be responsible for verifying the user's digital identity. For example, the second device may correspond to the IDM in the core network-side device, or the second device may correspond to the application function (AF) in the core network-side device, which may be an interface opened by the operator to third-party devices. The third device may be responsible for signing and endorsing the user's information. For example, the third device may correspond to the SA or other trusted authoritative institutions, and the embodiments of this application do not limit this.

[0127] In one possible implementation, the first device, the second device, and the third device in the embodiments of this application may also be referred to as communication devices, which may be a general-purpose device or a special-purpose device. The embodiments of this application do not limit this.

[0128] In one possible implementation, the functions of the first, second, and third devices in the embodiments of this application can be implemented by one device, by multiple devices, or by one or more functional modules within a single device. The embodiments of this application do not impose any limitations on this. It is understood that the aforementioned functions can be network elements in hardware devices, software functions running on dedicated hardware, a combination of hardware and software, or virtualization functions instantiated on a platform (e.g., a cloud platform).

[0129] For example, the functions of the first, second, and third devices in the embodiments of this application can be implemented by the communication device 410 in FIG. 4. FIG. 4 shows a schematic diagram of a possible communication device. It is understood that the communication device 410 includes necessary means such as modules, units, elements, circuits, or interfaces, to be appropriately configured together to execute the solution. The communication device 410 may be the first, second, or third device described in the embodiments of this application, or other devices, or it may be a component (e.g., a chip) in these devices to implement the methods described in the following method embodiments. The communication device 410 includes one or more processors 411. The processor 411 may be a general-purpose processor or a special-purpose processor, etc. For example, it may be a baseband processor or a central processing unit. The baseband processor may be used to process communication protocols and communication data, and the central processing unit may be used to control the communication devices (e.g., the first, second, and third devices, etc.), execute software programs, and process data of the software programs.

[0130] Optionally, in one design, the processor 411 may include a program 413 (sometimes also referred to as code or instructions), which can be executed on the processor 411 to cause the communication device 410 to perform the methods described in the embodiments below. In another possible design, the communication device 410 includes circuitry (not shown in FIG4) for implementing the communication functions in the embodiments below.

[0131] Optionally, the communication device 410 may include one or more memories 412 storing a program 414 (sometimes referred to as code or instructions), which can be run on the processor 411 to cause the communication device 410 to perform the methods described in the following method embodiments.

[0132] Optionally, the processor 411 and / or memory 412 may include an artificial intelligence (AI) module 417 and an AI module 418, which are used to implement AI-related functions. The AI ​​module 417 or 418 can be implemented through software, hardware, or a combination of both. For example, the AI ​​module 417 or 418 may include a radio intelligent controller (RIC) module. For example, the AI ​​module 417 or 418 can be a near real-time RIC or a non-real-time RIC.

[0133] Optionally, data may also be stored in the processor 411 and / or the memory 412. The processor and memory may be configured separately or integrated together.

[0134] Optionally, the communication device 410 may also include a transceiver 415 and / or an antenna 416. The processor 411, sometimes referred to as a processing unit, controls the communication devices (e.g., the first device, the second device, and the third device). The transceiver 415, sometimes referred to as a transceiver unit, transceiver, transceiver circuit, or transceiver, is used to implement the transmission and reception functions of the communication device via the antenna 416.

[0135] The information transmission method provided in the embodiments of this application will be described in detail below with reference to Figure 5.

[0136] It should be noted that the message names, parameter names, or information names between network elements in the following embodiments of this application are merely examples, and may be other names in other embodiments. The method provided in this application does not limit these names. It is understood that in the embodiments of this application, each network element may execute some or all of the steps in the embodiments of this application. These steps or operations are examples, and the embodiments of this application may also execute other operations or variations thereof. Furthermore, the steps may be executed in different orders as presented in the embodiments of this application, and may not necessarily involve executing all the operations in the embodiments of this application.

[0137] Figure 5 illustrates an example of the information transmission method provided in this application. The method is described using the interaction between a first device and a second device as an example. Of course, the entity executing the action of the first device in this method can also be a terminal-side device, or a component within the terminal-side device, such as a processor, chip, or chip system of the terminal-side device, or a logic module or software capable of implementing all or part of the terminal-side device. Similarly, the entity executing the action of the second device in this method can also be a core network-side device (such as an IDM), or a component within the core network-side device, such as a processor, chip, or chip system of the core network-side device, or a logic module or software capable of implementing all or part of the core network-side device. This application does not impose any limitations on these aspects.

[0138] For example, as shown in Figure 5, the information transmission method includes the following steps:

[0139] S501, the first device sends a digital identity verification request to the second device. Correspondingly, the second device receives the digital identity verification request from the first device.

[0140] The aforementioned digital identity verification request information can be used to request verification of the digital identity (e.g., the public key of the digital identity) held by the first device. The digital identity verification request information includes the public key of the first device's digital identity and a first signature. The first signature is obtained by signing the verification request information based on the private key of the digital identity. Specifically, the first device can first calculate the hash value of the verification request information, and then sign the verification request information based on the private key of the digital identity to obtain the first signature. It should be understood that the signature operation described in the embodiments of this application can be understood as first calculating the hash value of the information (e.g., the verification request information), and then signing the information; the embodiments of this application do not limit this to a specific method.

[0141] In some optional implementations, the digital identity verification request information (which may be referred to as verification request information) may also be referred to as network access request information, network access verification (authentication) request information, provision request information, configuration verification request information, etc. The above is an exemplary description of alternative names for verification request information. Verification request information may also be replaced with other names, and this application embodiment does not limit this.

[0142] In some possible implementations, the digital identity of the first device (hereinafter referred to as digital identity) may be a digital identity generated by the first device itself for the user to whom the first device belongs, a digital identity generated by the first device itself for the first device, a digital identity generated by the first device itself for a device attached to the first device, or a digital identity generated by the first device itself for a user attached to the first device. This application embodiment does not impose any limitations on this. Furthermore, the device attached to the first device may be a physical device or a virtual device, and this application embodiment does not impose any limitations on this.

[0143] It is understood that the digital identity involved in the embodiments of this application can be understood as a ubiquitous identity. This digital identity can be managed by the user and is not strongly bound to a verification party (e.g., an operator's network).

[0144] S502, the second device sends a digital identity verification response to the first device. Correspondingly, the first device receives the digital identity verification response from the second device.

[0145] Optionally, after receiving the verification request information, the second device performs verification based on the verification request information and sends verification response information to the first device.

[0146] Furthermore, optionally, verification based on the verification request information can also be understood as verifying the digital identity (e.g., the public key of the digital identity) held by the first device based on the verification request information. Specifically, the first signature is verified based on the public key of the digital identity to confirm whether the first device is the holder of the public key. Therefore, in this embodiment, verifying the digital identity held by the first device can also be understood as verifying the first signature based on the public key of the digital identity, and so on without further elaboration.

[0147] Further, optionally, the verification response information for the digital identity is used to indicate the result of verifying the digital identity (e.g., the public key of the digital identity) held by the first device. Specifically, the verification response information for the digital identity is used to indicate the result of verifying the first signature based on the public key of the digital identity. That is, if the verification of the digital identity held by the first device by the second device is successful, the verification response information indicates that the verification of the digital identity held by the first device is successful; if the verification of the digital identity held by the first device by the second device fails, the verification response information indicates that the verification of the digital identity held by the first device fails. The result of verifying the first signature based on the public key of the digital identity can be understood with reference to the above description, and will not be repeated here.

[0148] Optionally, the verification involved in the embodiments of this application may also replace authentication, auditing, or other descriptions, and the embodiments of this application do not limit this. Similarly, the verification success involved in the embodiments of this application may also replace authentication success, verification passed, authentication passed, or other descriptions, and the embodiments of this application do not limit this.

[0149] In some optional implementations, the digital identity verification response information (which may be referred to as verification response information) may also be called network access response information, network access verification (authentication) response information, provision response information, configuration verification response information, etc. The above is an exemplary description of alternative names for verification response information. Verification response information may also be replaced with other names, and this application embodiment does not limit this.

[0150] S503. If the verification response information indicates that the verification of the first signature based on the public key of the digital identity is successful, the first device sends a credential request message for the digital identity. Correspondingly, the third device receives the credential request message for the digital identity.

[0151] Optionally, the verification response information may also indicate that the verification of the first signature based on the public key of the digital identity failed. However, if the verification response information indicates that the verification of the first signature based on the public key of the digital identity failed, the first device re-determines and resends the verification request information for the digital identity, so that the second device can perform a second verification based on the verification request information for the digital identity re-reported by the first device. Alternatively, the first device may perform other operations, which are not limited in this embodiment. The credential request information is used to request endorsement (also known as signing, issuing credential, etc.) of the digital identity (such as the public key of the digital identity). The credential request information may also be called an endorsement request, an issuing credential request, etc.

[0152] The credential request information includes the public key of the digital identity. This credential request information may also include a second signature, which is obtained by signing the credential request information based on the private key of the digital identity. This allows a third device to verify the second signature based on the public key of the digital identity, thereby verifying whether the first device is the holder of the public key of the digital identity. If the verification of the second signature based on the public key of the digital identity is successful, the third device sends credential response information to the first device. This approach maximizes the security of the first credential request process.

[0153] Optionally, the third device receives the credential request information, endorses the digital identity to obtain the first credential, and returns the first credential to the first device. Endorsing the digital identity specifically involves signing the digital identity (e.g., the public key of the digital identity) using the private key of the third device to obtain the first credential. It should be understood that the signature required to obtain the first credential is at least a signature on the public key of the digital identity, but it can also be a signature on other content of the digital identity; this application does not limit this.

[0154] Optionally, the third device can also verify the second signature based on the public key of the digital identity, and perform the endorsement operation as described above only after successful verification of the second signature. Alternatively, the third device can specifically be a device of an authority trusted by the operator. The third device can communicate with the first device through the operator's network.

[0155] Optionally, the first device can send the credential request information to the third device through the network to which the second device belongs. In this embodiment, after the second device successfully verifies the digital identity (e.g., the public key of the digital identity), the first device then requests the third device to endorse the digital identity. That is, after the first device passes the verification by the second device using the digital identity, it can communicate through the network to which the second device belongs.

[0156] As an alternative approach, the third device can also be a device within the operator capable of providing endorsement. In this implementation, the third device and the second device can be different devices; alternatively, they can be the same device. If the third device and the second device are the same device, the verification request information and the credential request information can be the same message. That is, after receiving the verification request information, the second device performs the verification based on the verification request information (e.g., verifying the first signature based on the public key of the digital identity). If the verification is successful, the second device signs the digital identity (e.g., the public key of the digital identity) based on its private key to obtain the first credential and returns the information of the first credential to the first device.

[0157] For example, the first credential can also be called a digital identity issuance license credential or a digital identity uplink license credential. The above are exemplary descriptions of other names for the first credential. The first credential can also be called a public key credential for the digital identity of a third device, and this application embodiment does not limit this.

[0158] S504, the third device sends the digital identity credential response information. Correspondingly, the first device receives the digital identity credential response information.

[0159] The credential response information can be used to instruct the first device on the aforementioned first credential. That is, the credential response information may include information about the first credential. Specifically, the information about the first credential may be the first credential itself, or information used to identify the first credential. For example, the information about the first credential may specifically be the identifier of the digital identity, or the address of the digital identity in the distributed ledger. Further, optionally, the first device may also request the publication of the digital identity on the distributed ledger. Publishing the digital identity on the distributed ledger can be understood as publishing the public key of the digital identity, the identifier of the digital identity, the information of the first credential, and other specific content of the digital identity on the distributed ledger. The specific content of the digital identity can be found in the terminology description. The source of each piece of information in the digital identity may be generated by the first device and communicated to the third device, or it may be obtained by the third device itself; this application embodiment does not limit this. For example, the identifier of the digital identity, that is, the identifier of the subject of the digital identity, may be generated by the first device (e.g., the identifier of the digital identity is the hash value of the public key); the first credential is the aforementioned public key credential.

[0160] Among the alternative implementations, there are several ways for the first device to request the publication of its digital identity on the distributed ledger:

[0161] Implementation Method 1: After receiving the first credential, the first device requests to publish a digital identity on the distributed ledger based on the first credential. For example, the first device publishes the digital identity on the distributed ledger through nodes in the distributed ledger network based on the first credential request. Specifically, the first device sends a digital identity publication request to the nodes in the distributed ledger network. This publication request information includes the first credential and is used to request the publication of the digital identity on the distributed ledger. Optionally, the publication request information also includes other content of the digital identity, such as the identifier of the digital identity. The nodes in the distributed ledger network can invoke a smart contract to publish the digital identity and send a publication response to the first device. The publication response information also indicates that the digital identity has been successfully published on the distributed ledger. For example, a node in the distributed ledger network obtains the public key of a third device, verifies the first credential using the public key of the third device, and publishes the digital identity on the distributed ledger after successful verification of the first credential.

[0162] Implementation Method 2: The first device publishes a digital identity on the distributed ledger through a third device. For example, the credential request information is also used to request the publication of the digital identity on the distributed ledger; that is, after obtaining the aforementioned first credential, the third device triggers the publication of the digital identity on the distributed ledger. Specifically, the third device invokes a smart contract for publishing the digital identity to publish the digital identity on the distributed ledger. It should be understood that consensus nodes in the distributed ledger network also invoke smart contracts for consensus-building, etc., which will not be elaborated upon in this application.

[0163] Furthermore, the third device instructs the first device on the result of publishing the digital identity on the distributed ledger. It should be understood that, as one implementation, the aforementioned credential response information can also be used to indicate the result of publishing the digital identity on the distributed ledger; that is, the credential response information can also be used to indicate successful publication of the digital identity on the distributed ledger, or it can also be used to indicate unsuccessful publication of the digital identity on the distributed ledger. In this case, the credential request information can also be called the digital identity publication request information, and the credential response information can also be called the digital identity publication response information. Other examples of names for the credential request information or credential response information may also exist. The publication of the digital identity on the distributed ledger can be understood by referring to the descriptions in the corresponding positions above, and will not be repeated here.

[0164] When a digital identity is successfully published on a distributed ledger, the aforementioned credential response information enables the first device to know that the digital identity has been successfully published on the distributed ledger (such as a blockchain), so that the first device can subsequently use the digital identity to achieve interoperability and mutual trust. However, in addition to indicating successful digital identity publication, the credential response information can also indicate failure in digital identity publication. For example, the credential response information can be used to indicate failure in digital identity publication on the distributed ledger, or it can be used to indicate failure in digital identity publication on the blockchain.

[0165] For example, taking a distributed ledger as a blockchain: the successful publication of a digital identity on the distributed ledger can be understood as the successful publication of the digital identity in the form of a block within the blockchain. This block can include one or more transactions, and the digital identity can be processed into a transaction (understood as belonging to one of the one or more transactions included in the block), and then packaged into a block.

[0166] In addition, digital identities can be published not only on distributed ledgers or blockchains, but also distributed in distributed databases, such as the Interplanetary File System (IPFS) database. This application does not limit this.

[0167] In the information transmission method provided in this application embodiment, the first device can request the second device to verify the digital identity of the first device based on verification request information. If the verification of the first signature based on the public key of the digital identity is successful, that is, if the verification of the digital identity held by the first device based on the verification request information is successful, the first device sends a credential request information for the digital identity to the third device. This allows the first credential (i.e., a credential obtained by signing the digital identity based on the private key of the third device) issued by the third device to obtain information from the third device. In other words, the third device endorses the digital identity, and the issuance of the first credential is completed online, thereby realizing the creation of a user identity. Furthermore, in the information transmission method described in this application embodiment, the first credential is issued only after the second device successfully verifies the digital identity held by the first device based on the verification request information, rather than being issued arbitrarily. This improves the security of issuing the first credential.

[0168] The following provides further details regarding the verification request information.

[0169] In addition to the public key of the digital identity and the first signature, the verification request information may also include other information. Specifically, the verification request information may further include: the public key credential (or the public key of the user identification module of the first device), and a third signature. The third signature is obtained by signing the verification request information based on the private key of the user identification module. The public key credential of the user identification module includes the public key of the user identification module of the first device, which is used to verify the third signature. Accordingly, after receiving the verification request information, the second device can also verify the third signature based on the public key of the user identification module.

[0170] Furthermore, the verification request information may also include: the public key credential of the user identification module (or the public key of the user identification module of the first device), and the credential information of the manufacturer of the user identification module. The credential information of the manufacturer of the user identification module is used to verify the public key credential of the user identification module, and the public key credential of the user identification module includes the aforementioned public key of the user identification module; that is, the public key of the manufacturer of the user identification module is used to verify the public key of the user identification module. Accordingly, after receiving the verification request information, the second device can also verify the public key credential of the user identification module based on the credential information of the manufacturer of the user identification module. This determines the legitimacy of the public key credential of the user identification module, that is, it determines that the user identification module comes from a legitimate manufacturer.

[0171] In some possible implementations, the credential information of the user identification module manufacturer can specifically be the credential of the user identification module manufacturer itself, or information used to identify the manufacturer of the user identification module, such as the identifier of the credential of the user identification module manufacturer. Specifically, the second device can determine the locally stored credential of the user identification module manufacturer or obtain the credential of the user identification module manufacturer from the distributed ledger based on the identifier of the credential of the user identification module manufacturer. This application embodiment does not limit this. The credential of the user identification module manufacturer can specifically be the public key, root certificate, or root certificate credential of the user identification module manufacturer (card vendor), etc., and this application embodiment does not limit this.

[0172] Based on the above method, multiple verifications can be performed on the digital identity of the first device, thereby improving the security of the digital identity of the first device. It should be understood that the functions of the aforementioned verification request information and verification response information can be further expanded accordingly. Further details will not be elaborated further.

[0173] In some examples, the user identification module involved in the embodiments of this application may include a subscriber identity module (SIM) card, an embedded subscriber identity module (eSIM) card, a universal integrated circuit card (UICC), an embedded universal integrated circuit card (eUICC), or a virtual subscriber identity module (vSIM). Of course, the above is an exemplary description of the user identification module involved in the embodiments of this application. The user identification module may also include other devices for identifying user identity, such as a universal subscriber identity module (USIM), and the embodiments of this application do not impose limitations on this.

[0174] The first device typically includes a user identification module. When the first device includes a user identification module, the verification request information may include at least one of the following: the manufacturer's credentials for the user identification module, the public key credentials for the user identification module, or a third signature, to facilitate multiple verifications of the digital identity by the second device. Alternatively, the verification request information may not include the manufacturer's credentials for the user identification module, the public key credentials for the user identification module, or at least one of a third signature, to save communication overhead; this application embodiment does not impose such limitations.

[0175] However, in scenarios where the first device is a virtual UE or a cloud UE, there is no need to deploy a user identification module in the first device. Therefore, there is no credential information of the manufacturer of the aforementioned user identification module, the public key credential of the user identification module, or the third signature. Consequently, the verification request information does not include the credential information of the manufacturer of the aforementioned user identification module, the public key credential of the user identification module, or the third signature. As a result, the second device does not need to verify the legitimacy of the card vendor or equipment vendor of the aforementioned user identification module.

[0176] Optionally, the above is an exemplary description of the information included in the verification request information. The verification request information may also include other information, such as type information, which is used to indicate that the type of the information is for requesting verification of the digital identity held by the first device, or the information type information is used to indicate that the type of the information is a provisioning type (also referred to as a verification request type, etc.), which is for requesting verification of the digital identity held by the first device. This application embodiment does not limit this.

[0177] Optionally, the first device may encrypt all or part of the information in the verification request information to obtain encrypted verification request information, and then send the encrypted verification request information to the second device. Correspondingly, the second device receives the encrypted verification request information from the first device.

[0178] Further, optionally, the process by which the first device encrypts all or part of the information in the verification request information can be as follows: The first device determines the public key of the network to which the second device belongs (denoted as the first network public key) to be used when calculating the key for encrypting the verification request information, based on information related to the public key of the network to which the second device belongs (e.g., a list of public keys (PK) of the operator (OP)). The first device generates a temporary public-private key pair, which includes a temporary public key (PK-temporary) and a temporary private key (SK-temporary). The first device can calculate the key for encrypting the verification request information based on the first network public key and the temporary private key generated by the first device, and encrypt the verification request information based on the key for encrypting the verification request information.

[0179] Furthermore, the key used to encrypt different verification request messages can be the same, or the key used to encrypt different verification request messages can be different; this application embodiment does not impose any restrictions on this. The public key list of the network to which the second device belongs may include all or part of the public keys held by the network to which the second device belongs, while the first network public key can be any public key in the public key list of the network to which the second device belongs; this application embodiment does not impose any restrictions on this.

[0180] Accordingly, in this implementation, after receiving the encrypted verification request information from the first device, the second device decrypts the encrypted verification request information. Optionally, the process of the second device decrypting the encrypted verification request information can be as follows: the second device obtains the temporary public key generated by the first device and the private key corresponding to the first network public key, calculates a key for decrypting the verification request information based on the temporary public key generated by the first device and the private key corresponding to the first network public key, and decrypts the encrypted verification request information based on the key used to decrypt the verification request information.

[0181] Furthermore, the key used to encrypt the verification request information and the key used to decrypt the verification request information can be the same or different, and this application embodiment does not impose any restrictions on this.

[0182] As described above regarding the "encryption or decryption verification request information," the verification request information may also include other information, such as the identifier of the temporary public key generated by the first device and the public key of the network to which the second device belongs, so that the second device can determine the information used to calculate the decryption verification request information using the temporary public key generated by the first device and the public key of the network to which the second device belongs. The above is an exemplary description of the verification request information; the verification request information may also include other information, and this application embodiment does not limit this.

[0183] Optionally, the temporary public key generated by the first device and the public key of the network to which the second device belongs can be plaintext information in the verification request information, so that the second device can conveniently and quickly obtain the information used to calculate and decrypt the verification request information. Information in the verification request information other than the identifiers of the temporary public key generated by the first device and the public key of the network to which the second device belongs can be ciphertext information in the verification request information. For example, the public key of the digital identity, the first signature, the credential information of the user identification module manufacturer, the public key credential of the user identification module, and the third signature can all be ciphertext information in the verification request information.

[0184] The following provides further explanation of the verification response information.

[0185] In one alternative implementation, the verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs, and the credential request information includes the first token.

[0186] In some possible implementations, the first token may also be used to indicate one or more of the following: allowing the first device to send a credential request to the third device through the network to which the second device belongs, verifying the first signature through the network to which the second device belongs, verifying the first signature successfully based on the public key of the digital identity, or indicating that the first device has successfully verified the digital identity (e.g., the public key therein).

[0187] For example, the first token can be a token obtained by signing the public key of the network to which the second device belongs. Further, taking the network to which the second device belongs as an operator network as an example, the first token can include at least one of the following information: the operator's identifier (e.g., public land mobile network identification (PLMN ID)), the identifier of the first device, the validity period of the first token, or the type of the first token (e.g., the type of the first token is the type that authorizes a third device to issue a digital identity).

[0188] The above is an exemplary description of the first token and the information included in the first token. The first token may also be other tokens or may include other information, such as the verifier information of the first token (e.g., the identifier of the verifier of the first token). This application embodiment does not limit this.

[0189] However, in another alternative implementation, the verification response information may not include the first token, but instead directly indicate that the first device is allowed to access the network to which the second device belongs. That is, the verification response information may include first information (also referred to as approved information), which indicates that the first device is allowed to access the network to which the second device belongs. In this implementation, after receiving the verification response information, the first device can directly access the network to which the second device belongs by default, without needing to include the first token in the credential request information. Consequently, the second device can also directly provide services to the first device by default, without needing to verify the first token.

[0190] The above is an exemplary description of the verification response information. The verification response information may also include other information, such as the public key of the digital identity, the public key of the second device, or the identifier of the network to which the second device belongs.

[0191] Furthermore, the verification response information may also include a fifth signature. The first device can then verify the fifth signature based on the public key of the second device to verify the validity of the verification response information (such as the first token therein). This fifth signature is obtained by the second device signing the verification response information based on its private key. The first device can obtain the public key of the second device from the distributed ledger, or the verification response information may include the public key of the second device. That is, the first device can obtain the public key of the second device through the verification response information, or the second device can send its public key to the first device separately. This application embodiment does not impose any limitations on this.

[0192] Optionally, the second device may encrypt all or part of the information in the verification response information to obtain encrypted verification response information, and then send the encrypted verification response information to the first device. Correspondingly, the first device receives the encrypted verification response information from the second device.

[0193] Further, optionally, the second device can encrypt the verification response information as follows: the second device obtains the temporary public key generated by the first device and the private key corresponding to the first network public key, calculates the key for encrypting the verification response information based on the temporary public key generated by the first device and the private key corresponding to the first network public key, and encrypts the verification response information based on the key for encrypting the verification response information.

[0194] However, in this implementation, after the first device receives the encrypted verification response information from the second device, it needs to decrypt the encrypted verification response information. Optionally, the process of the first device decrypting the encrypted verification response information can be as follows: the first device determines a temporary private key generated by the first device and a first network public key, calculates a key for decrypting the verification response information based on the temporary private key generated by the first device and the first network public key, and decrypts the encrypted verification response information based on the key used to decrypt the verification response information.

[0195] Furthermore, the key used for encrypting the verification response information and the key used for decrypting the verification response information can be the same or different, and this application embodiment does not impose any restrictions on this. The key used for encrypting the verification request information and the key used for decrypting the verification response information can be different or the same. If the key used for encrypting the verification request information and the key used for decrypting the verification response information are the same, then the first device can directly use the key used for encrypting the verification request information to decrypt the verification response information without having to recalculate the key used for decrypting the verification response information, and this application embodiment does not impose any restrictions on this. The key used for decrypting the verification request information and the key used for encrypting the verification response information can be different or the same. If the key used for decrypting the verification request information and the key used for encrypting the verification response information are the same, then the second device can directly use the key used for decrypting the verification request information to encrypt the verification response information without having to recalculate the key used for decrypting the verification response information, and this application embodiment does not impose any restrictions on this.

[0196] The following provides further details on the credential request information.

[0197] In addition to the public key of the digital identity and the second signature, the credential request information may also include at least one of the following: a first token, the user's real-person verification information (also referred to as the user's real-person authentication information), or the user's SUPI.

[0198] Furthermore, taking the inclusion of a first token in the credential request information as an example: the third device can verify the first token based on the public key of the network to which the second device belongs, to determine whether the digital identity is a digital identity authorized to access the network to which the second device belongs, thereby ensuring the security of the credential request information. The public key of the network to which the second device belongs can be obtained by the third device from a distributed ledger, or the credential request information can also include the public key of the network to which the second device belongs. That is, the third device can obtain the public key of the network to which the second device belongs through the credential request information, or the first device can send the public key of the network to which the second device belongs to the third device separately. This application embodiment does not impose any limitations on this.

[0199] Furthermore, taking the inclusion of user verification information in the credential request information as an example: the third device can verify the user's verification information to confirm the user's true identity. Optionally, if the user's true identity verification is valid, the third device can also bind information related to the digital identity (e.g., the public key of the digital identity, the identifier of the digital identity, etc.) with the user's verification information to facilitate the management of the digital identity information (e.g., the public key of the digital identity, the identifier of the digital identity, etc.) during subsequent authentication processes.

[0200] For example, a user's identity verification information may include at least one of the following: near field communication (NFC) information, facial information, physical identity credentials (or legal citizenship credentials), or voice information. NFC information may include information read from physical identity credentials, such as address information. The above is an exemplary description of user identity verification information; user identity verification information may also include other information, such as fingerprint information, which is not limited in this application embodiment.

[0201] Furthermore, taking the user's SUPI included in the credential request information as an example: the third device can establish a correspondence between the user's SUPI and the digital identity through the user's SUPI, so that the operator network can trace the corresponding digital identity through the user's SUPI and thus determine the user's identity.

[0202] The operations performed by the third device on different information in the credential request information can be combined arbitrarily, and the embodiments of this application do not limit this.

[0203] Understandably, before the third device returns the information of the first credential, the digital identity is verified not only by the second device (that is, the verification request information) but also by the third device (that is, the information included in the credential request information). This double verification improves the security of returning the first credential.

[0204] The following provides further explanation of the voucher response information.

[0205] In addition to the information of the first credential, the credential response information may also include the result of publishing the digital identity on the distributed ledger, or information instructing the first device to publish the digital identity on the distributed ledger.

[0206] After the third device receives the credential request information, it can verify the credential request information based on the above method. If the verification of the credential request information is successful, it can sign the digital identity (e.g., the public key of the digital identity) based on the private key of the second device to obtain the first credential.

[0207] Furthermore, taking the example where the credential response information also includes the result of publishing a digital identity on the distributed ledger: if the credential request information is successfully verified, the third device can also invoke a smart contract in the distributed ledger network to publish a digital identity on the distributed ledger (e.g., the public key of the digital identity, the identifier of the digital identity, etc.), and return credential response information to the first device. This credential response information includes the information of the first credential and the result of publishing the digital identity on the distributed ledger. The specific implementation process of publishing a digital identity on the distributed ledger can be understood by referring to the description related to S504 above, and will not be repeated here.

[0208] In addition, the third device may first determine the first credential and then publish the digital identity on the distributed ledger; or, the third device may first publish the digital identity on the distributed ledger and then determine the first credential. This application embodiment does not limit this.

[0209] Regarding the publication of digital identities on a distributed ledger, a third device can publish the digital identity on the distributed ledger, or other nodes in the distributed ledger network can publish the digital identity on the distributed ledger and inform the third device of the result of publishing the digital identity on the distributed ledger. This application embodiment does not limit this.

[0210] Furthermore, taking the example where the credential response information also includes information instructing the first device to publish its digital identity on the distributed ledger: if the credential request information is successfully verified, the third device can also return credential response information to the first device. This credential response information includes information about the first credential and information instructing the first device to publish its digital identity on the distributed ledger. In response to the credential response information, the first device can invoke a smart contract in the distributed ledger network to publish its digital identity on the distributed ledger (e.g., the public key of the digital identity, the identifier of the digital identity, etc.).

[0211] The implementation process of "the first device sends a credential request message" in S503 is described in detail below.

[0212] In one possible implementation, this application also provides an information transmission method, as shown in FIG6. This method is illustrated using the interaction between a first device and a second device, and between the second device and a third device, as examples. The entity executing the action of the third device in this method can also be a third-party device, or a component within a third-party device, such as a processor, chip, or chip system of the third-party device. It can also be a logic module or software capable of implementing all or part of the third-party device; this application does not impose any limitations on this. The phrase "the first device sends credential request information" in S503 can be replaced by the following S601.

[0213] S601. The first device sends a credential request message to the third device through the network to which the second device belongs. Correspondingly, the third device receives the credential request message from the first device through the network to which the second device belongs.

[0214] In an alternative implementation, the above-described S601 process can be as follows: the first device sends credential request information to the second device, and correspondingly, the second device receives the credential request information from the first device. The second device then sends credential request information to the third device, and correspondingly, the third device receives the credential request information from the second device.

[0215] In another alternative implementation, the above-described S601 process can be as follows: the first device sends credential request information to other devices in the network to which the second device belongs, and correspondingly, the other devices receive credential request information from the first device. The other devices then send credential request information to a third device, and correspondingly, the third device receives credential request information from the other devices. The other devices are devices capable of relaying information transmitted between the first and third devices; for example, the other devices can be RAN-side devices or core network-side devices, etc., and this application embodiment does not limit this.

[0216] For further details regarding S601, please refer to the relevant descriptions in S503; they will not be repeated here.

[0217] As described above regarding "S601", the first device can send credential request information to the third device, and correspondingly, the credential response information can originate from the third device. Therefore, referring to Figure 6, S504 can be replaced by the following S602.

[0218] S602, the third device sends credential response information to the first device through the network to which the second device belongs. Correspondingly, the first device receives credential response information from the third device through the network to which the second device belongs.

[0219] For an understanding of S602, please refer to the relevant descriptions of S504 and S601; they will not be repeated here.

[0220] In one possible implementation, this application embodiment also provides an information transmission method. As shown in FIG7, after receiving the credential response information of the digital identity, the first device can also sign an agreement with the network to which the second device belongs through the first credential. The process of the first device signing an agreement with the network to which the second device belongs through the first credential can be implemented through the following steps.

[0221] S701, The first device sends a contract request message.

[0222] In some possible implementations, the first device may send a contract request to a device capable of authenticating digital identities. For example, the first device may send the contract request to a second device; or, for example, the first device may send the contract request to other devices in the network to which the second device belongs; or, for example, the first device may send the contract request to a third device; or, for example, the first device may send the contract request to other nodes in the distributed ledger network.

[0223] The signing request information is used to verify the digital identity. The verification request information can also be used to verify the digital identity. The difference between the two is that the verification request information includes the public key of the digital identity and the first signature; verifying the digital identity through the verification request information can be understood as verifying the first signature based on the public key of the digital identity. The signing request information includes information about the first credential; verifying the digital identity through the signing request information can be understood as verifying the first credential, that is, verifying the first credential endorsed by a third device, or verifying the digital identity through the signing request information can be understood as verifying the first credential based on the public key of the device endorsing the first credential, etc.

[0224] As can be seen from the aforementioned description of the information regarding the first credential, the information of the first credential can be the first credential itself, or information used to identify the first credential. For example, the information of the first credential can be the identifier of the digital identity, or the address of the digital identity in the distributed ledger, etc.

[0225] Taking the first credential's information as specifically the first credential itself as an example: the device that receives the contract request information (referred to as the fourth device) can obtain the public key of the device that endorses the first credential (e.g., the third device) from the distributed ledger, and verify the first credential based on the public key of the device that endorses the first credential.

[0226] Taking the first credential's information as a digital identity identifier as an example: the fourth device can retrieve the first credential corresponding to the digital identity from the distributed ledger based on the digital identity identifier, and retrieve the public key of the device endorsing the first credential from the distributed ledger. The fourth device then verifies the first credential based on the public key of the device endorsing the first credential.

[0227] Taking the information of the first credential as specifically the address of the digital identity in the distributed ledger as an example: the fourth device can retrieve the first credential from the distributed ledger based on the address of the digital identity in the distributed ledger, and retrieve the public key of the device endorsing the first credential from the distributed ledger. The fourth device verifies the first credential based on the public key of the device endorsing the first credential.

[0228] In some optional implementations, the subscription request information can be specifically used to request a subscription with the network to which the second device belongs, or it can be specifically used to request joining (or accessing) a distributed ledger network, or it can be specifically used to request using services provided by the network to which the second device belongs, or it can be specifically used to request using services related to the distributed ledger network, or it can be specifically used to request establishing a connection with the network to which the second device belongs or the distributed ledger network, etc. This application embodiment does not limit this. As described above regarding the "verification request information," the verification request information is used by the second device to verify its digital identity. If the networks to which the first device and the second device belong are already subscribed, it indicates that the second device has already verified the identity of the first device, and there is no need to verify the digital identity again. Therefore, the first device does not need to send verification request information to the second device, but can directly access the network to which the second device belongs. If the first device sends verification request information to the second device, it indicates that the first device has not subscribed with the network to which the second device belongs. The first device can send subscription request information to achieve a subscription between the first device and the network to which the second device belongs, so that the first device can subsequently use the services provided by the network to which the second device belongs.

[0229] S702, The first device receives the contract response information.

[0230] In some possible implementations, the first device may receive the contract response information from a device capable of authenticating the digital identity. For example, the first device may receive the contract response information from a second device; or, for example, the first device may also receive the contract response information from other devices in the network to which the second device belongs; or, for example, the first device may also receive the contract response information from a third device; or, for example, the first device may receive the contract response information from other nodes in the distributed ledger network.

[0231] The contract response information is used to provide feedback on the results of the verification of the digital identity.

[0232] Taking the device receiving the contract request information as the fourth device as an example, the fourth device sends a contract response message to the first device based on the verification result of the digital identity. Specifically, if the verification of the first credential based on the public key of the device endorsing the first credential is successful, the contract response message successfully verifies the digital identity. If the verification of the first credential based on the public key of the device endorsing the first credential fails, the contract response message fails to verify the digital identity.

[0233] In some optional implementations, the contract response information can be specifically used to report the result of the first device requesting to sign a contract with the network to which the second device belongs, or the contract response information can be specifically used to report the result of the first device requesting to join (or access) the distributed ledger network, or the contract response information can be specifically used to report the result of the first device requesting to use the services provided by the network to which the second device belongs, or the contract response information can be specifically used to report the result of the first device requesting to use the services related to the distributed ledger network, or the contract response information can be specifically used to report the result of the first device requesting to establish a connection with the network to which the second device belongs or the distributed ledger network, etc. The embodiments of this application do not limit this.

[0234] Furthermore, optionally, when the subscription response information indicates that the first device and the network to which the second device belong have successfully signed a subscription agreement, the subscription response information may include at least one of the following: the user's SUPI or the root symmetric key. In this implementation, the first device can obtain the user's SUPI and root symmetric key through the subscription response information, so that the first device can subsequently access the network to which the second device belongs based on the user's SUPI and root symmetric key, and thus use the services provided by the network to which the second device belongs.

[0235] In addition, in general technology, the first device can obtain the user's SUPI and symmetric key information through the following three methods: Method 1, obtaining the user's SUPI and symmetric key information through offline account opening; Method 2, obtaining the user's SUPI and symmetric key information through online account opening; Method 3, obtaining the user's SUPI and symmetric key information through online account opening.

[0236] In Method 1, the user of the first device can purchase a user identification module (e.g., SIM card) at the operator's network outlets with a physical identity certificate, and conduct an account opening process based on the user identification module, so as to write the user's SUPI and symmetric key information provided by the operator network into the user identification module.

[0237] In Method Two, the first device can apply to the operator to purchase a Subscriber Identity Module (e.g., SIM card) via an existing WiFi or cellular network connection, and upload real-person verification information such as the user's name, address, phone number, and ID number. Once the operator verifies and approves the user's real-person verification information, they can mail the Subscriber Identity Module to the user. This module stores the user's SUPI (Subscriber Identity Module Index) and symmetric key information written by the operator's network.

[0238] In method three, the first device can purchase the user's SUPI and symmetric key information from the operator via the connected WiFi network, and then write the user's SUPI and symmetric key information into the user identification module (e.g., eSIM) through an online service (over-the-top, OTT) provided by the terminal manufacturer. In other words, in method three, the first device can write the user's SUPI and symmetric key information into the user identification module through cooperation with the terminal manufacturer and the operator.

[0239] However, the user's SUPI and symmetric key information obtained by the above method are only associated with the operator. Therefore, optionally, the second device can establish and store the correspondence between the digital identity and the information in the subscription response information (e.g., the user's SUPI and symmetric key), so that the operator network can trace the corresponding digital identity through the user's SUPI and thus determine the user's identity.

[0240] For example, taking the first device as a terminal for installing a digital wallet, the first device needs to include a user identification module, the second device is an IDM, and the third device is an authoritative institution as an example, as shown in Figure 8, the information transmission method provided in this application embodiment may include the following S801 to S815.

[0241] S801. The terminal with the digital wallet installed obtains the user identification module and deploys the user identification module in the terminal with the digital wallet installed.

[0242] The user identification module may have pre-installed information such as the public key certificate of the user identification module or the production certificate (or factory certificate) generated by the manufacturer of the terminal that installs the digital wallet for the terminal that installs the digital wallet. However, the user identification module does not store information such as the contracted operator network, so the user identification module can be understood as a blank user identification module.

[0243] In some possible implementations, the user identification module can be provided by the manufacturer of the user identification module to the terminal where the digital wallet is installed, or it can be pre-installed in the terminal where the digital wallet is installed. This application embodiment does not limit this.

[0244] S802. The terminal with the digital wallet installed generates the public key and private key of the digital identity.

[0245] In one possible implementation, the S802 process can be as follows: the terminal with the digital wallet installed calls the cryptographic module of the user identification module through the digital wallet application deployed within the terminal with the digital wallet installed, and generates the public key and private key of the digital identity based on the cryptographic module.

[0246] Alternatively, the hash of the public key of the digital identity can be used as an identifier for that digital identity.

[0247] It is understandable that S801 to S802 can be steps in the generation stage. That is, S801 to S802 can generate relevant information about the digital identity, such as the public key and private key of the digital identity.

[0248] S803. The terminal with the digital wallet installed sends a verification request to the IDM. Correspondingly, the IDM receives the verification request from the terminal with the digital wallet installed.

[0249] For a more detailed explanation of S803, please refer to the description of S501 above and the further explanation of the verification request information. It will not be repeated here.

[0250] S804 and IDM verify the information in the verification request information.

[0251] For a more detailed explanation of S804, please refer to the description of S501 above and the further explanation of the verification request information. It will not be repeated here.

[0252] S805 and IDM send verification response information to the terminal with the digital wallet installed. Correspondingly, the terminal with the digital wallet installed receives the verification response information from IDM.

[0253] The verification response information includes the first token.

[0254] For a more detailed explanation of S805, please refer to the description of S502 above and the further explanation of the verification response information. It will not be repeated here.

[0255] S806. The terminal with the digital wallet installed decrypts the verification response information to obtain the first token, and verifies the fifth signature based on the IDM's public key to verify the validity of the first token.

[0256] S807: Terminals with digital wallets installed obtain users' real-person verification information through NFC recognition, facial recognition, and fingerprint recognition.

[0257] For information regarding user identity verification, please refer to the descriptions in the relevant sections above; further details will not be provided here.

[0258] S808: The terminal with the digital wallet installed sends a credential request message to the authoritative institution through the IDM. Correspondingly, the authoritative institution receives the credential request message from the terminal with the digital wallet installed through the IDM.

[0259] The credential request information includes the public key of the digital identity, the second signature, the first token, and the user's real-person verification information.

[0260] For a more detailed explanation of S808, please refer to the descriptions of S503 and S601 above, as well as the further explanation of the credential request information. Further details will not be provided here.

[0261] S809. An authoritative institution verifies the second signature based on the public key of the digital identity, verifies the first token based on the public key of the operator's network, verifies the user's real-person verification information, and, if all the above verifications pass, signs the digital identity based on the private key of the authoritative institution to obtain the first credential.

[0262] It is understandable that S803 to S809 can be steps in the endorsement stage. In other words, the endorsement of digital identity can be completed through S803 to S809, which is to complete the determination of the first credential.

[0263] S810: Authoritative institutions invoke smart contracts deployed in the distributed ledger network and request the publication of information such as the public key and identifier of the digital identity on the distributed ledger through the smart contract.

[0264] S811. After a node in a distributed ledger network successfully verifies its digital identity with an authoritative institution, it publishes the public key and identifier of its digital identity on the distributed ledger.

[0265] S812. The authoritative institution sends credential response information to the terminal with the digital wallet installed via the IDM. Correspondingly, the terminal with the digital wallet installed receives the credential response information from the authoritative institution via the IDM.

[0266] The voucher response information includes the first voucher.

[0267] For a more detailed explanation of S812, please refer to the descriptions of S504 and S602 above, as well as the further explanation of the voucher response information. Further details will not be provided here.

[0268] It is understandable that S810 to S812 can be steps in the registration phase. In other words, digital identity registration can be completed through S810 to S812, which means that digital identity and other information can be successfully published on the distributed ledger.

[0269] S813. The terminal with the digital wallet installed sends a subscription request to the IDM. Correspondingly, the IDM receives the subscription request from the terminal with the digital wallet installed.

[0270] For a more detailed explanation of S813, please refer to the description of S701 above; further details will not be provided here.

[0271] S814 and IDM can obtain the public key of the authoritative institution from the distributed ledger, verify the first credential based on the authoritative institution's public key, and determine the contract response information.

[0272] The contract response information may include at least one of the following: a subscription permanent identifier (SUPI) or a root symmetric key.

[0273] S815, IDM sends a subscription response message to the terminal with the digital wallet installed. Correspondingly, the terminal with the digital wallet installed receives the subscription response message from IDM.

[0274] For a more detailed understanding of the description of S815, please refer to the description of S702 above; it will not be repeated here.

[0275] It is understandable that S813 to S815 can be steps in the signing phase, that is, the signing of digital identity and operator network can be completed through S813 to S815.

[0276] Figure 9 illustrates an example of the information transmission method provided in this application. The method is illustrated using the interaction between a first device and a node in a distributed ledger network, and between the first device and a third device, as examples. Of course, the entity executing the actions of the first device in this method can also be a terminal-side device, or a component within the terminal-side device, such as a processor, chip, or chip system of the terminal-side device, or a logic module or software capable of implementing all or part of the terminal-side device; the entity executing the actions of a node in the distributed ledger network in this method can also be a node in the distributed ledger network, or a component within a node in the distributed ledger network, such as a processor, chip, or chip system of a node in the distributed ledger network, or a logic module or software capable of implementing all or part of the nodes in the distributed ledger network; the entity executing the actions of the third device in this method can also be a third-party device, or a component within a third-party device, such as a processor, chip, or chip system of a third-party device, or a logic module or software capable of implementing all or part of the third-party device. This application does not impose any limitations on these aspects.

[0277] For example, as shown in Figure 9, the information transmission method includes the following steps:

[0278] S901, the first device sends a digital identity credential request message to the third device. Correspondingly, the third device receives the digital identity credential request message from the first device.

[0279] The credential request information includes the public key of the digital identity of the first device. This credential request information may also include a fourth signature, which is obtained by signing the credential request information using the private key of the digital identity. Upon receiving the credential request information, the third device can verify the fourth signature using the public key of the digital identity. If the verification of the fourth signature using the public key of the digital identity is successful, the third device returns the information of the first credential to the first device.

[0280] For an understanding of S901, please refer to the relevant descriptions in S501 and S503; they will not be repeated here.

[0281] In one possible implementation, after receiving the credential request information and before sending the credential response information, the third device can also verify (or query) that the digital identity has been successfully published on the distributed ledger. Specifically, the third device can verify the existence of the digital identity on the distributed ledger using information such as the digital identity's identifier. If the digital identity exists on the distributed ledger, the third device verifies the credential request information based on the first device's digital identity published on the distributed ledger, and if the verification of the credential request information based on the first device's digital identity published on the distributed ledger is successful, the third device returns the credential response information to the first device.

[0282] Further, optionally, the third device can compare the public key of the digital identity of the first device published on the distributed ledger with the public key of the digital identity included in the credential request information. If the public key of the digital identity of the first device published on the distributed ledger matches the public key of the digital identity included in the credential request information, the verification of the credential request information by the third device based on the digital identity of the first device published on the distributed ledger is successful. If the public key of the digital identity of the first device published on the distributed ledger does not match the public key of the digital identity included in the credential request information, the verification of the credential request information by the third device based on the digital identity of the first device published on the distributed ledger fails.

[0283] Furthermore, the third device can instruct other devices to verify whether the digital identity has been successfully published on the distributed ledger, and provide feedback to the third device on the result of verifying whether the digital identity has been successfully published on the distributed ledger. This application embodiment does not limit this aspect.

[0284] S902, the third device sends a digital identity credential response message to the first device. Correspondingly, the first device receives the digital identity credential response message from the third device.

[0285] The credential response information includes information about the first credential, which is obtained by signing the digital identity based on the private key of the third device.

[0286] In one optional implementation, after obtaining the first credential, the third device can also trigger the publication of the first credential information on the distributed ledger to update the digital identity-related information in the distributed ledger, so that subsequent verifiers can obtain the first credential information from the distributed ledger. Specifically, the third device can directly publish the first credential information on the distributed ledger; or, the third device can instruct other devices to publish the first credential information on the distributed ledger using information such as the digital identity identifier, and provide feedback to the third device on whether the first credential information has been successfully published on the distributed ledger. This application embodiment does not limit this approach.

[0287] Alternatively, if the information of the first credential is successfully published on the distributed ledger, nodes in the distributed ledger network can associate the relevant information of the digital identity (e.g., the public key of the digital identity and the information of the first credential) through the identifier of the digital identity.

[0288] For an understanding of S902, please refer to the relevant descriptions in S501 and S504; they will not be repeated here.

[0289] In the information transmission method provided in this application embodiment, the first device sends a digital identity credential request information to the third device so that the first credential (i.e., the credential obtained by signing the digital identity based on the third device's private key) issued by the third device can be obtained from the third device. In other words, the third device completes the endorsement of the digital identity, and then completes the issuance of the first credential online, thereby realizing the creation of the user identity.

[0290] In one possible implementation, this application embodiment also provides an information transmission method, as shown in FIG9. The information transmission method provided by this application embodiment may further include the following steps.

[0291] S903, the first device sends a digital identity publication request message. Correspondingly, nodes in the distributed ledger network receive the publication request message.

[0292] In some alternative implementations, the first device can communicate directly with nodes in the distributed ledger network, or it can communicate with nodes in the distributed ledger network through the network to which the second device belongs. This application embodiment does not limit this.

[0293] The publication request information is used to request the publication of the digital identity of the first device on the distributed ledger. The publication request information includes the public key of the digital identity of the first device. Optionally, the publication request information may also include a second signature, which is obtained by signing the publication request information based on the private key of the digital identity. After receiving the publication request information, a node in the distributed ledger network can verify the second signature based on the public key of the digital identity. If the verification of the second signature based on the public key of the digital identity is successful, the node publishes the digital identity on the distributed ledger.

[0294] As can be seen from the aforementioned description of credential request information, credential request information can also be used to request the publication of digital identity on the distributed ledger. Therefore, this publication request information can be understood by referring to the aforementioned description of credential request information, and will not be repeated here.

[0295] The descriptions regarding the first device publishing the digital identity on the distributed ledger, the publication of the digital identity on the distributed ledger, and the related descriptions of the digital identity can be understood by referring to the relevant descriptions in S501, S503, and S808, and will not be repeated here. The difference between this embodiment and the above embodiments is that, in this case, the digital identity published on the distributed ledger does not include the aforementioned credentials; that is, the published digital identity does not have the endorsement of a third device.

[0296] In addition, for example, the published request information may also be referred to as on-chain request information, stored request information, created request information, etc., and this application embodiment does not limit it in this way.

[0297] S904. Nodes in the distributed ledger network send digital identity publication response information. Correspondingly, the first device receives the digital identity publication response information.

[0298] The response message is used to indicate the result of publishing the digital identity on the distributed ledger.

[0299] In one possible implementation, the release response information is used to indicate successful publication of a digital identity on the distributed ledger. The release response information is also used to indicate unsuccessful publication of a digital identity on the distributed ledger. As can be seen from the foregoing description of credential response information, credential response information can also be used to indicate the result of publishing a digital identity on the distributed ledger. Therefore, this release response information can be understood with reference to the aforementioned description of credential response information, and will not be repeated here.

[0300] For a more detailed description of the communication between nodes in the distributed ledger network and the first device, please refer to the relevant description in S901. It will not be repeated here.

[0301] In addition, for example, publishing response information may also be referred to as on-chain response information, storing response information, creating response information, etc., and this application embodiment does not limit it in this way.

[0302] For an understanding of S904, please refer to the relevant descriptions in S501, S504, and S812; they will not be repeated here.

[0303] It is understood that in the embodiments of this application, the holder (e.g., the first device) can publish the user identity through the issuer (e.g., the third device) without having to publish the user identity itself. This not only reduces the amount of redundant information in databases such as distributed ledgers, but also saves the holder's processing operations, thereby reducing the holder's processing burden.

[0304] It should be noted that the execution order of S901 to S902 and S903 to S904 is not restricted. That is, S901 to S902 can be executed before S903 to S904, and S901 to S902 can be executed after S903 to S904. This application embodiment does not impose any restrictions on this.

[0305] In one possible implementation, the first device can send a digital identity publication request to nodes in the distributed ledger network. In response to the digital identity publication request, nodes in the distributed ledger network verify a second signature based on the public key of the digital identity. If the verification of the second signature based on the public key of the digital identity is successful, the node returns a publication response to the first device and publishes the digital identity on the distributed ledger. The first device then sends a digital identity credential request to a third device. In response to the digital identity credential request, the third device verifies a fourth signature based on the public key of the digital identity. If the verification of the fourth signature based on the public key of the digital identity is successful, the third device verifies the credential request based on the digital identity of the first device published on the distributed ledger. If the verification of the credential request based on the digital identity of the first device published on the distributed ledger is successful, the third device returns a credential response to the first device. The third device can also, after obtaining the first credential, trigger the publication of the first credential on the distributed ledger to update the digital identity-related information in the distributed ledger.

[0306] In addition, optionally, the method shown in FIG9 in the embodiments of this application can be applied to a scenario where the first device does not need to establish a connection with the second device through a cellular network. For example, the method shown in FIG9 in the embodiments of this application can be applied to a scenario where the second device establishes a connection through WiFi.

[0307] In one optional implementation, after S904, the first device may further sign an agreement with the network to which the second device belongs. The process of the first device signing an agreement with the network to which the second device belongs may include: the first device sending and receiving agreement request information. The agreement request information includes information about a first credential, which is used to verify the digital identity.

[0308] Alternatively, the network to which the first device and the second device belong can be contracted for understanding with reference to the relevant description of the information transmission method shown in Figure 7 above, and will not be repeated here.

[0309] Optionally, the descriptions of the information transmission method shown in Figure 9 can be understood by referring to the descriptions of Figures 5 to 7 and other relevant descriptions, and will not be repeated here.

[0310] For example, taking the first device as a terminal for installing a digital wallet, the first device needs to include a user identification module, the second device is an IDM, and the third device is an authoritative institution as an example, as shown in Figure 10, the information transmission method provided in this application embodiment may include the following S1001 to S1012.

[0311] S1001. The terminal with the digital wallet installed obtains the user identification module and deploys the user identification module in the terminal with the digital wallet installed.

[0312] The user identification module may contain pre-set information such as the public key certificate of the user identification module or the production certificate (or factory certificate) generated by the manufacturer of the terminal with the digital wallet installed.

[0313] In some possible implementations, the user identification module can be provided by the manufacturer of the user identification module to the terminal where the digital wallet is installed, or it can be pre-installed in the terminal where the digital wallet is installed. This application embodiment does not limit this.

[0314] S1002. The terminal with the digital wallet installed generates the public key and private key of the digital identity.

[0315] In one possible implementation, the process of S1002 can be as follows: the terminal with the digital wallet installed calls the password module of the user identification module through the digital wallet application deployed in the terminal with the digital wallet installed, and generates the public key and private key of the digital identity based on the password module.

[0316] Alternatively, the hash of the public key of the digital identity can be used as an identifier for that digital identity.

[0317] It is understandable that S1001 to S1002 can be steps in the generation stage. That is, S1001 to S1002 can generate relevant information about the digital identity, such as the public key and private key of the digital identity.

[0318] S1003. Terminals with digital wallets installed connect to the network belonging to IDM via WiFi.

[0319] S1004. The terminal with the digital wallet installed sends a digital identity publication request. Correspondingly, nodes in the distributed ledger network receive the publication request.

[0320] For a more detailed explanation of S1004, please refer to the descriptions of S901, the descriptions of the release request information, and the further explanations of the credential request information. Further details will not be provided here.

[0321] S1005. Nodes in the distributed ledger network verify digital identities and publish them on the distributed ledger.

[0322] S1006. Nodes in the distributed ledger network send a digital identity publication response message. Correspondingly, terminals with digital wallets installed receive the digital identity publication response message.

[0323] For a more detailed explanation of S1006, please refer to the descriptions of S902, the descriptions of the released response information, and further explanations of the released response information. Further details will not be provided here.

[0324] S1007. The terminal with the digital wallet installed sends a credential request for digital identity to the authoritative institution through the IDM. Correspondingly, the authoritative institution receives the credential request for digital identity from the terminal with the digital wallet installed through the IDM.

[0325] For a more detailed explanation of S1007, please refer to the descriptions of S903 and the credential request information above. Further details will not be provided here.

[0326] S1008. The authoritative institution verifies the fourth signature based on the public key of the digital identity. If the verification of the fourth signature based on the public key of the digital identity is successful, the authoritative institution signs the digital identity based on the private key to obtain the first credential and publishes the information of the first credential on the distributed ledger.

[0327] S1009. Authoritative institutions send digital identity credential response information to terminals with digital wallets installed via IDM. Correspondingly, terminals with digital wallets installed receive digital identity credential response information from authoritative institutions via IDM.

[0328] For a more detailed explanation of S1008, please refer to the descriptions of S904 and the voucher response information above. Further details will not be provided here.

[0329] It is understandable that S1003 to S1009 can be steps in the endorsement and signing stage. That is, through S1003 to S1009, the endorsement and registration of digital identity can be completed, that is, the digital identity and other information can be successfully published on the distributed ledger, and the first credential can be determined.

[0330] S1010: The terminal with the digital wallet installed sends a subscription request to the IDM. Correspondingly, the IDM receives the subscription request from the terminal with the digital wallet installed.

[0331] For a more detailed explanation of S1010, please refer to the description of S701 above. It will not be repeated here.

[0332] S1011 and IDM can obtain the public key of the authoritative institution from the distributed ledger, verify the first credential based on the authoritative institution's public key, and determine the contract response information.

[0333] The contract response information may include at least one of the following: a subscription permanent identifier (SUPI) or a root symmetric key.

[0334] The relevant description of S1011 can be understood by referring to the relevant description of S702 above, and will not be repeated here.

[0335] S1012, IDM sends a subscription response message to the terminal with the digital wallet installed. Correspondingly, the terminal with the digital wallet installed receives the subscription response message from IDM.

[0336] The relevant description of S1012 can be understood by referring to the relevant description of S702 above, and will not be repeated here.

[0337] It is understandable that S1010 to S1012 can be steps in the signing phase, that is, the signing of digital identity and operator network can be completed through S1010 to S1012.

[0338] The above mainly describes the solutions provided by the embodiments of this application from the perspective of interaction between various network elements. Correspondingly, the embodiments of this application also provide a communication device for implementing the various methods described above. This communication device can be a first terminal device in the above method embodiments, or a device containing the first terminal device, or a component usable in the first terminal device; or, the communication device can be a second terminal device in the above method embodiments, or a device containing the second terminal device, or a component usable in the second terminal device. It is understood that, in order to achieve the above functions, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0339] This application embodiment can divide the communication device into functional modules according to the above method embodiment. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be understood that the module division in this application embodiment is illustrative and represents a logical functional division; in actual implementation, there may be other division methods.

[0340] Figure 11 shows a schematic diagram of a communication device 110. The communication device 110 includes a processing module 1101 and a transceiver module 1102. The transceiver module 1102, also known as a transceiver unit, is used to implement the transceiver function, and may be, for example, a transceiver circuit, a transceiver, a transceiver device, or a communication interface.

[0341] When the communication device 110 shown in FIG11 is the first device in the above embodiments:

[0342] In one possible implementation: Processing module 1101 is configured to instruct transceiver module 1102 to send a digital identity verification request to the second device and receive a digital identity verification response from the second device. The verification request includes the public key of the digital identity of the first device and a first signature, which is obtained by signing the verification request based on the private key of the digital identity. Processing module 1101 is further configured to instruct transceiver module 1102, if the verification response indicates successful verification of the first signature based on the public key of the digital identity, to send a digital identity credential request to the third device and receive a digital identity credential response. The credential request includes the public key of the digital identity, and the credential response includes information about a first credential, which is obtained by signing the digital identity based on the private key of the third device.

[0343] In one possible implementation, the credential request information is also used to request the publication of a digital identity on the distributed ledger, and the credential response information is also used to indicate that the digital identity has been successfully published on the distributed ledger.

[0344] In one possible implementation, the verification request information further includes one or more of the following: credential information of the manufacturer of the user identification module of the first device, the public key credential of the user identification module, or a third signature; the third signature is obtained by signing the verification request information based on the private key of the user identification module; the manufacturer's credential information is used to verify the public key credential of the user identification module, and the public key in the public key credential of the user identification module is used to verify the third signature.

[0345] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to send credential request information to the third device through the network to which the second device belongs.

[0346] In one possible implementation, the verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs.

[0347] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to send a digital identity publication request message and receive a digital identity publication response message, wherein the publication request message includes a first credential and is used to request the publication of a digital identity on the distributed ledger; the publication response message is also used to indicate that the digital identity has been successfully published on the distributed ledger.

[0348] In one possible implementation, the credential request information may also include at least one of the following: the user's identity verification information, or the user's contractual permanent identifier SUPI.

[0349] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0350] In this embodiment, the first device is presented as an integrated unit divided into functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the first device can take the form of the communication device 410 shown in FIG. 4.

[0351] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0352] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0353] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0354] When the communication device 110 shown in FIG11 is the second device in the above embodiments:

[0355] In one possible implementation: processing module 1101 is configured to instruct transceiver module 1102 to receive verification request information of a digital identity from the first device. The verification request information includes the public key of the digital identity of the first device and a first signature, wherein the first signature is obtained by signing the verification request information based on the private key of the digital identity. Processing module 1101 is further configured to verify the first signature based on the public key of the digital identity. Processing module 1101 is also configured to instruct transceiver module 1102 to send verification response information of the digital identity to the first device. The verification response information indicates that the verification of the first signature based on the public key of the digital identity was successful.

[0356] In one possible implementation, the verification request information also includes the public key credential of the user identification module of the first device and a third signature, which is obtained by signing the verification request information based on the private key of the user identification module; the processing module 1101 is also used to instruct the transceiver module 1102 to verify the third signature based on the public key in the public key credential of the user identification module.

[0357] In one possible implementation, the digital authentication request information also includes the manufacturer's credentials for the user identification module of the first device and the public key credentials for the user identification module; the processing module 1101 is further configured to instruct the transceiver module 1102 to verify the public key credentials of the user identification module based on the manufacturer's credentials.

[0358] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to receive credential request information of the digital identity from the first device and send the credential request information to the third device; wherein the credential request information includes the public key of the digital identity; the processing module 1101 is further configured to instruct the transceiver module 1102 to receive credential response information of the digital identity from the third device, the credential response information including information of the first credential, and send the credential response information to the first device, wherein the first credential is obtained by signing the digital identity based on the private key of the third device.

[0359] In one possible implementation, the verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs.

[0360] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to receive a signing request message from the first device. The signing request message includes information about a first credential, which is obtained by signing a digital identity based on the private key of the third device. The processing module 1101 is also configured to verify the first credential based on the public key of the third device and send a signing response message to the first device based on the verification result.

[0361] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0362] In this embodiment, the second device is presented as an integrated unit divided into functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the second device can take the form of the communication device 410 shown in FIG. 4.

[0363] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0364] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0365] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0366] When the communication device 110 shown in Figure 11 is the third device in the above embodiments:

[0367] In one possible implementation: processing module 1101 is configured to instruct transceiver module 1102 to receive credential request information for the digital identity from the first device; the credential issuance request information includes the public key of the digital identity of the first device. Processing module 1101 is further configured to sign the digital identity according to the private key of the third device to obtain a first credential; processing module 1101 is also configured to instruct transceiver module 1102 to send credential response information for the digital identity to the first device, the credential response information including information about the first credential.

[0368] In one possible implementation, the processing module 1101 is further configured to trigger the publication of a digital identity on the distributed ledger, the digital identity including a first credential; the credential response information is further configured to indicate that the digital identity has been successfully published on the distributed ledger.

[0369] In one possible implementation, the credential request information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs, and the method further includes: verifying the first token.

[0370] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to receive the credential request information of the digital identity from the first device sent through the network to which the second device belongs; the processing module 1101 is further configured to instruct the transceiver module 1102 to send the credential response information of the digital identity to the first device through the network to which the second device belongs.

[0371] In one possible implementation, the credential request information includes a second signature. The processing module 1101 is also used to instruct the transceiver module 1102 to send credential response information to the second device if the verification of the second signature based on the public key of the digital identity is successful.

[0372] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0373] In this embodiment, the third device is presented as an integrated unit divided into functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the third device can take the form of the communication device 410 shown in FIG. 4.

[0374] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0375] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0376] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0377] When the communication device 110 shown in FIG11 is the first device in the above embodiments:

[0378] In one possible implementation: the processing module 1101 is used to instruct the transceiver module 1102 to send the credential request information of the digital identity of the first device to the third device, and to receive the credential response information of the digital identity of the third device, wherein the credential request information includes the public key of the digital identity of the first device; the credential response information includes information of the first credential, which is obtained by signing the digital identity based on the private key of the third device.

[0379] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to send a digital identity publication request message and receive a digital identity publication response message, wherein the publication request message is used to request the publication of the digital identity of the first device on the distributed ledger, and the publication request message includes the public key of the digital identity of the first device.

[0380] In one possible implementation, the digital identity of the first device published on the distributed ledger is used to verify the credential request information.

[0381] In one possible implementation, a response message is published to indicate that the digital identity has been successfully published on the distributed ledger.

[0382] In one possible implementation, the processing module 1101 is also used to instruct the transceiver module 1102 to send a publish request message to the nodes in the distributed ledger network.

[0383] In one possible implementation, the processing module 1101 is further configured to instruct the transceiver module 1102 to send a contract request information and receive a contract response information, wherein the contract request information includes information about a first credential, which is used to verify the digital identity.

[0384] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0385] In this embodiment, the first device is presented as an integrated unit divided into functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the first device can take the form of the communication device 410 shown in FIG. 4.

[0386] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0387] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0388] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0389] When the communication device 110 shown in Figure 11 is a node in the distributed ledger network in the above embodiments:

[0390] In one possible implementation: processing module 1101 is used to instruct transceiver module 1102 to receive credential request information for the digital identity of the first device and to provide credential response information for the digital identity of the first device, wherein the credential request information includes the public key of the digital identity of the first device.

[0391] In one possible implementation, the credential response information is used to indicate that a digital identity has been successfully issued on the distributed ledger.

[0392] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0393] In this embodiment, the nodes in the distributed ledger network are presented as integrated functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the nodes in the distributed ledger network can take the form of the communication device 410 shown in FIG. 4.

[0394] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0395] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0396] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0397] When the communication device 110 shown in Figure 11 is the third device in the above embodiments:

[0398] In one possible implementation: processing module 1101 is configured to instruct transceiver module 1102 to receive credential request information for the digital identity from the first device, the credential request information including the public key of the digital identity of the first device. Processing module 1101 is further configured to sign the digital identity according to the private key of the third device to obtain a first credential. Processing module 1101 is also configured to instruct transceiver module 1102 to send credential response information for the digital identity to the first device, the credential response information including information about the first credential.

[0399] In one possible implementation, processing module 1101 is also used to verify that the digital identity has been successfully published on the distributed ledger.

[0400] In one possible implementation, the processing module 1101 is also used to trigger the publication of information for the first credential on the distributed ledger.

[0401] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0402] In this embodiment, the third device is presented as an integrated unit divided into functional modules. Here, "module" can refer to an application-specific integrated circuit (ASIC), a circuit, a processor and memory executing one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the third device can take the form of the communication device 410 shown in FIG. 4.

[0403] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0404] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0405] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0406] In this embodiment, the network-side device is presented as an integrated unit divided into functional modules. Here, "module" can refer to a specific ASIC, circuitry, a processor and memory executing one or more software or firmware programs, integrated logic circuitry, and / or other devices that can provide the aforementioned functions. In a simplified embodiment, those skilled in the art will recognize that the network-side device can take the form of the communication device 410 shown in FIG. 4.

[0407] For example, the processor 411 in the communication device 410 shown in Figure 4 can call the computer execution instructions stored in the memory 412 to make the communication device 410 execute the information transmission method in the above method embodiment.

[0408] Specifically, the functions / implementation processes of the transceiver module 1102 and processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412. Alternatively, the functions / implementation processes of the processing module 1101 in Figure 11 can be implemented by the processor 411 in the communication device 410 shown in Figure 4 calling computer execution instructions stored in the memory 412, and the functions / implementation processes of the transceiver module 1102 in Figure 11 can be implemented by the transceiver 415 in the communication device 410 shown in Figure 4.

[0409] Since the communication device 110 provided in this application embodiment can execute the above information transmission method, the technical effects it can obtain can be referred to the above method embodiment, and will not be repeated here.

[0410] It should be understood that one or more of the above modules or units can be implemented by software, hardware, or a combination of both. When any of the above modules or units are implemented by software, the software exists as computer program instructions and is stored in memory. The processor can be used to execute the program instructions and implement the above method flow. The processor can be built into a SoC (System-on-a-Chip) or ASIC, or it can be a separate semiconductor chip. In addition to the core that executes software instructions for computation or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), or logic circuits that implement dedicated logic operations.

[0411] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a central processing unit (CPU), microprocessor, digital signal processing (DSP) chip, microcontroller unit (MCU), artificial intelligence processor, ASIC, SoC, FPGA, PLD, application-specific digital circuit, hardware accelerator, or non-integrated discrete device, which can run the necessary software or perform the above method flow independently of software.

[0412] For a more detailed description of the above-mentioned processing module 1101 and transceiver module 1102, please refer to the relevant descriptions in the method embodiments shown in Figures 5 and 7 and 8.

[0413] In one possible implementation, this application embodiment also provides a communication device (e.g., the communication device may be a chip or a chip system), which includes a processor for implementing the methods in any of the above method embodiments. In one possible design, the communication device further includes a memory. The memory is used to store necessary program instructions and data, and the processor can call the program code stored in the memory to instruct the communication device to execute the methods in any of the above method embodiments. Of course, the memory may not be included in the communication device. When the communication device is a chip system, it may be composed of chips or may include chips and other discrete devices; this application embodiment does not specifically limit this.

[0414] In one possible implementation, this application also provides a computer-readable storage medium storing a computer program or instructions that, when run on a communication device, enable the communication device to execute the methods of any of the above-described method embodiments or any implementation thereof.

[0415] In one possible implementation, this application also provides an information transmission method, which includes the method of any of the above-described method embodiments or any implementation thereof.

[0416] In one possible implementation, embodiments of this application also provide a communication system, which includes the first device, the second device, the third device, and a node in a distributed ledger network as described in the above method embodiments.

[0417] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs).

[0418] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0419] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the scope of this application. Accordingly, this specification and drawings are exemplary illustrations of this application as defined by the appended claims and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. An information transmission method, characterized in that, Applied to a first device, the method includes: Send a digital identity verification request to the second device. The verification request includes the public key of the digital identity of the first device and a first signature, wherein the first signature is obtained by signing the verification request based on the private key of the digital identity. Receive verification response information of the digital identity from the second device; If the verification response information indicates that the verification of the first signature based on the public key of the digital identity is successful, a credential request information for the digital identity is sent to the third device; the credential request information includes the public key of the digital identity. The system receives credential response information for the digital identity from the third device. The credential response information includes information about a first credential, which is obtained by signing the digital identity based on the private key of the third device.

2. The method according to claim 1, characterized in that, The credential request information is also used to request the publication of the digital identity on the distributed ledger, and the credential response information is also used to indicate that the digital identity has been successfully published on the distributed ledger.

3. The method according to claim 1 or 2, characterized in that, The verification request information further includes one or more of the following: credential information of the manufacturer of the user identification module of the first device, the public key credential of the user identification module, or a third signature; the third signature is obtained by signing the verification request information based on the private key of the user identification module; the credential information of the manufacturer is used to verify the public key credential of the user identification module, and the public key in the public key credential of the user identification module is used to verify the third signature.

4. The method according to any one of claims 1-3, characterized in that, The step of sending the credential request information for the digital identity includes: The credential request information is sent to the third device through the network to which the second device belongs.

5. The method according to any one of claims 1-4, characterized in that, The verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs, and the credential request information includes the first token.

6. The method according to any one of claims 1, 3-5, characterized in that, Also includes: Send a publication request message for the digital identity, the publication request message including the first credential, the publication request message being used to request the publication of the digital identity on the distributed ledger; The system receives a publication response message for the digital identity, which further indicates that the digital identity has been successfully published on the distributed ledger.

7. The method according to claim 6, characterized in that, After receiving the credential response information of the digital identity, the method further includes: Send a contract request message, the contract request message including information of the first credential, the first credential being used to verify the digital identity; Receive contract response information.

8. An information transmission method, characterized in that, Applied to a second device, the method includes: The device receives a verification request message for a digital identity from a first device. The verification request message includes the public key of the digital identity of the first device and a first signature, wherein the first signature is obtained by signing the verification request message based on the private key of the digital identity. The first signature is verified based on the public key of the digital identity; The first device sends a verification response message of the digital identity, which indicates that the verification of the first signature based on the public key of the digital identity was successful.

9. The method according to claim 8, characterized in that, The verification request information also includes the public key credential of the user identification module of the first device and a third signature, wherein the third signature is obtained by signing the verification request information based on the private key of the user identification module; the method further includes: The third signature is verified based on the public key in the public key certificate of the user identification module.

10. The method according to any one of claims 8-9, characterized in that, The digital authentication request information also includes the credential information of the manufacturer of the user identification module of the first device, and the public key credential of the user identification module; the method further includes: The public key credentials of the user identification module are verified based on the manufacturer's credentials.

11. The method according to any one of claims 9-10, characterized in that, The method further includes: Receive credential request information for the digital identity from the first device; the credential request information includes the public key of the digital identity; Send the credential request information to the third device; The system receives credential response information for the digital identity from the third device, the credential response information including information about a first credential, which is obtained by signing the digital identity based on the private key of the third device. Send the credential response information to the first device.

12. The method according to claim 11, characterized in that, The credential request information is also used to request the publication of the digital identity on the distributed ledger, and the credential response information is also used to indicate that the digital identity has been successfully published on the distributed ledger.

13. The method according to any one of claims 8-12, characterized in that, The verification response information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs.

14. The method according to any one of claims 8-13, characterized in that, After sending the verification response information of the digital identity to the first device, the method further includes: Receive a signing request information from the first device, the signing request information including information about a first credential, the first credential being obtained by signing the digital identity based on the private key of the third device; The first credential is verified based on the public key of the third device. Based on the verification result, a contract response message is sent to the first device.

15. An information transmission method, characterized in that, Applied to a third device, the method includes: Receive credential request information for the digital identity from the first device; the credential issuance request information includes the public key of the digital identity of the first device; The digital identity is signed using the private key of the third device to obtain a first credential; credential response information of the digital identity is sent to the first device, the credential response information including information of the first credential.

16. The method according to claim 15, characterized in that, The method further includes: The digital identity, including the first credential, is triggered to be published on the distributed ledger; the credential response information is also used to indicate that the digital identity has been successfully published on the distributed ledger.

17. The method according to claim 15 or 16, characterized in that, The credential request information includes a first token, which indicates that the first device is allowed to access the network to which the second device belongs. The method further includes: verifying the first token.

18. The method according to claim 17, characterized in that, The receipt of credential request information for the digital identity from the first device includes receiving credential request information for the digital identity from the first device sent through the network to which the second device belongs; Sending the credential response information of the digital identity to the first device includes sending the credential response information of the digital identity to the first device through the network to which the second device belongs.

19. A communication device, characterized in that, include: A functional unit for performing the method as described in any one of claims 1-18; wherein the action performed by the functional unit is implemented by hardware or by hardware executing corresponding software.

20. A communication device, characterized in that, The communication device includes at least one processor; the processor is configured to run computer programs or instructions, or to cause the communication device to perform the method as described in any one of claims 1-18 via logic circuitry.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions or programs that, when executed on a computer, cause the communication device to perform the method as described in any one of claims 1-18.

22. A computer program product comprising instructions, characterized in that, When it is operated on a communication device, it causes the communication device to perform the method as described in any one of claims 1-18.

23. A communication system, characterized in that, Includes at least two of the following devices: A first apparatus for performing the method as described in any one of claims 1-7; A second apparatus for performing the method as described in any one of claims 8-14; A third apparatus for performing the method as described in any one of claims 15-18.

Images