Communication method, apparatus, and system

Abstract

A communication method, apparatus, and system. A trusted authority (such as an operator or another authoritative institution) can obtain second identity information on the basis of the first identity information of a second apparatus (such as a terminal, an RAN node or a core NF), and sends the second identity information to an apparatus in a DL network, thereby triggering publication of the second identity information in a DL. Thus, the digital identity information (such as the second identity information) of the second apparatus is published in the DL. If a third party needs to authenticate the identity of the second apparatus, the third party can search the DL for the digital identity information of the second apparatus, and then authenticate the digital identity information, thereby realizing interoperability and mutual trust of the digital identity information of the second apparatus between multiple services. Moreover, the second identity information is published by an apparatus in the DL network, and not any holder of a digital certificate has a publication permission, and thus, the second identity information has higher credibility in the DL network and is more secure.

Description

Communication methods, devices and systems

[0001] This application claims priority to Chinese Patent Application No. 202510084728.5, filed on January 17, 2025, with the China National Intellectual Property Administration, entitled “Communication Method, Apparatus and System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more particularly to a communication method, apparatus and system. Background Technology

[0003] Currently, users need to maintain multiple independent identities in various businesses such as communication technology (CT), information technology (IT), and offline business, and it is difficult for these identities to be interchangeable between different businesses.

[0004] Taking the CT (Computer-Assisted Communication) field as an example, because users' terminals (such as mobile phones) are strongly bound to operators through a subscriber identity module (SIM) card, each telecom operator independently manages its own contracted user identities. Therefore, user identities can only be used for the services of the contracted operator, lacking flexibility.

[0005] Therefore, we hope to provide a method that enables the flexible use of user identities. Summary of the Invention

[0006] This application provides a communication method, apparatus, and system that aims to publish a user's digital identity to a distributed ledger (DL) based on the network architecture of a telecommunications network, thereby supporting ubiquitous access to the user's digital identity.

[0007] Firstly, a communication method is provided, which can be applied to, for example, executed by, a first device. The first device may be a core network function (NF), an application function (AF), or a component within the core network NF, such as a chip, chip system, processor, etc., or it may be a logic module or software capable of implementing some or all of the functions of the core network NF, etc. The core network NF may, for example, be an identity (ID) management (IDM) network element (hereinafter referred to as IDM), or other network elements that can be used to manage digital identities; this application includes, but is not limited to, these.

[0008] For example, the system obtains first identity information of a second device, the first identity information including the public key and / or attributes of the second device; sends a first request message to a third device, the first request message being used to request the publication of second identity information in a distributed ledger (DL), the second identity information being obtained based on the first identity information, the second identity information including one or more of the following: the public key of the second device, the public key certificate of the second device, the attribute, the hash of the attribute, the attribute certificate, or the hash of the attribute certificate; wherein, the public key of the second device is used to verify a signature from the second device, the public key certificate of the second device is obtained by signing the public key of the second device based on the private key of the first device, the attribute certificate is obtained by signing the attribute based on the private key of the first device, and the third device is a device in the DL network; and receives a first response message from the third device, the first response message being used to indicate the publication result of the second identity information in the DL.

[0009] It should be understood that the second identity information may include a public key certificate and / or an attribute certificate (or a hash of the attribute certificate), and the public key certificate and the attribute certificate can be regarded as two examples of VC; the second identity information may also include a public key and / or an attribute (or a hash of the attribute), that is, the public key certificate and / or attribute certificate can be obtained by signing the public key and / or the attribute through a third device.

[0010] Based on the above scheme, the first device can obtain the second identity information based on the first identity information of the second device and send the second identity information to the third device. Since the third device is a device in the DL network, it can trigger the publication of the second identity information in the DL. This achieves the publication of the second device's digital identity information (such as the second identity information) in the DL. In this way, if authentication of the second device is required, its digital identity information can be retrieved from the DL for authentication, enabling interoperability and mutual trust of the second device's digital identity information across various services. Simultaneously, this scheme also supports the subsequent access of the second device to the DL network. Furthermore, the first device triggers the publication of the second identity information in the DL by sending a first request message to a device in the DL network, rather than any digital certificate holder having the authority to publish a digital identity in the DL network. This makes the second identity information more trustworthy and secure within the DL network.

[0011] In conjunction with the first aspect, in some possible implementations of the first aspect, before sending the first request message to the third device, the method further includes: verifying the first identity information as successful.

[0012] Therefore, the first device can verify the first identity information of the second device before sending the second identity information to devices in the DL network. The resulting second identity information is a verified digital identity, thus preventing malicious attacks on the DL network and improving security.

[0013] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes: generating the second identity information based on the first identity information.

[0014] The second identity information can be the first identity information, or it can be obtained by processing the first identity information, such as the second identity information being a hash of the first identity information, etc., without any limitation.

[0015] In conjunction with the first aspect, in some possible implementations of the first aspect, the first request message also carries a second identity information signature, which is obtained by signing the second identity information based on the private key of the first device.

[0016] The private key signature of the first device can be verified using the public key of the first device, thereby confirming whether the second identity information is valid.

[0017] In conjunction with the first aspect, in some possible implementations of the first aspect, the first identity information includes the public key and / or attributes of the second device; the second identity information includes the hash of the public key credential and / or attribute credential of the second device.

[0018] In other words, the first device issues credentials (or endorses) the digital identity of the second device. Since the first device is a network element provided by the operator's network to manage digital identities or a third-party social authority, the second identity information issued with the endorsement of the first device is more credible and more secure.

[0019] In conjunction with the first aspect, in some possible implementations of the first aspect, after sending the first request message to the third device, the method further includes: obtaining one or more of the following from the third device: the address of the second identity information in the DL, or the credentials of the DL, the credentials of the DL being used to authenticate the identity of a device in the DL's network.

[0020] The address of the second identity information in the DL helps the first device retrieve the second identity information from the DL. The DL's credentials help verify the identity of devices within the DL's network.

[0021] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes sending one or more of the following to the second device: an identifier of the second identity information, an address of the second identity information in the DL, or a credential of the DL.

[0022] The identifier of the second identity information can be obtained based on the identifier of the first identity information, and the identifier of the first identity information can be included in the first identity information.

[0023] Sending the identifier of the second identity information to the second device makes it convenient for the second device to send the identifier of the second identity information in the authentication request to the device in the DL network when it subsequently accesses the DL network. This allows the device to look up the second identity information in the DL based on the identifier of the second identity information and then authenticate the second device based on the second identity information.

[0024] Sending the address of the second identity information in DL to the second device makes it convenient for the second device to send the address in the authentication request to the device in DL network when it subsequently accesses DL's network. This allows the device to quickly find the second identity information in DL and then authenticate the second device based on the second identity information.

[0025] Sending DL's credentials to the second device facilitates the second device's subsequent verification of the identity of devices in DL's network when accessing DL's network.

[0026] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes sending to the fourth device one or more of the following: a correspondence between the attribute and the hash of the attribute published in the DL; a correspondence between the attribute credential and the hash of the attribute credential published in the DL; or, a correspondence between the identifier of the second identity information and the identifier of the second device, wherein the identifier of the second device is used to identify the second device within the network service scope provided by the operator.

[0027] Sending this information to the fourth device allows the fourth device to manage the identity information of the second device. Furthermore, this fourth device can be a private node of the operator, thus helping to protect user privacy.

[0028] Secondly, a communication method is provided that can be applied to, or executed by, a third device. This third device can be a device within the DL network, such as a core network NF, or a component within the core network NF, such as a chip, chip system, processor, etc., or a logic module or software capable of implementing some or all of the functions of the core network NF, etc. The core network NF can be, for example, a distributed ledger enable function (DLEF), and this application includes, but is not limited to, this.

[0029] For example, the method includes: receiving a first request message from a first device, the first request message carrying second identity information of a second device, the second identity information including one or more of the following: a public key of the second device, a public key credential of the second device, the attribute, a hash of the attribute, an attribute credential, or a hash of the attribute credential; wherein the public key of the second device is used to verify a signature from the second device, the public key credential of the second device is obtained by signing the public key of the second device based on the private key of the first device, and the attribute credential is obtained by signing the attribute based on the private key of the first device; and sending a first response message to the first device, the first response message being used to indicate the publication result of the second identity information in the DL.

[0030] Based on the above scheme, after receiving the second identity information from the second device via the first device, the third device can trigger the publication of the second identity information in the DL network. This can be achieved through various means, such as the third device publishing the information itself, processing it (e.g., hashing, signing, or hashing after signing), publishing it through other devices within the DL network, or the second device processing the information and then publishing it through other devices within the DL network. This enables the publication of the digital identity of devices within the telecommunications network in the DL, providing support for identity authentication when the second device subsequently accesses the DL network. Furthermore, since the third device is a device within the DL network and can trigger the publication of the second identity information, not every digital certificate holder has the authority to publish their digital identity within the DL network. This makes the second identity information more trustworthy and secure within the DL network.

[0031] In conjunction with the second aspect, in some possible implementations of the second aspect, the first request message also carries a second identity information signature, which is obtained by signing the second identity information based on the private key of the first device; the method further includes: verifying the second identity information signature based on the public key credential of the first device.

[0032] Since the first device is a network element provided by the operator's network to manage digital identities, the second identity information issued with the endorsement of the first device is more credible and secure. Furthermore, the private key signature of the first device can be verified using the public key in the public key certificate of the first device, thereby confirming the validity of the second identity information.

[0033] In conjunction with the second aspect, in some possible implementations of the second aspect, the DL is a blockchain, and the second identity information is published in the DL, including: obtaining a transaction based on the second identity information; obtaining a block based on the transaction; and triggering consensus of the block in the blockchain network.

[0034] Optionally, the transaction includes: the initiator of the transaction, the recipient of the transaction, the transaction content, and the transaction signature; wherein, the initiator of the transaction indicates the issuer of the second identity information or the party to which the issuer of the second identity information belongs, the recipient of the transaction indicates the smart contract, the transaction content is generated based on the second identity information, or the transaction content is generated based on the second identity information or the signature of the second identity information, and the transaction signature is obtained by signing the transaction content based on the private key of the third device.

[0035] Therefore, transactions can be generated based on the secondary identity information, and then packaged into blocks. This enables the publication of the secondary identity information within the blockchain.

[0036] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes sending one or more of the following to the second device: the address of the second identity information in the DL, or the root credential of the DL, the root credential being used to verify the credentials of each node in the network of the DL.

[0037] For details on the technical effects of sending the address of the second identity information in the DL and the root credential of the DL to the second device, please refer to the detailed description in the first aspect above, which will not be repeated here.

[0038] Thirdly, a communication method is provided that can be applied to, for example, executed by, a second device. The second device may be a terminal, a radio access network (RAN) node, or a core network NF, or a component within the terminal, RAN node, or core network NF, such as a chip, chip system, or processor. It may also be a logic module or software capable of implementing some or all of the functions of the terminal, RAN node, or core network NF, etc., and this application does not limit the scope of the application.

[0039] For example, the method includes: sending a second request message for requesting the publication of second identity information in the DL, the second request message carrying first identity information, the first identity information including a public key and / or attributes of a second device; the first identity information for obtaining the second identity information; and receiving a second response message for indicating the publication result of the second identity information in the DL.

[0040] Based on the above scheme, when there is a need to join the DL network, the second device can request the publication of a second identity information in DL via a second request message. This second request message carries the first identity information, which the receiving first device can use to obtain the second identity information, thus supporting the publication of the second identity information in DL. Furthermore, the first identity information includes the second device's public key and / or attributes, which the first device can verify and audit, thereby helping to prevent malicious attacks on the DL network and ensuring DL's network security. Moreover, by sending the first identity information to the first device to request the publication of the second identity information in the DL network, the second device does not have the authority to register a digital identity in the DL network, making the registration of the second identity information in the DL network more credible and secure.

[0041] In conjunction with the third aspect, in some possible implementations of the third aspect, the second response message carries one or more of the following: the second identity information, the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL, the credentials of the DL being used to verify the identity of the device in the DL's network.

[0042] Sending the second identity information to the second device allows the second device to save its digital identity locally, which can then be used as credentials when publishing the digital identity to the DL again, or when publishing the digital identity to other DLs, thus facilitating the rapid publication of the second device's digital identity to the DL.

[0043] For details regarding the identification of the second identity information, the address of the second identity information in the DL, and the technical effects of the DL's credentials, please refer to the first aspect above, which will not be repeated here.

[0044] Fourthly, a communication method is provided, which can be applied to a second device, for example, executed by the second device. The second device may be a terminal, a RAN node, or a core network NF, or a component in the terminal, RAN node, or core network NF, such as a chip, chip system, or processor, or a logic module or software capable of implementing some or all of the functions of the terminal, RAN node, or core network NF, etc., and this application does not limit it in this regard.

[0045] For example, the method includes: sending a third request message to a first device, the third request message being used to request obtaining second identity information based on carried first identity information, the first identity information including a public key and / or attributes of the second device; receiving the second identity information from the first device, the second identity information including a public key credential and / or attribute credential of the second device, the public key credential being obtained by signing the public key of the second device with the private key of the first device, and the attribute credential being obtained by signing the public key of the second device with the private key of the first device.

[0046] Based on the above scheme, the second device can obtain second identity information issued by the first device by sending a request message carrying the first identity information to the first device. Thus, the second device can obtain credentials that can be used for authentication. The first device is the issuer of the second identity information. Therefore, if a third party needs to authenticate the second device, it can authenticate the second identity information obtained from the second device based on the public key credentials of the first device; alternatively, the second device can publish the second identity information to the DL after obtaining it. If a third party needs to authenticate the second device, it can also retrieve the second identity information from the DL and then authenticate it based on the public key credentials of the first device. This enables the interoperability and mutual trust of the second device's digital identity information across various services.

[0047] In conjunction with the fourth aspect, in some possible implementations of the fourth aspect, the method further includes: sending a fourth request message to the first device, the fourth request message carrying the second identity information, the fourth request message being used to request the publication of the second identity information in the DL; and receiving a second response message from the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

[0048] Based on the above scheme, the second device can publish the second identity information to the DL through the first device. Since the DL has high security, publishing the second identity information to the DL can not only ensure the security of the user's identity information, but also facilitate third parties to retrieve the second identity information from the DL when authentication of the second device is required, thus supporting the interoperability and mutual trust of the second device's digital identity information across various services.

[0049] Fifthly, a communication method is provided, which can be applied to, for example, executed by, a first device. The first device may be a core network element (NF), an application element (AF), or a component within the core network NF, such as a chip, chip system, processor, etc., or a logic module or software capable of implementing some or all of the functions of the core network NF, etc. The core network NF may, for example, be an integrated device management system (IDM), or other network elements that can be used to manage digital identities; this application includes, but is not limited to, these.

[0050] For example, the method includes: receiving a third request message from a second device, the third request message being used to request obtaining second identity information based on carried first identity information, the first identity information including the public key and / or attributes of the second device; obtaining the second identity information based on the first identity information, the second identity information including the public key certificate and / or attribute certificate of the second device, the public key certificate being obtained by signing the public key of the second device with the private key of the first device, and the attribute certificate being obtained by signing the public key of the second device with the private key of the first device; and sending the second identity information to the second device.

[0051] In conjunction with the fifth aspect, in some possible implementations of the fifth aspect, the method further includes: receiving a fourth request message from the second device, the fourth request message carrying the second identity information, the fourth request message being used to request the publication of the second identity information in the DL; and sending a second response message to the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

[0052] It should be understood that the technical solution of the fifth aspect corresponds to the technical solution of the fourth aspect and has the same technical effect as the fourth aspect. For details on the technical effect of the fifth aspect, please refer to the relevant description of the fourth aspect; further details will not be repeated here. In conjunction with the fourth or fifth aspect, in some possible implementations, the second response message may also carry one or more of the following: an identifier of the second identity information, the address of the second identity information in the DL, or a credential of the DL, wherein the credential of the DL is used to verify the identity of the device in the DL's network.

[0053] For details regarding the identification of the second identity information, the address of the second identity information in the DL, and the technical effects of the DL's credentials, please refer to the first aspect above, which will not be repeated here.

[0054] Sixthly, a communication method is provided, which can be applied to a second device, for example, executed by the second device. The second device may be a terminal, a RAN node, or a core network NF, or a component in the terminal, RAN node, or core network NF, such as a chip, chip system, or processor, or a logic module or software capable of implementing some or all of the functions of the terminal, RAN node, or core network NF, etc., and this application does not limit it in this regard.

[0055] For example, the method includes: sending a first authentication request to a fifth device, the first authentication request being used to request authentication of second identity information of a second device, the first authentication request including first information and a first signature, the first information including: an identifier of the second identity information of the second device and / or a public key credential of the second device, the identifier of the second identity information of the second device being used to identify the second identity information of the second device published in the distributed ledger DL, the public key credential of the second device being used to verify a signature from the second device, the first signature being obtained by signing the first information based on the private key of the second device, the fifth device being a device in the network of the DL; and receiving a first authentication response from the fifth device, the first authentication response being used to indicate the authentication result of the second device.

[0056] Based on the above scheme, devices in the DL network can authenticate the second device without having to go through the network of their contracted operator, thus achieving ubiquitous authentication with a simple authentication process. Furthermore, after accessing the DL network, the second device can also authenticate the peer node for communication or services.

[0057] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the first information may further include one or more of the following: a session identifier, or the address of the second identity information in the DL, wherein the session identifier is used to identify the session corresponding to the first authentication request.

[0058] The session identifier can be used to identify the session of the first authentication request. The session identifier can be, for example, a random number or other identifiers, such as a packet data unit (PDU) session ID, etc., without limitation. The session identifier can be used by the device receiving the first information (such as the fifth device below) to sign it, thereby facilitating the second device to verify the signature of the fifth device and realize the identity authentication of the fifth device.

[0059] The address of the second identity information in the DL can facilitate the device receiving the first information (such as the fifth device below) to search for the second identity information in the DL, and then obtain the issuer information, public key certificate, etc. of the second identity information, thereby facilitating the verification of the identity of the second device.

[0060] Public key credentials can be used to obtain a public key, enabling a fifth device receiving the public key credential to verify the signature of the second device, such as verifying the second signature. Including the public key credential in the first information allows the fifth device to quickly obtain the public key, improving efficiency.

[0061] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the first authentication response includes second information and a second signature, the second information including the authentication result and the public key credential of the fifth device, and the second signature being obtained by signing the second information based on the private key of the fifth device; the method further includes: verifying the public key credential of the fifth device based on the credential of the DL; and verifying the second signature based on the public key credential of the fifth device.

[0062] Based on the above scheme, the second device can authenticate the identity of the fifth device. Thus, the second device can determine the validity of the fifth device's credentials, and if authentication is successful, obtain the data from the DL from the fifth device, thereby ensuring the authenticity of the data obtained by the second device from the fifth device.

[0063] Optionally, the method further includes: verifying the public key credentials of the fifth device based on the credentials of the DL.

[0064] Verifying the public key credentials of the fifth device using DL's credentials, that is, authenticating devices in DL's network using DL's public key credentials, can ensure the legitimacy of the fifth device.

[0065] Optionally, the second information may further include one or more of the following: an identifier of the second identity information of the first device, a random number, or a session identifier, wherein the session identifier is used to identify the session corresponding to the verification request.

[0066] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the method further includes: receiving a second authentication request from a sixth device, the sixth device being a device in the network of the DL, the second authentication request carrying an identifier of the identity information of the sixth device, the identifier of the identity information of the sixth device being used to identify the identity information of the sixth device published in the DL; obtaining the identity information of the sixth device according to the second authentication request; authenticating the sixth device according to the identity information of the sixth device; and sending a second authentication response to the sixth device, the second authentication response being used to indicate the authentication result of the sixth device by the second device.

[0067] Since the identity information of the devices published to the DL is stored in the DL, the second device does not need to pre-install the issuer information of the credentials of other devices (such as the sixth device) locally. It can obtain the identity information of the authenticated party simply by searching in the DL, and then authenticate it, which is convenient and secure.

[0068] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the method further includes: sending a third authentication request to a seventh device, the seventh device being a device in the DL network, the third authentication request including the public key credentials and / or attribute credentials of the second device; and receiving a third authentication response from the seventh device, the third authentication response indicating the authentication result of the seventh device on the second device.

[0069] Since the identity information of the devices published to DL is stored in DL, the second device can also be authenticated by other devices in the DL network (such as the seventh device). The seventh device can obtain the identity information of the authenticated party simply by searching in DL, and then authenticate it, which is convenient and secure.

[0070] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the method further includes, before sending the first authentication request to the fifth device, triggering a process of publishing second identity information to the DL.

[0071] The second device may be the same as the second device in the third aspect. It can obtain the certificate issued by the issuer through the process of publishing the second identity information to DL provided by the first to third aspects, thereby providing support for the second device to access the DL network.

[0072] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, triggering the publication of the second identity information into the DL includes: sending a second request message to a first device, the second request message being used to request the publication of the second identity information in the DL, the second request message carrying first identity information, the first identity information including the public key and / or attributes of the second device; the first identity information being used to obtain the second identity information; the second identity information including one or more of the following: the public key of the second device, the public key certificate of the second device, the attribute, the hash of the attribute, the attribute certificate, or the hash of the attribute certificate; wherein, the public key of the second device is used to verify a signature from the second device, the public key certificate of the second device is obtained by signing the public key of the second device based on the private key of the first device, and the attribute certificate is obtained by signing the attribute based on the private key of the first device; the method further includes: receiving a second response message from the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

[0073] The second device can trigger the publication of the second identity information in the DL by sending a second request message carrying the first identity information to the first device.

[0074] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the second response message carries one or more of the following: the second identity information, the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL, the credentials of the DL being used to verify the identity of a device in the DL's network.

[0075] The technical effects of sending the second identity information, the identifier of the second identity information, the address of the second identity information in the DL, and the credentials of the DL to the second device can be found in the above description in conjunction with the first to third aspects, and will not be repeated here.

[0076] In a seventh aspect, a method is provided that can be applied to, for example, executed by, a fifth device. The fifth device can be a device in a DL network, such as a core network NF, or a component in the core network NF, such as a chip, chip system, processor, etc., or a logic module or software capable of implementing some or all of the functions of the core network NF, etc. The core network NF can be, for example, a DLEF, and this application includes, but is not limited to, this method.

[0077] It should be understood that the fifth device in the seventh aspect and the third device in the second aspect may be the same device or different devices, without limitation.

[0078] Exemplarily, the method further includes: receiving a first authentication request, the first authentication request including first information and a first signature, the first information including: an identifier of second identity information of the second device and / or a public key credential of the second device, the second identity information being used to identify the second identity information of the second device published to the DL, the public key credential of the second device being used to verify a signature from the second device, the first signature being obtained by signing the first information based on the private key of the second device; obtaining the second identity information according to the first authentication request; authenticating the second device based on the second identity information; and sending a first authentication response, the first authentication response being used to indicate the authentication result of the second device.

[0079] Based on the above scheme, the fifth device can authenticate the second device based on the second identity information in the DL when it receives the first authentication request, without having to authenticate through the second device's contracted operator network. Therefore, ubiquitous authentication of the second device can be achieved, and the authentication process is simple.

[0080] In conjunction with the seventh aspect, in some possible implementations of the seventh aspect, the first information may further include one or more of the following: a random number, a session identifier, or the address of the second identity information in the DL, wherein the session identifier is used to identify the session corresponding to the authentication request.

[0081] For details on the technical effects of the various contents included in the first information, please refer to the sixth aspect above, which will not be repeated here.

[0082] In conjunction with the seventh aspect, in some possible implementations of the seventh aspect, the authentication of the second device based on the second identity information includes: verifying the public key credential of the second device in the second identity information based on the public key credential of the issuer of the second identity information; and verifying the first signature based on the public key credential of the second device.

[0083] Since the public key credential in the second identity information is signed with the issuer's private key, it can be verified based on the issuer's public key. Furthermore, since the first signature is based on the second device's private key, it can be verified based on the second device's public key. Therefore, the fifth device can authenticate the second device, which helps ensure the security of the DL network and prevents malicious attacks on it.

[0084] Optionally, the first authentication response may also carry one or more of the following: an identifier of the second identity information of the first device and a session identifier, wherein the session identifier is used to identify the session corresponding to the verification request.

[0085] In conjunction with the seventh aspect, in some possible implementations of the seventh aspect, the first authentication response includes second information and a second signature, the second information including the public key credential of the fifth device, the second signature being obtained by signing the second information based on the private key of the fifth device, and the public key credential being used to verify the second signature.

[0086] Based on the above scheme, the second device can authenticate the identity of the fifth device. Thus, the second device can determine the validity of the fifth device's credentials, and if authentication is successful, obtain the data from the DL from the fifth device, thereby ensuring the authenticity of the data obtained by the second device from the fifth device.

[0087] Eighthly, a communication apparatus is provided that can implement the methods described in any one of the first to seventh aspects and in any possible implementation of any one of the first to seventh aspects. The apparatus includes one or more corresponding functional units or modules for performing the described methods. The functional units or modules included in the apparatus can be implemented by software and / or hardware.

[0088] A ninth aspect provides a communication device including a processor, the processor being configured to perform the method described in any one of the first to seventh aspects and in any possible implementation of any one of the first to seventh aspects.

[0089] Optionally, the apparatus may further include a memory for storing instructions and data. The memory is coupled to the processor, which, when executing the instructions stored in the memory, can implement the methods described in the foregoing aspects.

[0090] Optionally, the device may further include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0091] In a tenth aspect, a chip system is provided, the chip system including at least one processor for supporting the implementation of any of the first to seventh aspects and any possible implementation of any of the first to seventh aspects, such as receiving or processing data and / or information involved in the above methods.

[0092] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0093] In one possible design, the chip system further includes an interface circuit and / or a power supply circuit, wherein the interface circuit is used to transmit data and the power supply circuit is used to supply power to the chip system.

[0094] The chip system can consist of chips or include chips and other discrete components.

[0095] Eleventhly, a communication system is provided, comprising one or more of the following: a first device, a second device, and a third device. The first device can be used to implement the method of the first aspect or the fifth aspect, and any possible implementation thereof. The second device can be used to implement the method of the third aspect or the fourth aspect, and any possible implementation thereof. The third device can be used to implement the method of any possible implementation thereof.

[0096] In a twelfth aspect, a communication system is provided, comprising one or more of the following: a second device and a fifth device. The second device can be used to implement the method in any possible implementation of the fifth aspect, and the fifth device can be used to implement the method in any possible implementation of the sixth aspect.

[0097] In a thirteenth aspect, a computer-readable storage medium is provided, including a computer program that, when executed on a computer, causes the computer to implement any one of the first to seventh aspects and any possible implementation of any one of the first to seventh aspects.

[0098] In a fourteenth aspect, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code or instructions) that, when the computer program is run, causes a computer to perform any one of the first to seventh aspects and any possible implementation of any one of the first to seventh aspects.

[0099] It should be understood that aspects eight to fourteen of this application correspond to the technical solutions of aspects one to seven of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0100] Figure 1 is a schematic diagram of the verifiable credential (VC) data model;

[0101] Figure 2 is a schematic diagram of building a digital identity blockchain on a telecommunications network;

[0102] Figure 3 is a schematic diagram of a Merkle tree;

[0103] Figure 4 is a schematic diagram of the system architecture applicable to the method provided in this application;

[0104] Figure 5 is a schematic flowchart of the communication method provided in an embodiment of this application;

[0105] Figure 6 is a schematic flowchart of publishing blocks in a blockchain according to an embodiment of this application;

[0106] Figure 7 is a schematic diagram of devices in different operators publishing digital identities through an aggregation node, as provided in an embodiment of this application;

[0107] Figure 8 is a schematic diagram of a communication method provided in another embodiment of this application;

[0108] Figure 9A is a schematic diagram of a terminal accessing a DL network when not roaming.

[0109] Figure 9B is a schematic diagram of a terminal accessing the DL network while roaming.

[0110] Figure 10 is a schematic diagram of a communication method provided in another embodiment of this application;

[0111] Figure 11A is a schematic diagram of the authentication process of the second device for other devices provided in another embodiment of this application;

[0112] Figure 11B is a schematic diagram of the authentication process of the second device by other devices provided in another embodiment of this application;

[0113] Figure 12 is a schematic block diagram of a communication device provided in an embodiment of this application;

[0114] Figure 13 is another schematic block diagram of the communication device provided in the embodiments of this application. Detailed Implementation

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

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

[0117] First, in this application, the indication includes explicit indication (also known as direct indication) and implicit indication (also known as indirect indication). Explicit indication information A means including information A; implicit indication information A means indicating information A through the correspondence between information A and information B, and direct indication information B. The correspondence between information A and information B can be predefined, pre-stored, pre-burned, or pre-configured; or it can refer to indicating information A through information B and preset rules.

[0118] Second, in this application, information C is used to determine information D, which includes both determining information D based solely on information C and determining it based on information C and other information. Furthermore, information C can also be used to determine information D indirectly, for example, in the case where information D is determined based on information E, and information E is determined based on information C.

[0119] Third, in this application, "at least one" means one or more, and "more than one" means two or more. The expression " / " is used to indicate that the objects before and after are in an "or" relationship; for example, A / B can mean: A or B. The expression "and / or" is used to indicate that the objects before and after are in a relationship of either "and" or "or", for example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the objects before and after are in an "or" relationship, but it does not exclude the possibility that the objects before and after are in a relationship of "and". The specific meaning can be understood in conjunction with the context. "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 mean: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, and c can be single or multiple.

[0120] Fourth, the use of prefixes such as "first" and "second" in this application is solely for the purpose of distinguishing different things belonging to the same name category, and does not constrain the order, size, or quantity of things. For example, "first computing model" and "second computing model" are simply different computing models, and there is no temporal sequence, size, or priority relationship between them; similarly, "first computing task" and "second computing task" are simply different computing tasks, and there is no temporal sequence, size, or priority relationship between them. It should be understood that the objects described in this way can be interchanged where appropriate, so as to describe solutions other than those in the embodiments of this application.

[0121] Fifth, in this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to the terminal" can be understood as the destination of the information being the terminal, which can include direct transmission via the air interface or indirect transmission by other units or modules via the air interface. "Receive information from the terminal" can be understood as the source of the information being the terminal, which can include direct reception from the terminal via the air interface or indirect reception from the terminal by other units or modules via the air interface. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can occur between devices, such as between a terminal and a core network element, or between core network elements, or within a device, such as sending or receiving between components, modules, chips, software modules, or hardware modules within the device via a bus, wiring, or interface.

[0122] Sixth, in the embodiments of this application, "when," "if," and "if" all refer to the device making corresponding processing under certain objective circumstances, and are not limited to a time, nor do they require the device to make a judgment action when it is implemented, nor do they mean that there are other limitations.

[0123] Seventh, in this application, the words "example," "exemplarily," "for example," or "such as" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "example," "exemplarily," "for example," or "such as" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the words "example," "exemplarily," "for example," or "such as" is intended to present the relevant concepts in a specific manner.

[0124] Eighth, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

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

[0126] 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 limit these applications.

[0127] With the development of digital technology, decentralized identity trust frameworks have gradually attracted industry attention. The main characteristics of a decentralized identity trust framework are: First, compared to existing centralized identity management methods, issuers and verifiers no longer need to 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 achieve self-management of their identity information, selectively creating different identity information and VCs as needed, decoupling user identity from issuers, and allowing them to present their VCs to any service provider as needed, achieving cross-domain, multi-party service access and truly realizing digital identity sovereignty.

[0128] Figure 1 is a schematic diagram of the VC data model proposed by the World Wide Web Consortium (W3C). This model illustrates issuers, holders, verifiers, and a verifiable data registry platform. Users (i.e., holders) can generate a public-private key pair. Issuers can issue certificates (i.e., public key credentials, or public key certificates) to users' (i.e., holders') public keys. Issuers can sign the user's public key with their own private key to obtain the certificate. After obtaining the certificate, 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 a VC also has its decentralized identity, and the verifier can use the issuer's DID's public key to verify the holder's VC, thus forming a trusted closed loop. Because the Verifiable Data Registry is an open platform accessible to all holders, holders can send their DID documents to the Verifiable Registry for storage.

[0129] Based on industry-leading digital identity technologies, telecommunications networks, as ubiquitous global connectivity infrastructure, are well-suited to serve as the infrastructure for digital identity, enabling the construction of a blockchain on the telecommunications network 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 vendors (e.g., embedded UICC vendors (EUICC management 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 root credentials of the trusted institutions (e.g., the operator's root certificate) to the blockchain. The user's digital identity includes: an identifier (ID) and a profile. For example, the user can generate their own public-private key pair, using the public key hash or a unified identifier issued by a social authority as the identifier of their digital identity. The overview may include VCs issued (or signed) by various trusted institutions. For example, a VC issued by a social authority can be used to prove that the holder is a legal citizen; a VC issued by a mobile operator can be used to prove that the holder is a mobile phone number; a VC issued by a university can be used to prove that the holder is a student of that university, and so on. These VCs are signed by trusted institutions using private keys and verified using public keys. Since the public key certificates are published on the blockchain, a user's VC can be universally verified, thereby achieving interoperability and mutual trust in identity.

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

[0131] 1. Distributed Ledger: A distributed ledger is a database maintained by multiple nodes that records transactions between network participants, ensuring data consistency and security. Unlike traditional centralized databases, distributed ledgers do not have a social authority managing the data. Instead, they rely on each node in the network to jointly verify, store, and update the data, thus improving data transparency, security, and immutability.

[0132] 2. Blockchain: Blockchain is a form of distributed ledger technology. It is distributed and managed on a peer-to-peer network, and is a decentralized distributed ledger. Data on the blockchain is grouped and organized in the form of blocks, which are linked in chronological order to form a chain and protected by cryptographic techniques. The structure of the blockchain makes it decentralized in both technology and operation, and data cannot be changed or deleted once recorded.

[0133] It does not rely on authoritative social institutions to verify transactions or manage records; instead, it is maintained collaboratively by multiple nodes in the network. Each participating node can maintain a copy of the entire ledger, and once a block is added to the chain, it cannot be altered or deleted. This technology enables data transparency, security, and immutability.

[0134] 3. Consensus: In a blockchain network, all participants (i.e., nodes) need to reach a consensus on the current state, which requires a specific algorithm. Consensus is the process by which peers in a blockchain network reach an agreement on the current state of the data in the network. Consensus algorithms establish reliability and trust in a blockchain network, enabling the system to function properly.

[0135] 4. Digital Identity: This includes identifier (ID), document, and VC (Visual Identity). Document and VC can be collectively referred to as the overview. Details are as follows:

[0136] Identifier: This ID can be used to identify the subject of the digital identity. The ID can be a globally unique identifier. For example, the ID format can be a universally unique identifier (UUID), a format specified by the Hypertext Transfer Protocol (HTTP) or Uniform Resource Identifier (URI), or it can be a subscriber permanent identifier (SUPI), International Mobile Subscriber Identity (IMSI), International Mobile Equipment Identity (IMEI), Permanent Equipment Identifier (PEI), Subscription Concealed Identifier (SUCI), or other formats specified by the 3rd Generation Partnership Project (3GPP). The ID can also be a DID, or the identifier of a client in the DL, etc., as included but not limited to these in this application. The ID can be generated by the subject of the digital identity or by an issuer (such as an operator). This application does not limit this. The digital identity can be stored on the DL 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 DL.

[0137] Documents: Public information, containing descriptive information publicly disclosed by the holder of this digital identity. Examples include, but are not limited to, the following:

[0138] - Subject: Subject information, such as the name of the holder of a digital identity, such as a company, etc.

[0139] - Subject Type (sbjType): Represents the type of subject of digital identity, such as: terminal (e.g., mobile phone, drone, smart car, virtual digital human, IoT device, digital assistant, software phone, cloud phone, etc.), network function (NF), radio access network (RAN) node, organization, etc.

[0140] - Subject Controller (sbjController): Represents the actual controller of the digital identity. For example, when parents control their child's digital identity, the digital identity identifier can be the child's identifier, and the subject controller can be the parents' identifier.

[0141] - Verification Method: A set of cryptographic key materials that can be used for different verification purposes / relationships (e.g., authentication, assertion and key protocols, authorization, etc.) to verify a user's identity. Generally, the entity that generates 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.

[0142] VC: Credential information of the holder, credentials issued by other organizations or users, a collection of statements endorsed by the issuer and verifiable using the issuer's public key. It should be understood that the content published in this credential information is publicly available.

[0143] VC includes two types, as detailed below:

[0144] Public key credential (PK credential): 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 to a user, or a certificate issued by a social authority to a user.

[0145] Attribute credential (AC): An attribute credential contains a user's attributes and can be an attribute certificate held by the user and issued by a trusted third party. Attributes can be viewed as descriptions of the holder, such as descriptions of social status. Examples include, but are not limited to, student ID cards and graduation certificates issued by reputable organizations; work permits issued by companies; identity cards issued by authoritative social institutions; and certificates issued by telecom operators to prove a subscription plan.

[0146] For example, attribute credentials may include one or more of the following:

[0147] Examples of communication attributes and credentials: In the context of the future network industry, communication attributes include permanent user identifiers related to communication issued by operators and various service identifiers and contract information bound to mobile phone numbers, such as profile and location. Credentials serve as proof of these attributes.

[0148] Real Person Attributes and Certificate Examples: Identity certificates formed using real identity documents such as ID cards and passports that are issued by specific administrative agencies in accordance with national laws and regulations, are applicable to the whole society, and have legal effect.

[0149] Third-party attributes and credential examples: Credentials issued by various business systems, applicable to their own systems and related system applications, used for business access, attribute verification, resource access control, etc.

[0150] Digital identity can be referred to as user-centric digital identity (UCDID).

[0151] 5. Address of identity information in DL: This can be determined by the verification path (or storage path) of the identity information in DL. For ease of understanding, the following explanation uses a Merkle tree as an example to illustrate the verification path.

[0152] A Merkle tree is a binary tree. It organizes a database into a tree structure using a hash function. The process of building a Merkle tree can be recursive, starting from the bottom-level leaf nodes. All data blocks are placed into the bottom-level leaf nodes. A hash function is used to calculate the hash value of each data block. The hash values ​​of two adjacent leaf nodes are concatenated, and the hash function is used again to calculate a new hash value, forming a new non-leaf node. Therefore, each leaf node contains the hash value of the data block, while non-leaf nodes are combinations of the hash values ​​of their child nodes (usually the hash value of the concatenated child node hash values). The hash operation on the nodes is repeated to generate new nodes until the last node, called the root node, is produced.

[0153] Figure 3 is a schematic diagram of a Merkle tree. For ease of understanding, different data blocks will be represented by letters A to P, and H will be used to represent different data blocks. x Let H represent the hash value calculated using a hash function on data block x, where x can be one or more from A to P. As shown in the diagram, 16 data blocks A to P are placed in the bottom-level leaf nodes. After calculating the hash value for each data block using the hash function, the hash values ​​of two adjacent nodes are concatenated and a new hash value is calculated again using the hash function. As shown in the diagram, the hash value H of data block A is... A The hash value H of B B After concatenation, a new hash value H is obtained by using a hash function again. AB This allows the creation of new nodes, into which data blocks H are placed. AB The hash value H of data block C C And the hash value H of data block D D After concatenation, a new hash value H is obtained by using a hash function again. CD This allows the creation of new nodes, into which data blocks H are placed. CD Similarly, new nodes can be obtained, and the data blocks to be placed are H. EFH GH H IJ H KL H MN H OP Repeating the above process will result in a new layer of nodes, each containing a data block named H. ABCD H EFGH H IJKL H MNOP Repeating the above process again yields a new layer of nodes, each containing a data block named H. ABCDEFGH H IJKLMNOP Repeating the above process again yields the top-level root node, into which the data block H is placed. ABCDEFGHIJKLMNOP .

[0154] The verification path refers to all sibling nodes along the Merkle tree path from the bottom-level leaf node to the Merkle root, excluding the Merkle root itself. Once the verification path is obtained, the Merkle root can be calculated using the transaction hash. As shown in the diagram, H... K The transaction verification path is H. L H IJ H MNOP H ABCDEFGH ; possess H K When the hash value of transaction K is obtained, the Merkle Root can be calculated.

[0155] Identity information in a blockchain (i.e., a type of deep learning) can also be indicated by transaction addresses and block heights. A transaction address is a unique identifier used to receive or send cryptocurrency. Each transaction address is unique on the blockchain, ensuring the accuracy and security of transactions. A transaction address typically consists of a string of characters, similar to a bank account number, used to identify the specific location where cryptocurrency is received or sent. Block height refers to the number of blocks between a given block and the genesis block (the first block). The genesis block has a height of 0, and each subsequent block increases the height by 1. Block height is an important indicator of the blockchain's development, representing how many blocks have been generated and confirmed. A higher block height means more transactions and verifications, and is generally considered a sign of a more secure and reliable network.

[0156] On a blockchain, each transaction is recorded in a block, and each block has a unique block height. The transaction address identifies the initiator, recipient, and content of the transaction, while the block height indicates the block's specific location on the blockchain. By using the transaction address or block height, the specific information and confirmation status of each transaction can be traced and verified.

[0157] 6. DL Network: Devices participating in the maintenance and / or querying of the DL constitute the DL network. Devices participating in the DL network (such as NF, RAN nodes, servers, etc.) may directly maintain and query the DL (i.e., have one or more of the following permissions: consensus, querying, or writing to the DL), or may participate in the maintenance and querying of the DL through other devices (i.e., do not have consensus, querying, and writing permissions to the DL themselves, but can perform the above operations through other devices, such as terminals, etc.).

[0158] Devices participating in a DL network can be called nodes in the DL network, including but not limited to RAN nodes, NFs, servers, etc.

[0159] In one possible design, the terminal is a node in the DL network; alternatively, the nodes in the DL network may also include the terminal.

[0160] In another possible design, the terminal is not a node in the DL network, but can obtain services from the DL network.

[0161] Figure 4 is a schematic diagram of the system architecture applicable to the method provided in this application. Figure 4 shows some network elements in the terminal side, RAN node, and core network. The terminal side can communicate with core network elements through the RAN node.

[0162] In this system, the terminal (including mobile phones, drones, smart cars, and also virtual digital humans, digital assistants, software phones, cloud phones, etc.) holds a digital wallet. This digital wallet can be built into a universal integrated circuit card (UICC) or installed on the terminal as software or an application (APP). The terminal (or UICC) can generate public and private keys as the public and private keys for this digital wallet.

[0163] Core network elements may include, but are not limited to, IDM network elements, distributed ledger enable function (DLEF), archive node, NF, ledger anchor function (LAF) network elements, security edge protection proxies (SEPP), etc.

[0164] In this context, the IDM can be responsible for signing and endorsing user information. For example, after a 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.

[0165] DLEF is a node in DL (Digital Identity Provider). It can receive digital identity information from the IDM (Integrated Device Manager) or the terminal itself and publish this information to the distributed database. DLEF can store all data in the distributed database. For example, in a digital identity blockchain, DLEF can store all blockchain data.

[0166] The accounting node can be a private node of the operator. It can work with a distributed database to complete data storage and can also be used to store private information.

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

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

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

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

[0171] IDM also has an interface with DLEF. IDM is responsible for sending digital identity information to DLEF for terminals or NFs. IDM can also query information stored in the distributed database from DLEF.

[0172] DLEF has an interface with the terminal. As a storage network element (such as a blockchain node) in a distributed database, DLEF can be responsible for publishing the digital identity information of the terminal and querying the information stored in the distributed database by the terminal.

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

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

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

[0176] It should be understood that Figure 4 is merely an example, showing 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 limitations on this.

[0177] 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 terminals, access network devices, or core network elements.

[0178] The communication method provided in this application will now be described in detail with reference to the accompanying drawings.

[0179] It should be noted that in the various embodiments described below, the devices or network elements corresponding to each device are merely examples and should not constitute any limitation on this application. These devices are only classified from a functional perspective. In actual deployment, some devices may be housed in a single entity, while others may be deployed separately in different entities. Furthermore, the correspondence between a device and an equipment can refer to the device itself, or to components within the device, such as chips, chip systems, processors, or logic modules or software used to implement their respective functions, etc. This application does not impose any limitations in this regard.

[0180] Figure 5 is a schematic flowchart of the communication method 400 provided in an embodiment of this application, mainly describing a possible implementation of the publication of the digital identity of the second device (hereinafter referred to as the second identity information) in the DL. It should be understood that the publication of the digital identity of the second device in the DL can be regarded as the registration of the second device in the DL. After the digital identity of the second device is published in the DL, the second device can communicate with other devices in the DL network through the issuer that endorses it.

[0181] The method 400 shown in Figure 5 includes steps 401 to 404. Optionally, it also includes one or more of steps 401', 401'', 405 to 407. The various steps in method 400 are described in detail below.

[0182] In step 401, the first device obtains the first identity information of the second device.

[0183] For example, the first device can be responsible for signing and endorsing the user's information. This first device may correspond to an IDM, or it may correspond to an AF, which may be an interface opened by the operator to a third-party social authority. The second device may correspond to a terminal, RAN node, or NF, or other device that wishes to publish its digital identity in the DL.

[0184] The first identity information is information that can be used to identify the identity of the second device, and can be used for the authentication of the second device, or may also be used to authenticate other devices. For example, the first identity information may include the public key and / or attributes of the second device. The public key may be the public key in a public-private key pair generated by the second device, and can be used for authentication of the second device in the DL network, for example, it can be used by other devices in the DL network to authenticate the identity of the second device (or, in other words, for authenticating the second device itself). Attributes are properties that can represent the subject of the second device, and can also be used by other devices to authenticate the identity of the second device. Attributes include, but are not limited to, being 18 years of age or older, a legal citizen, having subscribed to a certain plan with an operator, etc., and this application includes but is not limited to these.

[0185] Optionally, the first identity information also includes an identifier of the first identity information, which can be regarded as the identifier of the subject of the digital identity. The identifier of the subject of the first identity information can be used to identify the second device in the DL. The identifier of the first identity information can be, for example, the identifier of the second device, such as SUPI, SUCI, IMSI, IMEI, IPEI, etc., which can be used to indicate the device, or it can be the identifier of the client in the DID or DL, etc., and this application does not limit it in this way. Among them, the identifier of the client in the DID or DL ​​can be, for example, the hash of the public key of the second device.

[0186] It should be understood that the identifiers of the identity information mentioned in the embodiments of this application, such as the identifier of the first identity information and the identifier of the second identity information (hereinafter referred to as the identifier of the second device), are named for the purpose of distinguishing the second device. Both the identifier of the identity information and the identifier of the second device can be used to identify the second device, but the scope of application is different. The identifier of the identity information is used to identify the second device in the DL network, and the identifier of the second device is used to identify the second device within the network service scope provided by the operator. In some cases, the identifier of the second device and the identifier of the identity information are the same.

[0187] In this embodiment, the first identity information can be used to obtain the second identity information, or in other words, the second identity information can be obtained based on the first identity information. The second identity information can be considered the digital identity of the second device, and is identity information that can be published in the DL (Digital Domain).

[0188] The first device can obtain the first identity information of the second device in various ways. For example, the first identity information of the second device can be stored in the first device, and if the second device needs to publish its digital identity information, the first device can obtain the first identity information of the second device locally. Another example is that the first identity information of the second device can be information entered by a staff member into the first device, and the first device can obtain the first identity information of the second device through human-computer interaction. Yet another example is that the first identity information of the second device can be sent by the second device to the first device. This application does not limit the specific implementation method by which the first device obtains the first identity information of the second device.

[0189] Optionally, step 401 specifically includes: the first device receiving first identity information from the second device. Accordingly, the second device sending the first identity information to the first device.

[0190] In one possible implementation, the second device sends first identity information to the first device, including: the second device sending a request message #1 (i.e., an example of a second request message) to the first device, the request message #1 carrying the first identity information, the request message #1 being used to request the first device to endorse the first identity information of the second device.

[0191] It should be understood that the figure is only an example, illustrating step 401 by taking the first device receiving the first identity information from the second device as an example, but this should not constitute any limitation on the specific implementation of how the first device obtains the first identity information of the second device.

[0192] Optionally, before step 402, the method further includes step 401': the first device successfully verifies the first identity information.

[0193] The first device can verify the first identity information of the second device, and after successful verification, obtain the second identity information based on the first identity information. For example, the first device can obtain the second identity information based on the first identity information after successfully verifying the second device.

[0194] As mentioned above, the first identity information includes the public key and / or attributes of the second device. In other words, the verification of the first identity information by the first device may specifically include the verification of the public key and / or the verification of the attributes.

[0195] For example, the first device's verification of the public key primarily involves verifying the signature of the first device based on the public key. For instance, the second device could send a signature containing the second device's public key and a hash of a historical message (such as a message from the main authentication process) using its private key. The first device could then verify this signature using the public key to confirm that the second device is the holder of the public key.

[0196] The first device's verification of attributes is attribute-related. For example, if the attributes included in the first identity information are business-related attributes such as the location of the second device, the first device can directly verify them based on the contract information or network status.

[0197] It should be understood that the specific method by which the first device verifies the first identity information of the second device is not limited.

[0198] Corresponding to the information included in the first identity information, the second identity information includes one or more of the following: a public key, a public key credential, an attribute, a hash of the attribute, an attribute credential, or a hash of the attribute credential. As an example, the first identity information includes a public key and an attribute, and the second identity information includes a public key credential and an attribute credential.

[0199] It should be understood that, for the purpose of publication, the public key and the public key credential serve the same purpose, as do the attribute, the hash of the attribute, the attribute credential, and the hash of the attribute credential. Therefore, the second identity information may include the public key or the public key credential, and / or, the second identity information may include one of the attribute, the hash of the attribute, the attribute credential, or the hash of the attribute credential.

[0200] In one implementation, the first device can sign the first identity information based on its own private key, or endorse the first identity information, to obtain the second identity information.

[0201] Optionally, before step 402, the method further includes step 401: the first device generates second identity information based on the first identity information.

[0202] For example, when the first identity information includes the public key of the second device, the second identity information may include the public key credential of the second device. The first device can sign the public key of the second device based on its own private key to obtain the public key credential of the second device.

[0203] For example, when the first identity information includes attributes of the second device, the second identity information may include attribute credentials of the second device. The first device may sign the attribute based on its own private key to obtain the attribute credentials of the second device.

[0204] For example, when the first identity information includes attributes of the second device, the second identity information may include a hash of the attribute credential of the second device. The first device may sign the attribute based on its own private key to obtain the attribute credential of the second device, and then process the attribute credential to obtain the hash of the attribute credential of the second device.

[0205] In another implementation, the first device can directly use the first identity information or the hash of the first identity information as the second identity information.

[0206] For example, when the first identity information includes the public key of the second device, the second identity information may also include the public key of the second device. For example, when the first identity information includes attributes of the second device, the second identity information may include the attributes of the second device or a hash of the attributes.

[0207] In one possible design, the first identity information includes the public key and / or attributes of the second device. The second identity information includes the hash of the public key credential and / or attribute credential of the second device. That is, the first device issues a credential to the first identity information to obtain the second identity information.

[0208] It should be understood that the second identity information is not limited to including public keys, public key credentials, attributes, attribute credentials, hashes of attributes, hashes of attribute credentials, etc., but may also include other information. For example, the first identity information may also include one or more of the following: the identifier of the first identity information, the type of the second device, the verification method of the second device, the controller of the second device, the subject of the second device, etc. Correspondingly, the second identity information may also include one or more of the following: the identifier of the second identity information, the type of the second device, the verification method of the second device, the controller of the second device, the subject of the second device, etc. More detailed information about the second identity information can be found in the relevant explanations of digital identity in the terminology explanation above, and will not be repeated here. The identifier of the second identity information can be obtained based on the identifier of the first identity information. For example, the identifier of the second identity information can be the same as or different from the identifier of the first identity information. For instance, the identifier of the second identity information can be obtained by processing the identifier of the first identity information. This application does not limit this.

[0209] In step 402, the first device sends a request message #2 to the third device, which requests the publication of second identity information in DL. Correspondingly, the third device receives the request message #2 from the first device.

[0210] For example, the third device may correspond to a node in the DL network, such as the DLEF. The third device and the first device may belong to the same operator or different operators; this application does not limit this.

[0211] The request message #2 (i.e., an example of the first request message) may include second identity information to facilitate its publication in the DL. Upon receiving the second identity information, the third device may execute step 403, triggering the publication of the second identity information in the DL.

[0212] Optionally, the request message #2 includes second identity information and a second identity information signature. The second identity information signature can be obtained by the first device signing the second identity information using its own private key. This second identity information signature can be used by a third device to verify the second identity information, confirming that the second identity information indeed originates from the first device. The third device can verify the second identity information signature based on the first device's public key, and can execute step 403 if the verification is successful.

[0213] In step 403, the third device triggers the publication of the second identity information in DL.

[0214] Upon receiving request message #2, the third device can trigger the publication of the second identity information in the DL. As mentioned earlier, the second identity information includes one or more of the following: a public key, a public key credential, an attribute, a hash of the attribute, an attribute credential, or a hash of the attribute credential. The third device can also issue a credential for the second device's public key even if the first device has not issued one. That is, the third device can sign the second device's public key using its own private key to obtain a public key credential. Similarly, the third device can also issue a credential for the second device's attributes even if the first device has not issued one. That is, the third device can sign the second device's attributes using its own private key to obtain an attribute credential. Since the attribute credential contains attributes and may involve the holder's privacy, it may not be published in the DL. For example, it can be processed by converting the attribute credential into a hash of the attribute credential.

[0215] Thus, the publication of second identity information in the DL can include one or more of the following: public key credentials, hashes of attributes, or hashes of attribute credentials. For security reasons, second identity information may contain privacy-related information; therefore, it can be processed before being published in the DL. For ease of distinction and explanation, the information published in the DL after processing second identity information will be referred to as third identity information. It can be understood that third identity information can be the second identity information itself, a portion of the second identity information, or information derived from the second identity information. Therefore, third identity information is second identity information, or processed second identity information. Publishing third identity information in the DL is merely for security reasons, processing any privacy-related information that may exist in the second identity information. Third identity information is introduced for ease of distinction and description; its essence is still the publication of second identity information, or it can also be called the publication of processed second identity information. Alternatively, it can be said that this third identity information can be considered a possible form of second identity information published in the DL.

[0216] The third device can broadcast the third identity information in the DL network to synchronize the third identity information to various distributed databases in the DL network, thereby completing the publication of the third identity information in the DL; or, the third device can also send the third identity information to other nodes in the DL so that the third identity information can be published in the DL through other nodes.

[0217] As an example, if the DL is a blockchain, the publication of the second identity information in the DL can be done by publishing it in the form of a block within the blockchain. More specifically, the publication of the second identity information in the DL can include: obtaining a transaction based on the second identity information; obtaining a block based on the transaction; and triggering consensus on the block within the blockchain network.

[0218] A block can include one or more transactions. Secondary identity information can be processed into a transaction (which can be understood as belonging to one or more transactions included in the block) and then packaged into a block.

[0219] The following section, using Figure 6 as an example, describes the publication of a second identity information by taking the publication of a block in a blockchain.

[0220] Figure 6 illustrates devices 1 to m that send transactions to the aggregation node, and transactions 1 to n sent by devices 1 to m, where n can be greater than or equal to m, and both n and m are positive integers. That is, each device can send one or more transactions to the aggregation node. The third device can be any one of devices 1 to m.

[0221] Each of devices 1 to m can obtain transactions 1 to n through a smart contract. Taking the third device as an example, in one instance, the second identity information includes one or more of the following: a public key credential, a hash of an attribute credential, or a hash of an attribute; that is, the second identity information does not include information involving privacy. After obtaining the second identity information, the third device can directly call the smart contract, using the second identity information as input to generate a transaction through the smart contract. In this case, the second and third identity information are the same. In another example, the second identity information includes one or more of the following: a public key, an attribute credential, or an attribute; that is, the second identity information includes information involving privacy. After obtaining the second identity information, the third device can process the second identity information to obtain third identity information, which may include, for example, one or more of the following: a public key credential, a hash of an attribute credential, or an attribute credential. The third device can call the smart contract, using the third identity information as input to generate a transaction through the smart contract. In this case, the second and third identity information are different, but it can be understood that the third identity information is obtained by processing the second identity information. Therefore, the transaction can be described as being obtained based on a second identity information.

[0222] For example, the transaction includes: an initiator, a recipient, transaction content, and a transaction signature. In this embodiment, the initiator of the transaction indicates the issuer or the party to which the issuer belongs of the second device's credentials (including public key credentials and / or attribute credentials), such as the operator or organization to which the issuer belongs. In the above embodiment, the issuer of the second device's credentials can be the first device or the third device; therefore, the initiator of the transaction can indicate the first device or its party, or it can indicate the third device or its party. The recipient of the transaction indicates a smart contract, such as the identifier of the smart contract. The transaction content is third identity information (or, in other words, second identity information or processed second identity information), or the transaction content is third identity information and a third identity information signature. The transaction signature can be a signature of the transaction content by the third device based on its own private key, or the transaction signature can be a signature of the initiator, recipient, and transaction content by the third device based on its own private key.

[0223] It should be understood that the issuer of the credentials for the second device can specifically refer to the issuer of the public key credentials and / or attribute credentials for the second device. Since the public key credentials and / or attribute credentials for the second device can be included in the third identity information, the issuer of the credentials for the second device can also be referred to as the issuer of the third identity information, or, in other words, the issuer of the second identity information.

[0224] For example, a third device can publish its third-party identity information to the blockchain through a aggregation node in the blockchain, publishing it as a block. One possible implementation is that the aggregation node in the blockchain obtains a block based on the third-party identity information and then publishes the block to the consensus node set. Each consensus node in the consensus node set confirms the block by executing a consensus algorithm, such as the Reliable, Replicated, Redundant, and Fault-Tolerant (RAFT) algorithm or the Practical Byzantine Fault Tolerance (PBFT) algorithm. The confirmed block is then synchronized on the blockchain by the consensus nodes. Upon receiving this synchronization message, the third device can write a block locally and, after completing the block writing, confirm that the transaction information has been published on the blockchain.

[0225] One possibility is that the third device is not a convergence node in the blockchain, as shown in Figure 6. The third device can send the aforementioned transactions to the convergence node of the blockchain so that the convergence node can publish the block. It is understood that the convergence node in the blockchain may receive multiple transactions from multiple devices. Therefore, the convergence node can package these multiple transactions into a block, sign the block based on its own private key, and publish it to the blockchain. It should be understood that the aforementioned multiple devices and the convergence node may belong to different operators or the same operator; this application does not limit this.

[0226] Another possible scenario is that the third device is a aggregation node in the blockchain. In this case, one of the devices 1 to m in Figure 6 could be the same device as the aggregation node, and the transactions sent by this device to the aggregation node can be considered internal communication within the device. The third device can not only obtain transactions based on the second identity information, but also receive one or more transactions from other devices in the blockchain. This third device can package the received transactions and its own obtained transactions into a block, sign the block based on its private key, and publish it to the blockchain. It should be understood that the other devices in the aforementioned blockchain and the third device may belong to different operators or the same operator; this application does not limit this.

[0227] It should be understood that the term "convergence node" is a name given from a functional perspective. It can be an independent entity or integrated with other network elements in a network element. This application does not limit this.

[0228] An example of a block is as follows: Block i{Header,ContentMerkle{TX1,TX2,…,TXn}}.

[0229] Here, Block i represents block i, which is a package of transactions 1 to n; Header represents the block header; and ContentMerkle{TX1,TX2,…,TXn} represents the block body, which is the content of the block. Merkle refers to all transactions in the block as represented by a Merkle tree, where {TX1,TX2,…,TXn} represents n transactions.

[0230] It should be understood that the examples of blocks mentioned above are for illustrative purposes only and should not be construed as limiting the scope of this application. This application does not limit the specific structure of the blocks.

[0231] The aggregation node broadcasts the block to other consensus nodes in the blockchain. Each consensus node confirms the block (such as block i above) by executing a consensus algorithm, such as RAFT or PBFT. The confirmed block i is then synchronized on the blockchain by the consensus nodes. Devices 1 to m, acting as on-chain nodes, receive this synchronization message and can then write a block locally. After completing the block writing, they can confirm the transaction information and publish it on the blockchain.

[0232] It should be understood that Figure 6 is merely an example, using blockchain as an example to illustrate the process of publishing the second identity information. As mentioned earlier, deep learning technology is not limited to applications in blockchain; third identity information can also be published to distributed databases, such as the Interplanetary File System (IPFS) database. In this case, the aforementioned smart contract can be replaced by an interface that calls the database. Publishing the third identity information to a distributed database can be achieved by calling the database's interface, which then synchronizes the third identity information to the distributed database.

[0233] In step 404, the third device sends a response message #2 to the first device, which indicates the publication result of the second identity information in DL.

[0234] The third device can confirm that the publication of the second identity information in the DL has been completed, or in other words, successfully completed, upon receiving a response message from another device in the DL network regarding the broadcast of the third identity information. For example, in a blockchain, the third device can confirm that the publication of the second identity information in the blockchain has been completed, or in other words, successfully completed, upon receiving a synchronization message from a consensus node (i.e., an example of the response message mentioned above).

[0235] If the second identity information is successfully published in DL, the third device can notify the first device that the publication of the second identity information in DL has been completed, or that the publication was successful, by sending a response message #2 (i.e., an example of the first response message); if the publication of the second identity information in DL fails, the third device can notify the first device that the second identity information was not published in DL, or that the publication failed, by sending a response message #2.

[0236] Optionally, if the second identity information is successfully published in the DL, the method further includes: the first device obtaining one or more of the following from the third device: the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL.

[0237] The address of the second identity information in the DL can refer to the storage address of that second identity information within the DL. For example, in a blockchain, the address of the second identity information in the blockchain can include the transaction address and the block height. More detailed information regarding the address of the second identity information in the DL can be found in the relevant description in the terminology section above, and will not be repeated here.

[0238] The credentials of a DL (Deep Provider) can be used to verify the identity of devices within the DL's network. These credentials can be, for example, a public key or public key certificate generated when the DL is created. The DL's credentials can also be used to generate certificates for each device within the DL's network. For instance, the public key certificates for each device in the DL's network can be obtained by signing their respective public keys based on the DL's private key. Therefore, the DL's credentials can be used to verify the public key credentials of each device within the DL's network. Since the public key credentials of each device in the DL's network can be issued after their respective identities have been verified, it can also be said that the DL's credentials can be used to verify the identity of each device within the DL's network.

[0239] In one possible design, the first device may obtain one or more of the above from the received response message #2: the address of the second identity information in the DL or the credential of the DL. In other words, the response message #2 also carries one or more of the above: the identifier of the second identity information, the address of the second identity information in the DL, or the credential of the DL.

[0240] Optionally, the method further includes step 405: the first device sends a response message #1 to the second device, the response message #1 indicating the publication result of the second identity information in DL. Accordingly, the second device receives the response message #1 from the first device.

[0241] After receiving response message #2, the first device can also notify the second device of the publication result of the second identity information in DL.

[0242] Optionally, the method further includes the first device sending one or more of the following to the second device: an identifier of the second identity information, an address of the second identity information in the DL, or a credential of the DL. Correspondingly, the second device receives one or more of the following from the first device: an identifier of the second identity information, an address of the second identity information in the DL, or a credential of the DL.

[0243] The first device can forward the information received from the third device to the second device, and the second device can store the received information locally so that after the second device accesses the DL network, it can communicate directly with other devices in the DL network.

[0244] In one possible design, one or more of the above can be carried in response message #1. In other words, response message #1 carries one or more of the following: the identifier of the second identity information, the address of the second identity information in the DL, or the DL's credentials.

[0245] Optionally, the first device may not send the address of the second identity information in the DL and the DL's credentials to the second device. The second device may also not be connected to the DL network. In this case, if the second device needs to communicate with other devices in the DL network later, it can also do so through the first device.

[0246] Optionally, the method further includes step 406: the first device sends backup information to the fourth device. Accordingly, the fourth device receives backup information from the first device; and step 407: the fourth device saves the backup information.

[0247] The backup information may include the correspondence between the backup information of the second device and the information published to the DL.

[0248] Optionally, the method further includes: the third device sending information published to the DL to the first device. Accordingly, the first device receives the information published to the DL from the third device.

[0249] As mentioned above, the third device can respond to request message #2 to trigger the publication of the second identity information in DL. One possible form of the publication of the second identity information in DL is the third identity information. Therefore, the third device sending the information published in DL to the first device can also be replaced by the third device sending the third identity information to the first device.

[0250] One possible design is that the third identity information is carried in response message #2, or in other words, response message #2 carries the information published to DL. In this case, for the third device, sending the information published to DL to the first device and step 404 can be the same sending step; for the first device, receiving the information published to DL from the third device and step 404 can be the same receiving step.

[0251] As mentioned above, the first device can obtain first identity information; in other words, the first device holds a public key and / or attributes. Therefore, the first device can associate the information published in the DL with the original text based on the information published in the DL. For example, if the information published in the DL includes the hash of an attribute, the first device can associate the attribute with the hash of the attribute to obtain the correspondence between the attribute and the attribute hash. Or, if the information published in the DL includes the hash of an attribute credential, the first device can associate the attribute credential with the hash of the attribute credential to obtain the correspondence between the attribute credential and the attribute hash. Furthermore, if the information published in the DL also includes the identifier of second identity information, the first device can also associate the identifier of the second identity information with the identifier of the second device to obtain the correspondence between the identifier of the second identity information and the identifier of the second device.

[0252] It should be understood that the first device does not necessarily need to obtain the information published to the DL from the third device. Since the first device has already obtained the first identity information in step 401, the first device can also calculate the hash of the attribute itself based on the first identity information, or calculate the hash of the attribute credential after obtaining the attribute credential by signing the attribute, etc. This application does not limit this.

[0253] The first device can store the backup information in a fourth device. This fourth device could be, for example, a private node of an operator; therefore, the backup information stored in the fourth device is not publicly disclosed and has a high level of security. Because this backup information involves user privacy, it can also be referred to as private information, privacy information, etc.

[0254] One possibility is that the first device and the fourth device are housed in the same physical device. In this case, step 406 can be considered as internal communication within the device. Alternatively, steps 406 and 407 can be combined into one step: the first device (or the fourth device) saves backup information.

[0255] For example, the backup information includes one or more of the following:

[0256] The mapping between attributes and their hashes published in DL;

[0257] The mapping between attribute credentials and the hashes of attribute credentials published in DL; or

[0258] The correspondence between the identifier of the second identity information and the identifier of the second device.

[0259] As mentioned above, for security reasons, the third device may publish the hash of the attribute or the hash of the attribute credential to the DL. For ease of management, the first device may, after confirming the publication of the second identity information in the DL, store the original text of the attribute and the hash of the attribute in the fourth device, or store the original text of the attribute credential or the hash of the attribute credential in the fourth device.

[0260] The identifier of the second device refers to the identifier used to indicate the second device within the network service range provided by the operator, such as SUPI, IMSI, IMEI, or PEI. For security reasons, the identifier of the second identity information published in the DL is not necessarily the identifier of the second device. In this case, the first device can also store the correspondence between the identifier of the second identity information and the identifier of the second device in the fourth device, thereby facilitating the management of the second device.

[0261] It should be understood that after obtaining the first identity information in step 401, the first device can obtain the backup information and cache it locally. After receiving a message indicating that the second identity information has been published in DL (such as the response message #2 mentioned above), the first device can determine the backup information and send the backup information to the fourth device for storage.

[0262] Based on the above scheme, the first device can verify the first identity information of the second device and send the second identity information obtained based on the first identity information to the third device. The third device is a device in the DL network, thus triggering the publication of the second identity information in the DL. This realizes the publication of the digital identity of devices in the telecommunications network in the DL. In this way, if identity authentication of the second device is required, its digital identity information can be retrieved from the DL for authentication, enabling interoperability and mutual trust of the second device's digital identity information across various services. Simultaneously, this scheme also supports identity authentication for the second device's subsequent access to the DL network.

[0263] Furthermore, since the digital identity of the second device published to DL is a digital identity verified and credentialed by the issuer, it has a high degree of credibility. This is more secure than the holder registering their digital identity themselves with a verifiable data registration platform.

[0264] It should be understood that the second device, the third device, and the aggregation node in the above embodiments may belong to the same operator or different operators. For ease of understanding, the following description will be provided in conjunction with the accompanying drawings.

[0265] Figure 7 illustrates a schematic diagram of devices from different operators publishing their digital identities through a convergence node. As shown in Figure 7, Terminal 1 is a subscribed user of Operator 1 and is an example of a second device; Terminal 2 is a subscribed user of Operator 2 and is another example of a second device.

[0266] Within the network service range provided by Operator 1, Terminal 1 can complete the publication in DL through the following process: In step ①-1, Terminal 1 generates first identity information and sends it to the core network NF (such as IDM1) of Operator 1 (i.e., an example of the first device) through step ②-1. IDM1 obtains second identity information based on the first identity information and sends it to another core network NF (such as DLEF1) of Operator 1 (i.e., an example of the third device) through step ③-1. In step ④-1, DLEF1 calls the smart contract to obtain transaction 1 and sends transaction 1 to the aggregation node through step ⑤-1.

[0267] Within the network service range provided by Operator 2, Terminal 2 can also complete the publication in DL through a similar process: In step ①-2, Terminal 2 generates first identity information and sends it to the core network NF (such as IDM2) of Operator 2 (i.e., another example of the second device) through step ②-2. IDM2 obtains second identity information based on the first identity information and sends it to another core network NF (such as DLEF2) of Operator 2 (i.e., another example of the third device) through step ③-2. In step ④-2, DLEF2 calls the smart contract to obtain transaction 2 and sends transaction 2 to the aggregation node through step ⑤-2.

[0268] The aggregation node shown in Figure 7 belongs to the core network NF of operator 3 (such as DLEF3). It can execute step ⑥, packaging the received transactions (including but not limited to transactions 1 and 2 mentioned above) into blocks and sending them to the consensus node set. The consensus node set shown in Figure 7 includes consensus node 1 to consensus node x, where x is a positive integer. The consensus nodes can complete consensus and write blocks through step ⑦. Afterwards, the consensus nodes can synchronize the blocks to other nodes in the DL network, such as DLEF1 and DLEF2 mentioned above, through step ⑧.

[0269] Within the network service range provided by Operator 1, after receiving the synchronization block message, DLEF1 sends the block to IDM1 of Operator 1 via step ⑨-1, so that IDM1 can back up the block. IDM1 can determine backup information 2 based on the information in the block and the first identity information from Terminal 1, and send backup information 2 to the core network element (such as an archive node) of Operator 1 via step ⑩-1, so that the archive node can back up the block. Within the network service range provided by Operator 2, after receiving the synchronization block message, DLEF2 sends the block to IDM2 of Operator 2 via step ⑨-2, so that IDM2 can back up the block. IDM2 can determine backup information 2 based on the information in the block and the first identity information from Terminal 2, and send backup information 2 to the core network element (such as an archive node) of Operator 2 via step ⑩-2, so that the archive node can back up the block.

[0270] As can be seen in the process shown in Figure 7, DLEF1, DLEF2, and DLEF3 belong to different operators, but are devices in the same DL network. They can still complete the deployment of their respective contracted terminals in DL based on the method provided above.

[0271] Furthermore, as explained above, the first device can also be an AF, which can be, for example, an interface of a social authority structure opened by the operator to a third party. In this case, IDM1 and / or IDM2 in Figure 7 can also be replaced by an AF. The specific process is similar to the process described above in conjunction with Figure 7. For the sake of simplicity, no further details are provided here.

[0272] In another implementation, the public key credentials and / or attribute credentials of the second device do not necessarily have to be published to the DL. The second device can also save them locally for later use after obtaining the public key credentials and / or attribute credentials.

[0273] Figure 8 is a schematic flowchart of a communication method provided in another embodiment of this application, mainly describing a possible implementation of the second device obtaining a credential. The method 700 shown in Figure 8 includes steps 701 to 703. Optionally, it also includes one or more of steps 702', 704, and 402 to 407. The various steps in method 700 are described in detail below.

[0274] In step 701, the second device sends a request message #3 to the first device, which requests to obtain second identity information based on the carried first identity information. Correspondingly, the first device receives the request message #3 from the second device.

[0275] Request message #3 can be considered an example of a third request message. Request message #3 may carry first identity information, including the public key and / or attributes of the second device, to request the first device to issue credentials for the public key and / or attributes in the first identity information, thereby obtaining the second identity information. In this embodiment, the second identity information includes the public key credential and / or attribute credential of the second device. In other words, the second identity information in this embodiment includes credentials issued by the first device for the second device.

[0276] Optionally, the first identity information may also include one or more of the following: the identifier of the first identity information, the type of the second device, the verification method of the second device, the controller of the second device, the subject of the second device, etc.

[0277] For a more detailed explanation of this primary identity information, please refer to the relevant description of step 401 in method 400 above, which will not be repeated here.

[0278] In step 702, the first device obtains the second identity information based on the first identity information.

[0279] In response to request message #3, the first device can obtain second identity information based on the first identity information. For example, the first identity information includes the public key of the second device, and the first device can sign the public key of the second device using its own private key to obtain a public key credential. For example, the first identity information includes attributes of the second device, and the first device can also sign the attributes of the second device using its own private key to obtain an attribute credential. Whether the first device signs the public key or the attributes of the second device depends on the content included in the first identity information. If the first identity information includes both a public key and attributes, the first device can sign the public key and the attributes separately to obtain a public key credential and an attribute credential. Therefore, the first device can obtain the second identity information based on the first identity information.

[0280] Corresponding to the first identity information, the second identity information may optionally include one or more of the following: the identifier of the second identity information, the type of the second device, the verification method of the second device, the controller of the second device, the subject of the second device, etc.

[0281] The identifier of the second identity information may be the same as or different from the identifier of the first identity information. For example, the identifier of the second identity information may be obtained by processing the identifier of the first identity information. This application does not limit this.

[0282] Optionally, before step 702, the method further includes step 702', where the first device verifies the first identity information.

[0283] For a more detailed explanation of step 702', please refer to the relevant description of step 401' in method 400 above, which will not be repeated here.

[0284] In step 703, the first device sends a response message #3 to the second device, which carries the second identity information.

[0285] Response message #3 is an example of a third response message. After obtaining the second identity information, the first device can send response message #3 to the second device to transmit the second identity information. Thus, the second device can obtain the second identity information.

[0286] Subsequently, the second device may store the second identity information locally or publish it to the DL; this application does not limit this. It is understood that regardless of whether the second device publishes the second identity information to the DL, this second identity information can be used by a third party to authenticate the identity of the second device.

[0287] Based on the above scheme, the second device can obtain second identity information issued by the first device by sending a request message carrying the first identity information to the first device. Thus, the second device can obtain credentials that can be used for authentication. The first device is the issuer of the second identity information. Therefore, if a third party needs to authenticate the second device, it can authenticate the second identity information obtained from the second device based on the public key credentials of the first device; alternatively, the second device can publish the second identity information to the DL after obtaining it. If a third party needs to authenticate the second device, it can also retrieve the second identity information from the DL and then authenticate it based on the public key credentials of the first device. This enables the interoperability and mutual trust of the second device's digital identity information across various services.

[0288] Optionally, the method further includes step 704, in which the second device sends a request message #4 to the first device, the request message #4 being used to request that the second identity information be published to DL.

[0289] Request message #4 can be considered an example of a fourth request message. The second device can request the publication of the second identity information in DL by sending request message #4 carrying the second identity information to the first device. Unlike request message #1 described in method 400 above, since the second device has already obtained the second identity information issued by the first device from the first device in steps 701 to 703, the second device can carry the second identity information in request message #4 without having to carry the first identity information.

[0290] It is understandable that request message #4 has the same function as request message #1 in method 400 above, only the identity information it carries is different. Therefore, request message #4 and request message #1 can also be regarded as the same type of request message. When the first device receives this type of request message, it can determine that the second device requests to publish the second identity information in DL.

[0291] The subsequent process can be found in steps 402 to 407 of method 400 above, and will not be repeated here.

[0292] It should be understood that the second device does not necessarily have to perform step 704 after obtaining the second identity information, nor does the second identity information necessarily need to be published to the DL. Figure 8 is merely an example and should not constitute any limitation on this application.

[0293] Based on the preceding description in conjunction with Figures 5 to 8, the second identity information of the second device can be obtained by the second device or can be published to DL for use as identity authentication of the second device.

[0294] As mentioned earlier, the publication of the second device's digital identity in DL can be considered as the registration process of the second device in DL. With its digital identity published in DL, the second device can communicate with other devices in the DL network through its endorser. If the second device wishes to communicate directly with devices in the DL network, obtain data from DL, or directly publish data to DL, it needs to further access the DL network. The process of the second device accessing the DL network will be described in detail below with reference to the accompanying drawings.

[0295] Because DL (Digital Link) can be deployed across different carrier networks, and the digital identity of the second device is endorsed by a trusted institution within the DL network (such as a carrier or a third-party social authority), the digital identity of the second device can be verified by nodes within the DL network in different carrier networks. In other words, the process of the second device accessing the DL network is not limited by the carrier network to which the second device's current location belongs. For example, when the second device corresponds to a terminal, the terminal can access the DL network whether roaming or not.

[0296] Figure 9A is a schematic diagram of a terminal accessing the DL network in a non-roaming situation. As shown, the terminal can access the network provided by its home operator (operator 1 in the figure) based on a traditional authentication process. For example, the terminal can access the network provided by operator 1 based on a subscriber identity module (SIM) card. Operator 1's core network NF (such as the authentication service function (AUSF)) can perform identity authentication for the terminal. In addition, the terminal can obtain a digital identity (i.e., the aforementioned second identity information) through the process shown in method 400 above. After accessing the network, the terminal can send this digital identity to operator 1's core network NF (such as DLEF1) to request access to the DL network.

[0297] Figure 9B is a schematic diagram of a terminal accessing the DL network while roaming. As shown, the terminal can first access the network provided by its home operator (operator 1 in the figure) based on a traditional authentication process. For example, the terminal can access the network provided by operator 1 using a SIM card. Operator 1's core network NF (such as AUSF1) can perform identity authentication for the terminal. Then, the terminal can access the network provided by the destination operator (operator 2 in the figure) based on a traditional roaming authentication process. For example, the terminal can access the network provided by operator 2 using a SIM card. Operator 2's core network NF (such as AUSF2) sends the authentication request from the terminal to operator 1's core network NF (such as AUSF1), which performs authentication for the terminal and sends the authentication result to operator 2's core network NF after completion. Afterward, the terminal can use its digital identity to request access to the DL network from operator 2's core network NF (such as DLEF2).

[0298] In summary, whether roaming or not, the terminal can initiate the authentication process to access the DL network through the network provided by the operator in its current location. For ease of distinction and explanation, this paper refers to the authentication process for accessing the operator's network as primary authentication and the authentication process for accessing the DL network as secondary authentication. The specific process of primary authentication can be found in existing technologies and will not be detailed here. The secondary authentication process will be explained in detail below with reference to Figure 10. It should be understood that secondary authentication is performed after primary authentication is completed.

[0299] It should be understood that the process shown in Figure 10 can be based on the following scenario: The second identity information of the second device has been published to the DL, and the second device has completed the main authentication process. The process of publishing the second identity information to the DL shown in Figure 10 can be the process exemplified by method 400 above. In the main authentication process shown in Figure 10, the fifth device and the third device in method 400 above can be the same device or different devices; this application does not limit this. The third device and the fifth device are distinguished in Figure 10 only for the convenience of different processes.

[0300] Figure 10 is a schematic flowchart of a communication method 900 provided in another embodiment of this application. The method shown in Figure 10 includes steps 901 to 904. Optionally, it also includes one or more of steps 905 to 906. Optionally, it also includes the flowchart shown in Figure 11A and / or Figure 11B. The various steps in method 900 are described in detail below.

[0301] In step 901, the second device sends authentication request #1 to the fifth device, which requests authentication of the second device. Correspondingly, the fifth device receives authentication request #1 from the second device.

[0302] After completing the main authentication process, the second device can send the authentication request #1 to the fifth device in the operator network at its current location. Authentication request #1 is an example of the first authentication request. Authentication request #1 can also be called a request to access the DL, or a request to join the DL, etc., without limitation. The fifth device is a device in the DL network. Exemplarily, the fifth device can correspond to DLEF. It should be understood that DLEF in this embodiment can correspond to the third device in method 400 shown above in conjunction with Figure 5, or it can correspond to one of devices 1 to m, the aggregation node, or the consensus node shown in Figure 6, or it can be different from the third device in method 400 shown in Figure 5, or different from devices 1 to m, the aggregation node, and the consensus node in the process shown in Figure 6. This application does not limit this.

[0303] In one possible implementation, the second device can send the authentication request #1 to the AMF in the operator's network, and the AMF can forward the authentication request #1 to the fifth device.

[0304] For example, the AMF can forward the received authentication request #1 to a device in the DL network (such as the fifth device in this embodiment) according to the message type of the received authentication request #1. The message type can be, for example, a message requesting access to the DL network, or a predefined message type, which is not limited in this application.

[0305] For example, the authentication request #1 includes first information and a first signature, wherein the first information may include: an identifier of the second identity information of the second device and / or the public key credential of the second device.

[0306] The first signature can be obtained by the second device signing the first information based on its own private key.

[0307] The identifier of the second identity information can be used to identify the second device in the DL, or in other words, it can be used to identify the second identity information in the DL. This identifier of the second identity information can be used by the fifth device to retrieve the second identity information from the DL, and then obtain the public key certificate of the second device from the second identity information. The public key certificate of the second device contains the public key of the second device, which can be used by the fifth device to verify the first signature. It is not difficult to see that the first information may also exclude the identifier of the second identity information, but include the public key certificate of the second device.

[0308] Optionally, the first information may also include a random number, which may include random number 1 sent by the second device to the fifth device and / or random number 2 sent by the fifth device to the second device.

[0309] The random number 1 can be a challenge value generated by the second device and sent to the fifth device. The second device can authenticate the fifth device based on this random number 1. For details on the authentication of the fifth device by the second device, please refer to steps 904 to 906 below. Similar details will not be provided here.

[0310] Random number 2 can be a challenge value generated by the fifth device and sent to the second device, which the fifth device can use to authenticate the second device. This random number 2 can be sent by the fifth device to the second device before step 901.

[0311] Optionally, before step 901, the method further includes: the second device sending an authentication request #2 to the fifth device, the authentication request #2 being used to request the fifth device to authenticate the second device. Optionally, the authentication request #2 carries an identifier of the second identity information.

[0312] The second device can request a challenge value from the fifth device by sending authentication request #2. In response to authentication request #2, the fifth device can generate a random number 2 and return it as the challenge value to the second device. The second device can then include this random number 2 in authentication request #1 to facilitate authentication by the fifth device. It can be understood that including this random number 2 in authentication request #1 indicates that the device sending authentication request #1 and the device receiving random number 2 are the same device. In other words, random number 2 can be used to identify the message used to send it.

[0313] In step 902, the fifth device obtains the second identity information based on the authentication request #1.

[0314] Since the fifth device is a device within the DL network, it has the authority to query ledger data. In this embodiment, the fifth device can obtain the second identity information by searching the DL, based on the identifier of the second identity information.

[0315] In step 903, the fifth device authenticates the second device based on the second identity information.

[0316] The authentication of the second device by the fifth device may include the following two aspects: first, whether the identity information of the second device (i.e., the second identity information) has been published in DL; second, the validity of the second device's credentials, or in other words, whether the credentials are valid, specifically whether they are valid in the DL network.

[0317] For public key credentials, validity can include: the public key credential can be used to verify its signature. Optionally, validity also includes: the public key credential was issued by a trusted institution (such as an operator). For attribute credentials, validity can include: successful verification of the attribute. Optionally, validity also includes: the attribute credential was issued by a trusted institution (such as an operator). In other words, the validity of the second device's credential in the DL network can also be understood as the second device's credential being issued by a trusted institution, or endorsed by a trusted institution. If the fifth device can find the second identity information in the DL, it can be determined that the second identity information has been published in the DL. The second device can further authenticate itself based on the second identity information. If the fifth device cannot find the second identity information in the DL, it can be determined that the second identity information has not been published in the DL, and the fifth device's authentication of the second device fails.

[0318] In this embodiment, it is assumed that the fifth device finds the second identity information in the DL and can continue to authenticate the second device based on the second identity information. That is, it determines whether the second device is valid in the DL network. In other words, the second device can be verified in the DL network, which means that the identity information of the second device (i.e., the second identity information) is issued by a trusted institution, or in other words, the second identity information is endorsed by a trusted institution.

[0319] As previously mentioned, the third identity information of the second device published to DL may include the public key credential of the second device, or the public key credential of the second device may also be carried in the aforementioned authentication request #1. The fifth device can verify the first signature based on the public key in the public key credential. Since the first signature is obtained by signing the first information based on the private key of the second device, if the fifth device can decrypt the first signature based on the public key of the second device and obtain the hash of the first information, it indicates that the authentication of the second device is successful.

[0320] Optionally, the first information mentioned above may also include one or more of the following: the address of the session ID or second identity information in the DL.

[0321] The session identifier can be used to identify the session corresponding to authentication request #1. Since authentication request #1 is used by the second device to request access to the DL network, or in other words, to request access to the DLEF, the session corresponding to this session identifier can also be referred to as a session for accessing the DL network, or in other words, a session related to the DL network.

[0322] In one possible design, the session identifier can be the packet data unit (PDU) session identifier (PDU session ID) in the main authentication process. In another possible design, the session identifier may not be the PDU session identifier in the main authentication process. This application does not limit this.

[0323] The session identifier can change dynamically as the number of messages exchanged increases. For example, between the two communicating parties, the session identifier can be automatically incremented by one for each message sent, thereby preventing replay attacks.

[0324] Optionally, the session identifier can also be used as a challenge value. In this case, the aforementioned random number can be the session identifier. In other words, the first information also includes one or more of the following: the session identifier (i.e., an example of the random number) or the address of the second identity information in the DL.

[0325] The address of the second identity information in the blockchain (DL) can be used by the fifth device to locate the second identity information within the DL. For example, if the DL is a blockchain, the address of the second identity information in the DL could be its block ID or transaction ID within the blockchain. By indicating the address of the second identity information in the DL to the fifth device, the second device can more quickly locate the second identity information.

[0326] The following examples illustrate the different designs of authentication request #1 and the authentication process of the second device by the fifth device based on authentication request #1.

[0327] In one example, the first information in the authentication request #1 above includes an identifier and a random number for the second identity information. The first signature is obtained by signing the first information (i.e., the identifier and random number of the second identity information) using the private key of the second device. The fifth device can search for the second identity information in the DL based on the identifier of the second identity information, and then obtain the public key certificate in the second identity information. The public key certificate in the second identity information is the public key certificate of the second device. The fifth device can verify the first signature based on the public key in the public key certificate of the second device.

[0328] Furthermore, the fifth device can also obtain the issuer information of the second identity information from the second identity information. For example, the issuer of the second identity information can refer to the first device (such as IDM or an interface AF open to third-party social authorities) or the third device (such as DLEF) that issued the credentials (such as public key credentials and / or attribute credentials) for the second device mentioned above. The fifth device can obtain the issuer's public key certificate based on the issuer information, and then verify the second device's public key credential based on the public key in the issuer's public key certificate, and then verify the first signature based on the public key in the second device's public key credential. The issuer's public key certificate is pre-installed in the DL. For example, the issuer's public key certificate can be written to the DL during the DL creation phase; for example, when the DL is a blockchain, the issuer's public key certificate can be written to the genesis block during the blockchain creation phase. Therefore, devices in the DL network can obtain the issuer's public key certificate from the DL.

[0329] In another example, the first information in the aforementioned authentication request #1 includes a random number and a public key credential of the second device. The first signature is obtained by signing the first information (i.e., the random number and the public key credential) using the private key of the second device. The fifth device can verify the first signature based on the public key in the public key credential of the second device.

[0330] Furthermore, the fifth device can also obtain the issuer information of the second identity information from the second identity information. The fifth device can obtain the issuer's public key certificate based on the issuer information, and then verify the public key certificate of the second device based on the public key in the issuer's public key certificate. Then, it verifies the first signature based on the public key in the public key certificate of the second device. The method of obtaining the issuer's public key certificate can be referred to the example above, and will not be repeated here.

[0331] The examples of authentication request #1 and the authentication process of the fifth device for the second device given above are merely examples, and this application includes, but is not limited to, these examples.

[0332] In step 904, the fifth device sends authentication response #1 to the second device. Accordingly, the second device receives authentication response #1 from the fifth device.

[0333] Authentication response #1 is an example of a first authentication response. Authentication response #1 can indicate the authentication result of the fifth device on the second device. It is understood that if the fifth device successfully verifies the first signature based on the public key in the second device's public key certificate, the authentication of the second device by the fifth device is successful, indicating authentication pass or authentication success; if the fifth device fails to verify the first signature based on the public key in the second device's public key certificate, or if the fifth device fails to authenticate the second device, the authentication result can indicate authentication failure or authentication failure. In this embodiment, assuming the fifth device successfully authenticates the second device, this authentication result can indicate authentication success or authentication pass.

[0334] On the other hand, since the second device cannot determine whether the fifth device that sent authentication response #1 is legitimate in the DL network, it can also authenticate the fifth device. As mentioned earlier, the second device can request the fifth device to issue a challenge value through authentication request #2. If the fifth device successfully authenticates the second device, it can include information and a signature used by the second device to authenticate the fifth device in the authentication response #2 sent to the second device.

[0335] Optionally, the authentication response #1 includes second information and a second signature, the second information including the public key credential of the fifth device, the second information being obtained by signing the second information based on the private key of the fifth device, etc.

[0336] Optionally, the second information may also include one or more of the following: the identifier of the second identity information, the random number 1, or the session identifier.

[0337] As previously stated, authentication request #1 includes one or more of the following: an identifier of the second identity information, a random number 1, or a session identifier. One or more of the identifier of the second identity information, the random number 1, or the session identifier included in authentication response #1 may be obtained by the fifth device from authentication request #1.

[0338] In step 905, the second device verifies the public key certificate of the fifth device based on the DL certificate.

[0339] In step 906, the second device verifies the second signature based on the public key certificate of the fifth device.

[0340] As described in method 400 above, after the second identity information of the second device is published in DL, devices in the DL network (such as the second device in the example above) can send DL credentials to the first device. These DL credentials can be used to generate certificates for various devices in the DL network, and thus can be used to authenticate the identity of devices in the DL network. In this embodiment, since the fifth device is a device in the DL network, and devices in the DL network hold public key credentials issued based on DL credentials, that is, the public key credentials of the fifth device are obtained by signing the public key of the fifth device based on the DL credentials. Therefore, the second device can verify the public key credentials of the fifth device based on the previously obtained DL credentials, and if the verification passes, further verify the second signature based on the public key in the public key credentials of the fifth device. If the verification passes, it can be determined that the fifth device is legitimate or valid in the DL network; if the verification fails, it can be determined that the fifth device is illegitimate or invalid in the DL network. For ease of understanding and explanation, this embodiment assumes that the verification passes.

[0341] As previously stated, the second signature is obtained by signing the second information based on the private key of the fifth device. The second information includes the verification result and the public key certificate of the fifth device, and optionally includes one or more of the following: random number 1, the identifier of the second identity information, or the session identifier. Therefore, the second device can verify the second signature based on the public key in the public key certificate of the fifth device. Signing the second information with one or more of the following: random number 1, the identifier of the second identity information, or the session identifier, facilitates the second device in determining whether the sender of the authentication response #1 is the receiver of the authentication request #1. The inclusion of random number 1 in the authentication response #1 indicates that the device sending the authentication response #1 and the device receiving the random number 1 are the same device. In other words, random number 1 can be used to identify the aforementioned authentication request #1.

[0342] After the second device completes its authentication of the fifth device, two-way verification is completed between the second device and the fifth device.

[0343] Based on the above scheme, after the second device accesses the network, it can be authenticated by devices in the DL network without having to be authenticated through the network of the operator it has signed up with. Therefore, ubiquitous authentication can be achieved, and the authentication process is simple.

[0344] After the second device connects to the DL network, it gains the authority to query ledger data within the DL network. As a device within the DL network, it authenticates other devices or is authenticated by other devices, such as authenticating peer nodes in communication or business. For example, during terminal authentication between two terminals, the second device can correspond to one terminal, and the peer node can correspond to the other terminal communicating with it. Similarly, when a terminal connects to a World Wide Web (WWW) server, the web server authenticates the terminal; in this case, the second device can correspond to the terminal accessing the web server, and the peer node can correspond to the web server.

[0345] The authentication process of the second device to other devices and the authentication process of other devices to the second device are described below with reference to Figures 11A and 11B, respectively.

[0346] Figure 11A is a schematic diagram of the second device authenticating the sixth device. The sixth device shown in Figure 11A is an example of other devices. The identity information of the sixth device has been published in the DL. For example, the sixth device can also publish its identity information in the DL through the process described above in conjunction with method 400 shown in Figure 5. Therefore, devices in the DL network can find the identity information of the sixth device from the DL.

[0347] In step 1001, the sixth device sends authentication request #3 to the second device, and the second device receives authentication request #3 from the sixth device.

[0348] The authentication request #3 is an example of a second authentication request, such as a service request, a connection establishment request, etc., without limitation. Exemplarily, the authentication request #3 may include third information and a third signature. The third signature is obtained by signing the third information based on the private key of the sixth device. The third information includes the public key credential and / or attribute credential of the sixth device, which can be used by the second device to authenticate it. Optionally, the third information includes an identifier of the sixth device's identity information, which can be used to identify the identity information of the sixth device published to the DL, or in other words, to identify the sixth device in the DL's network.

[0349] In step 1002, the second device obtains the identity information of the sixth device.

[0350] Since the second device has already accessed the DL network through steps 901 to 906 in the above method 900, in other words, the second device is a device in the DL network, and therefore has the authority to search for ledger data in the DL. Therefore, the second device can respond to the received authentication request #3 and search for the identity information of the sixth device in the DL in order to authenticate the sixth device.

[0351] For example, the second device can obtain the identity information of the sixth device from the eighth device in the DL network. For instance, the second device can send an identifier of the sixth device's identity information to the eighth device to request the sixth device's identity information. The eighth device can then use this identifier to search for the sixth device's identity information in the DL and send it to the second device.

[0352] In step 1003, the second device authenticates the sixth device based on the identity information of the sixth device.

[0353] The authentication of the sixth device by the second device may include the following two aspects: first, whether the identity information of the sixth device has been published in DL; and second, the validity of the sixth device's credentials, or in other words, whether the sixth device's credentials are valid in DL's network.

[0354] Whether the identity information of the sixth device has been published to the DL can be determined by whether the identity information of the sixth device can be found in the DL. In this embodiment, if the second device receives the identity information of the sixth device from the eighth device, it means that the identity information of the sixth device can be found in the DL, and the second device can continue to verify the legitimacy of the sixth device in the DL network; if the second device does not receive the identity information of the sixth device from the eighth device, it means that the identity information of the sixth device cannot be found in the DL, and thus authentication failure can be determined.

[0355] It should be understood that the eighth device is a device in the DL network. For example, it can be the same device as the fifth device shown in Figure 10 above, or it can be a different device. This application does not limit this.

[0356] The credentials for the sixth device are valid within the DL network; that is, the credentials for the sixth device are issued by a trusted authority, or in other words, endorsed by a trusted authority. For an understanding of the validity of the sixth device's credentials within the DL network, please refer to the relevant explanation of the validity of the second device's credentials in step 903 above, which will not be repeated here.

[0357] The second device can use the issuer's public key to verify the sixth device's public key certificate and / or attribute certificate. If the verification is successful, it can further verify the third signature based on the public key in the sixth device's public key certificate. If the verification is successful, it can be determined that the authentication of the sixth device is successful; if the verification fails, it can be determined that the authentication of the sixth device is unsuccessful.

[0358] In step 1004, the second device sends authentication response #2 to the sixth device. Accordingly, the sixth device receives authentication response #2 from the second device.

[0359] Authentication response #2 is an example of a second authentication response, which may carry the authentication result of the second device to the sixth device. It can be understood that if the second device successfully verifies the third signature based on the sixth device's public key, the second device's authentication of the sixth device is successful, and the authentication result can indicate successful authentication. If the second device fails to verify the third signature based on the sixth device's public key, or fails to verify the sixth device's public key credential or attribute credential based on the issuer's public key, or fails to obtain the sixth device's identity information, the second device's authentication of the sixth device fails, and the authentication result can indicate failed authentication.

[0360] Based on steps 1001 to 1004 above, the second device can complete the authentication of the sixth device.

[0361] Figure 11B is a schematic diagram of the seventh device authenticating the second device. The seventh device shown in Figure 11B is an example of other devices. This seventh device is already connected to the DL network, so it can look up the identity information of the second device (i.e., the second identity information mentioned above) from devices in the DL network (such as the ninth device).

[0362] In step 1101, the second device sends authentication request #4 to the seventh device, and the seventh device receives authentication request #4 from the second device.

[0363] Authentication request #4 is an example of a third authentication request, such as a service request, a connection establishment request, etc., without limitation. Exemplarily, authentication request #4 includes fourth information and a fourth signature, the fourth signature being obtained by signing the fourth information based on the private key of the second device. The fourth information may include the public key credential and / or attribute credential of the second device. The public key credential and / or attribute credential of the second device can be used by the seventh device to verify the second device. Optionally, the fourth information also includes an identifier of the second identity information, which can be used to identify the second identity information published in the DL, or in other words, to identify the second device in the DL's network.

[0364] In step 1102, the seventh device acquires the second identity information.

[0365] Since the seventh device is a device already connected to the DL network and has the authority to search for ledger data in the DL, the seventh device can respond to the received authentication request #4 and search for the second identity information from the DL in order to authenticate the second device.

[0366] For example, the seventh device can obtain the identity information of the sixth device from the ninth device. For instance, the seventh device can send an identifier of the second identity information to the ninth device to request that the second identity information be obtained. The ninth device can then search for the second identity information in the DL based on the identifier of the second identity information and send it to the second device.

[0367] In step 1103, the seventh device authenticates the second identity information based on the second identity information.

[0368] The authentication of the second device by the seventh device may include the following two aspects: first, whether the second identity information has been published in DL; and second, the validity of the second device's credentials, or in other words, whether the second device's credentials are valid in DL's network.

[0369] Whether the second identity information has been published to the DL can be determined by whether the second identity information can be found in the DL. In this embodiment, if the seventh device receives the second identity information from the ninth device, it means that the second identity information can be found in the DL, and the seventh device can continue to verify the legitimacy of the second device in the DL network; if the seventh device does not receive the second identity information from the ninth device, it means that the second identity information cannot be found in the DL, and thus authentication failure can be determined.

[0370] It should be understood that the ninth device is a device in the DL network. For example, it can be the same device as the fifth device shown in Figure 10 above or the eighth device in Figure 11A, or it can be a different device. This application does not limit this.

[0371] The credentials for the second device are valid within the DL network, meaning that the credentials for the second device were issued by a trusted authority, or in other words, endorsed by a trusted authority. For an understanding of the validity of the credentials for the second device within the DL network, please refer to the relevant explanation of the validity of the credentials for the second device in step 903 above, which will not be repeated here.

[0372] The seventh device can use the issuer's public key to verify the public key certificate and / or attribute certificate of the second device. If the verification is successful, it can further verify the fourth signature based on the public key in the public key certificate of the second device. If the verification is successful, it can be determined that the authentication of the second device is successful; if the verification fails, it can be determined that the authentication of the second device is unsuccessful.

[0373] In step 1104, the seventh device sends authentication response #3 to the second device. Accordingly, the second device receives authentication response #3 from the seventh device.

[0374] Authentication response #3 is an example of a third authentication response, which can indicate the authentication result of the seventh device on the second device. It can be understood that if the seventh device successfully verifies the fourth signature based on the second device's public key, the seventh device's authentication of the second device is successful, and the authentication result can indicate successful authentication. If the seventh device fails to verify the fourth signature based on the second device's public key, or fails to verify the second device's public key credential or attribute credential based on the issuer's public key, or fails to obtain the second identity information, the seventh device's authentication of the second device fails, and the authentication result can indicate failed authentication.

[0375] Based on steps 1101 to 1104 above, the seventh device can complete the authentication of the second device.

[0376] It should be understood that Figures 11A and 11B are provided for ease of understanding only, illustrating the possible processes that a second device might execute after accessing the DL network from the perspectives of the second device authenticating other devices (such as the sixth device) and the second device being accessed by other devices (such as the seventh device). These examples are given for ease of understanding only and do not imply that the second device must execute the processes described in Figures 11A or 11B after accessing the DL network based on the method 900 shown in Figure 10.

[0377] Based on the above scheme, after the second device accesses the DL network, it can also authenticate peer nodes in communication or services, and can also be authenticated by peer nodes in communication or services. Since the identity information of devices published in the DL is stored in the DL, devices accessing the DL network (such as the second device) do not need to pre-configure the issuer information of other nodes' credentials locally. They can obtain the identity information of the authenticated party simply by searching in the DL, and then authenticate it.

[0378] It should be understood that in the various embodiments shown above in conjunction with the accompanying drawings, the sequence number of each step does not imply the order of execution. The execution order of each step should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0379] It should also be understood that, in the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0380] The communication method provided in the embodiments of this application has been described in detail above with reference to Figures 5 to 11B. The apparatus provided in the embodiments of this application will now be described with reference to the accompanying drawings.

[0381] As an example, FIG12 is a schematic block diagram of a communication device 1200 provided in an embodiment of the present application. As shown in FIG12, the communication device 1200 includes a transceiver unit 1210 and a processing unit 1220.

[0382] One possible design is that the communication device 1200 can be used to implement the function of the first device in the method embodiment shown in FIG5 or FIG8 above.

[0383] For example, the processing unit 1220 can be used to obtain first identity information of the second device, which includes the public key and / or attributes of the second device; the transceiver unit 1210 can be used to send a first request message to a third device, which requests the publication of second identity information in DL, which is obtained based on the first identity information and includes one or more of the following: the public key of the second device, the public key credential of the second device, attributes, hashes of attributes, attribute credentials, or hashes of attribute credentials; wherein, the public key of the second device is used to verify signatures from the second device, the public key credential of the second device is obtained by signing the public key of the second device with the private key of the first device, the attribute credential is obtained by signing the attribute with the private key of the first device, and the third device is a device in the DL network; the transceiver unit 1210 can also be used to receive a first response message from the third device, which indicates the publication result of the second identity information in DL.

[0384] Optionally, the processing unit 1220 is also used to verify the first identity information.

[0385] Optionally, the processing unit 1220 is also configured to generate second identity information based on the first identity information.

[0386] Optionally, the transceiver unit 1210 is further configured to obtain one or more of the following from the third device: the address of the second identity information in the DL, or the credential of the DL, which is used to verify the identity of the device in the DL's network.

[0387] Optionally, the transceiver unit 1210 is also configured to send one or more of the following to the second device: the identifier of the second identity information, the address of the second identity information in the DL, or the credential of the DL.

[0388] Optionally, the transceiver unit 1210 is further configured to send one or more of the following to the fourth device: a correspondence between an attribute and the hash of an attribute published in the DL; a correspondence between an attribute credential and the hash of an attribute credential published in the DL; or, a correspondence between the identifier of the second identity information and the identifier of the second device, wherein the identifier of the second device is used to identify the second device within the network service scope provided by the operator.

[0389] A more detailed description of the transceiver unit 1210 and the processing unit 1220 can be obtained directly from the relevant description of the first device in the method embodiment shown in Figure 5 or Figure 8, and will not be repeated here.

[0390] Another possible design is that the communication device 1200 can be used to implement the function of the third device in the method embodiment shown in FIG5 or FIG8 above.

[0391] For example, the transceiver unit 1210 can be used to receive a first request message from the first device, the first request message carrying second identity information of the second device, the second identity information being obtained by the first device based on the first identity information of the second device; the transceiver unit 1210 is also used to send a first response message to the first device, the first response message being used to indicate the publication result of the second identity information in DL.

[0392] Optionally, the first request message also carries a second identity information signature, which is obtained by signing the second identity information based on the private key of the first device; the processing unit 1220 is also used to verify the second identity information signature based on the public key certificate of the first device.

[0393] Optionally, the publication of the second identity information in the DL includes: publishing the second identity information in a block on the blockchain, the block being generated based on a transaction; the processing unit 1220 is further configured to invoke a smart contract to obtain a transaction, the transaction including: the initiator of the transaction, the recipient of the transaction, the transaction content, and the transaction signature; wherein, the initiator of the transaction indicates the issuer of the second identity information, or the party to which the issuer of the second identity information belongs; the recipient of the transaction indicates the smart contract; the transaction content is generated based on the second identity information, or the transaction content is generated based on the second identity information and the signature of the second identity information, and the transaction signature is obtained by signing the transaction content with the private key of a third device.

[0394] Optionally, the transceiver unit 1210 is further configured to send one or more of the following to the second device: the address of the second identity information in the DL, and the DL's credentials, which are used to verify the identity of the device in the DL's network.

[0395] A more detailed description of the transceiver unit 1210 and the processing unit 1220 can be obtained directly from the relevant description of the third device in the method embodiment shown in Figure 5 or Figure 8, and will not be repeated here.

[0396] Another possible design is that the communication device 1200 can be used to implement the function of the second device in the method embodiment shown in FIG5 or FIG8 above.

[0397] For example, the transceiver unit 1210 can be used to send a second request message, which is used to request the publication of second identity information in DL. The second request message carries first identity information, which includes the public key and / or attributes of the second device. The first identity information is used to obtain the second identity information. The transceiver unit 1210 can also be used to receive a second response message, which is used to indicate the publication result of the second identity information in DL.

[0398] A more detailed description of the transceiver unit 1210 and the processing unit 1220 can be obtained directly from the relevant description of the third device in the method embodiment shown in Figure 5 or Figure 8, and will not be repeated here.

[0399] Another possible design is that the communication device 1200 can be used to implement the function of the second device in the method embodiments shown in FIG10, FIG11A or FIG11B.

[0400] For example, the transceiver unit 1210 can be used to send a first authentication request to a fifth device. The first authentication request is used to request authentication of the second identity information of device 1200. The first authentication request includes first information and a first signature. The first information includes an identifier of the second identity information of device 1200. The identifier of the second identity information of device 1200 is used to identify the second identity information of device 1200 published in DL. The first signature is obtained by signing the first information based on the private key of device 1200. The fifth device is a device in the network of DL. The transceiver unit 1210 can also be used to receive a first authentication response from the fifth device. The first authentication response carries the authentication result of device 1200.

[0401] Optionally, the first authentication response includes second information and a second signature. The second information includes the authentication result and the public key credential of the fifth device. The second signature is obtained by signing the second information based on the private key of the fifth device. The public key credential of the fifth device is used to verify the second signature. The processing unit 1220 is specifically used to: verify the public key credential of the fifth device based on the DL credential; and verify the second signature based on the public key credential of the fifth device.

[0402] Optionally, the transceiver unit 1210 is further configured to receive a second authentication request from a sixth device, which is a device in the DL network. The second authentication request carries an identifier of the identity information of the sixth device, which is used to identify the identity information of the sixth device published in the DL. The processing unit 1220 is further configured to obtain the identity information of the sixth device from the fifth device according to the second authentication request, and to authenticate the sixth device according to the identity information of the sixth device.

[0403] Optionally, the processing unit 1220 is also used to trigger the process of sending the second identity information to the DL.

[0404] Optionally, the transceiver unit 1210 is specifically configured to send a second request message to the first device, the second request message being used to request the publication of second identity information in the DL. The second request message carries first identity information, which includes the public key and / or attributes of device 1200. The first identity information is used to obtain the second identity information, which includes one or more of the following: the public key of device 1200, the public key certificate of device 1200, an attribute, a hash of the attribute, an attribute certificate, or a hash of the attribute certificate. The public key of device 1200 is used to verify a signature from device 1200, the public key certificate of device 1200 is obtained by signing the public key of device 1200 with the private key of the first device, and the attribute certificate is obtained by signing the attribute with the private key of the first device. The transceiver unit 1210 is also configured to receive a second response message from the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

[0405] A more detailed description of the transceiver unit 1210 and the processing unit 1220 can be obtained directly from the relevant description of the second device in the method embodiments shown in FIG10, FIG11A or FIG11B, and will not be repeated here.

[0406] Another possible design is that the communication device 1200 can be used to implement the function of the fifth device in the method embodiment shown in FIG10 above.

[0407] For example, the transceiver unit 1210 can be used to receive a first authentication request, which includes first information and a first signature. The first information includes an identifier of the second identity information of the device 1200, which is used to identify the second identity information of the device 1200 published in the DL. The first signature is obtained by signing the first information based on the private key of the device 1200. The processing unit 1220 can be used to obtain the second identity information according to the first authentication request. The processing unit 1220 can also be used to authenticate the second device based on the second identity information. The transceiver unit 1210 can also be used to send a first authentication response, which carries the authentication result of the second device.

[0408] Optionally, the processing unit 1220 may be used to: determine the issuer of the second identity information based on the second identity information; verify the public key certificate in the second identity information based on the issuer's public key certificate; and verify the first signature based on the public key certificate in the second identity information.

[0409] A more detailed description of the transceiver unit 1210 and the processing unit 1220 can be obtained directly from the relevant description of the fifth device in the method embodiment shown in FIG10, and will not be repeated here.

[0410] It should be noted that the transceiver unit can also be called a transceiver module, transceiver, transceiver machine, or transceiver device, etc. The processing unit can also be called a processor, processing board, processing module, or processing device, etc. Optionally, the transceiver unit is used to execute the sending and receiving operations of the devices in the above methods. The device in the communication module that implements the receiving function can be considered as the receiving unit, and the device in the communication module that implements the sending function can be considered as the sending unit; that is, the transceiver unit includes both a receiving unit and a sending unit.

[0411] It should also be noted that, in one possible design, the aforementioned transceiver unit and / or processing unit can be implemented through virtual modules. For example, the processing unit can be implemented through software functional units or virtual devices, and the transceiver unit can be implemented through software functions or virtual devices. In another possible design, the processing unit or transceiver unit can also be implemented through physical devices. For example, if the device is implemented using a chip / chip circuit, the transceiver unit can be an input / output circuit and / or a communication interface, performing input operations (corresponding to the aforementioned receiving operation) and output operations (corresponding to the aforementioned sending operation); the processing unit is an integrated processor, microprocessor, or integrated circuit.

[0412] The unit division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used. Furthermore, the functional modules in the various examples of this embodiment can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules can be implemented in hardware or as software functional modules.

[0413] As an example, another communication device provided in this application is shown in FIG13. The communication device 1300 includes at least one processor 1310. The at least one processor 1310 can be used to execute computer programs or instructions in memory to implement the steps performed by the second device in the embodiments shown in FIG5, FIG8, FIG10, FIG11A or FIG11B, or to implement the steps performed by the first device in the embodiments shown in FIG5 or FIG8, or the steps performed by the third device in the embodiment shown in FIG5, or the steps performed by the fourth device in the embodiment shown in FIG5, or the steps performed by the fifth device in the embodiment shown in FIG10.

[0414] Optionally, the communication device 1300 may further include at least one memory 1320 for storing instructions executed by the processor 1310, or storing input data required by the processor 1310 to execute instructions, or storing data generated after the processor 1310 executes instructions. The at least one processor 1310 and the at least one memory 1320 may be configured separately. For example, each memory may be connected to one or more processors, enabling the connected processors to read information from, store, and / or write information to the memory. Alternatively, the at least one processor 1310 and the at least one memory 1320 may be integrated together; for example, one or more memories may be integrated into a single processor.

[0415] Optionally, the communication device 1310 further includes an interface circuit 1330 for transmitting data and / or signaling. The at least one processor 1310 and the interface circuit 1330 are coupled to each other. It is understood that the interface circuit 1330 can be a transceiver, input / output circuit, bus, module, pin, or other type of communication interface, wherein the input circuit in the input / output circuit can be used for receiving, and the output interface can be used for transmitting.

[0416] When the communication device 1300 is used to implement the methods shown in Figures 5, 8, 10, 11A, and 11B, the processor 1310 performs the functions of the aforementioned processing unit, and the interface circuit 1330 performs the functions of the aforementioned transceiver unit. Whether the interface circuit 1330 is used for transmitting or receiving depends on whether the communication device 1300 is performing a transmitting or receiving action in the chosen scheme.

[0417] It is understood that when the communication device 1300 is a communication equipment, the interface circuit 1330 can be a transceiver, specifically including a transmitter and a receiver. The transmitter is used to send signals, and the receiver is used to receive signals. When the communication device 1300 is a chip used in a communication equipment, the interface circuit 1330 can be an input / output circuit, a bus, a module, a pin, or other types of communication interface. The input circuit in the input / output circuit can be used for receiving, and the output interface can be used for sending.

[0418] It should be understood that in the communication device 1300 shown in FIG13, the processor 1310 may correspond to the processing unit 1220 in the aforementioned communication device 1200, and the interface circuit 1330 may correspond to the transceiver unit 1210 in the aforementioned communication device 1200.

[0419] It should also be understood that the coupling in the embodiments of this application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information interaction between devices, units, or modules. The embodiments of this application do not limit the specific connection medium between the at least one processor 1310, at least one memory 1320, interface circuit 1330, and power supply circuit 1340. In Figure 13, the embodiments of this application show the processor 1310, memory 1320, interface circuit 1330, and power supply circuit 1340 connected via a bus 1350. The bus 1350 is represented by a thick line in Figure 13. The connection methods between other components are only illustrative and not intended to be limiting. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 13, but this does not indicate that there is only one bus or one type of bus.

[0420] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0421] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0422] This application also provides a communication system, which includes a first device and a third device. Optionally, it also includes a second device. Optionally, it also includes a fourth device.

[0423] This application also provides a communication system including a second device and a fifth device. Optionally, it also includes a sixth device.

[0424] This application also provides a computer program product comprising: a computer program (also referred to as code or instructions), which, when run, causes a computer to execute the method executed by the second device in the embodiments shown in FIG5, FIG8, FIG10, FIG11A or FIG11B, or to execute the method executed by the first device in the embodiments shown in FIG5 or FIG8, or the method executed by the third device in the embodiment shown in FIG5, or the method executed by the fourth device in the embodiment shown in FIG5, or the method executed by the fifth device in the embodiment shown in FIG10.

[0425] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the second device in the embodiments shown in FIG. 5, FIG. 8, FIG. 10, FIG. 11A or FIG. 11B, or to perform the method executed by the first device in the embodiments shown in FIG. 5 or FIG. 8, or the method executed by the third device in the embodiment shown in FIG. 5, or the method executed by the fourth device in the embodiment shown in FIG. 5, or the method executed by the fifth device in the embodiment shown in FIG. 10.

[0426] The terms “unit”, “module”, etc., used in this specification may be used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0427] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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.

[0428] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0429] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0430] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0431] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0432] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. This computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are 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, the 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 such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0433] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0434] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method, characterized in that, Applied to a first device, the method includes: Obtain first identity information of the second device, wherein the first identity information includes the public key and / or attributes of the second device; A first request message is sent to a third device. The first request message is used to request the publication of second identity information in the distributed ledger (DL). The second identity information is obtained based on the first identity information and includes one or more of the following: the public key of the second device, the public key certificate of the second device, the attribute, the hash of the attribute, the attribute certificate, or the hash of the attribute certificate; wherein, the public key of the second device is used to verify the signature from the second device, the public key certificate of the second device is obtained by signing the public key of the second device based on the private key of the first device, the attribute certificate is obtained by signing the attribute based on the private key of the first device, and the third device is a device in the DL network. A first response message is received from the third device, the first response message being used to indicate the publication result of the second identity information in the DL.

2. The method as described in claim 1, characterized in that, Before sending the first request message to the third device, the method further includes: The first identity information has been successfully verified.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: Based on the first identity information, the second identity information is generated.

4. The method according to any one of claims 1 to 3, characterized in that, The first request message also carries a second identity information signature, which is obtained by signing the second identity information based on the private key of the first device.

5. The method according to any one of claims 1 to 4, characterized in that, After sending the first request message to the third device, the method further includes: The third device obtains one or more of the following: the address of the second identity information in the DL, or the credential of the DL, the credential of the DL being used to authenticate the identity of the device in the DL's network.

6. The method as described in claim 5, characterized in that, The method further includes: Send one or more of the following to the second device: the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Send one or more of the following to the fourth device: The correspondence between the attribute and the hash of the attribute published in the DL; The correspondence between the attribute credentials and the hashes of the attribute credentials published in the DL; or The correspondence between the identifier of the second identity information and the identifier of the second device, wherein the identifier of the second device is used to identify the second device within the network service scope provided by the operator.

8. A communication method, characterized in that, Applied to a third device, the method includes: A first request message is received from a first device, the first request message carrying second identity information of a second device, the second identity information including one or more of the following: the public key of the second device, the public key certificate of the second device, the attribute, the hash of the attribute, the attribute certificate, or the hash of the attribute certificate; wherein, the public key of the second device is used to verify the signature from the second device, the public key certificate of the second device is obtained by signing the public key of the second device based on the private key of the first device, and the attribute certificate is obtained by signing the attribute based on the private key of the first device; A first response message is sent to the first device, the first response message being used to indicate the publication result of the second identity information in the distributed ledger DL.

9. The method as described in claim 8, characterized in that, The first request message also carries a second identity information signature, which is obtained by signing the second identity information based on the private key of the first device; The method further includes: The signature of the second identity information is verified based on the public key certificate of the first device.

10. The method as described in claim 8 or 9, characterized in that, The DL is a blockchain, and the publication of the second identity information in the DL includes: Based on the second identity information, a transaction is obtained; Based on the aforementioned transaction, a block is obtained; This triggers consensus for the block within the blockchain network.

11. The method as described in claim 10, characterized in that, The transaction includes: the initiator of the transaction, the recipient of the transaction, the transaction content, and the transaction signature; wherein, the initiator of the transaction indicates the issuer of the second identity information or the party to which the issuer of the second identity information belongs, the recipient of the transaction indicates the smart contract, the transaction content is generated based on the second identity information, or the transaction content is generated based on the second identity information and the signature of the second identity information, and the transaction signature is obtained by signing the transaction content based on the private key of the third device.

12. The method according to any one of claims 8 to 11, characterized in that, The method further includes: Send one or more of the following to the second device: the address of the second identity information in the DL, or the credentials of the DL, the credentials of the DL being used to verify the identity of the device in the DL's network.

13. A communication method, characterized in that, include: Send a second request message to the first device, the second request message carrying first identity information, the first identity information including the public key and / or attributes of the second device; The first identity information is used to obtain the second identity information, and the second request message is used to request the publication of the second identity information in the distributed ledger DL; Receive a second response message, which indicates the publication result of the second identity information in the DL.

14. The method as described in claim 13, characterized in that, The second response message carries one or more of the following: the second identity information, the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL, wherein the credentials of the DL are used to verify the identity of the device in the DL's network.

15. A communication method, characterized in that, Applied to a second device, the method includes: A first authentication request is sent to the fifth device. The first authentication request is used to request authentication of the second identity information of the second device. The first authentication request includes first information and a first signature. The first information includes the identifier of the second identity information of the second device and / or the public key credential of the second device. The identifier of the second identity information of the second device is used to identify the second identity information of the second device published in the distributed ledger DL. The public key credential of the second device is used to verify the signature from the second device. The first signature is obtained by signing the first information based on the private key of the second device. The fifth device is a device in the network of the DL. Receive a first authentication response from the fifth device, the first authentication response indicating the authentication result for the second device.

16. The method as described in claim 15, characterized in that, The first information also includes one or more of the following: a random number, a session identifier, or the address of the second identity information in the DL, wherein the session identifier is used to identify the session corresponding to the first authentication request.

17. The method as described in claim 15 or 16, characterized in that, The first authentication response includes second information and a second signature. The second information includes the public key credential of the fifth device, and the second signature is obtained by signing the second information based on the private key of the fifth device. The method further includes: The second signature is verified based on the public key credentials of the fifth device.

18. The method as described in claim 17, characterized in that, The method further includes: Based on the credentials of the DL, verify the public key credentials of the fifth device.

19. The method as described in claim 17 or 18, characterized in that, The method further includes: Receive a second authentication request from a sixth device, which is a device in the network of the DL. The second authentication request carries an identifier of the identity information of the sixth device, which is used to identify the identity information of the sixth device published to the DL. Based on the second authentication request, obtain the identity information of the sixth device; The sixth device is authenticated based on its identity information; A second authentication response is sent to the sixth device, the second authentication response being used to indicate the authentication result of the sixth device by the second device.

20. The method as described in claim 17 or 18, characterized in that, The method further includes: Send a third authentication request to a seventh device, which is a device in the DL network, the third authentication request including the public key credentials and / or attribute credentials of the second device; A third authentication response is received from the seventh device, the third authentication response being used to indicate the authentication result of the seventh device for the second device.

21. The method according to any one of claims 15 to 20, characterized in that, Before sending the first authentication request to the fifth device, the method further includes: This triggers the process of publishing the second identity information to the DL.

22. The method as described in claim 21, characterized in that, The process of triggering the publication of the second identity information to the DL includes: A second request message is sent to the first device. The second request message is used to request the publication of the second identity information in DL. The second request message carries first identity information, which includes the public key and / or attributes of the second device. The first identity information is used to obtain the second identity information. The second identity information includes one or more of the following: the public key of the second device, the public key certificate of the second device, the attribute, the hash of the attribute, the attribute certificate, or the hash of the attribute certificate. The public key of the second device is used to verify the signature from the second device. The public key certificate of the second device is obtained by signing the public key of the second device with the private key of the first device. The attribute certificate is obtained by signing the attribute with the private key of the first device. The method further includes: A second response message is received from the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

23. The method as described in claim 22, characterized in that, The second response message carries one or more of the following: the second identity information, the identifier of the second identity information, the address of the second identity information in the DL, or the credentials of the DL, wherein the credentials of the DL are used to verify the identity of the device in the DL's network.

24. A communication method, characterized in that, Applied to a fifth device, the method includes: The system receives a first authentication request, which includes first information and a first signature. The first information includes: an identifier of the second identity information of the second device and / or a public key credential of the second device. The identifier of the second identity information of the second device is used to identify the second identity information of the second device published to the distributed ledger DL. The public key credential of the second device is used to verify the signature from the second device. The first signature is obtained by signing the first information based on the private key of the second device. The fifth device is a device in the network of the DL. Based on the first authentication request, the second identity information is obtained; The second device is authenticated based on the second identity information; Send a first authentication response, which indicates the authentication result of the second device.

25. The method as described in claim 24, characterized in that, The first information also includes one or more of the following: a random number, a session identifier, or the address of the second identity information in the DL, wherein the session identifier is used to identify the session corresponding to the authentication request.

26. The method as described in claim 24 or 25, characterized in that, The authentication of the second device based on the second identity information includes: Based on the public key credentials of the issuer of the second identity information, verify the public key credentials of the second device in the second identity information; The first signature is verified based on the public key credentials of the second device.

27. The method according to any one of claims 24 to 26, characterized in that, The first authentication response includes second information and a second signature. The second information includes the public key credential of the fifth device. The second signature is obtained by signing the second information based on the private key of the fifth device. The public key credential is used to verify the second signature.

28. A communication method, characterized in that, Applied to a second device, the method includes: Send a third request message to the first device, the third request message being used to request to obtain second identity information based on the first identity information carried, the first identity information including the public key and / or attributes of the second device; The system receives second identity information from the first device. The second identity information includes a public key certificate and / or an attribute certificate of the second device. The public key certificate is obtained by signing the public key of the second device with the private key of the first device, and the attribute certificate is obtained by signing the public key of the second device with the private key of the first device.

29. The method as described in claim 28, characterized in that, The method further includes: Send a fourth request message to the first device, the fourth request message carrying the second identity information, the fourth request message being used to request the publication of the second identity information in DL; A second response message is received from the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

30. A communication method, characterized in that, Applied to a first device, the method includes: Receive a third request message from the second device, the third request message being used to request to obtain second identity information based on carried first identity information, the first identity information including the public key and / or attributes of the second device; Based on the first identity information, the second identity information is obtained, which includes the public key certificate and / or attribute certificate of the second device. The public key certificate is obtained by signing the public key of the second device with the private key of the first device, and the attribute certificate is obtained by signing the public key of the second device with the private key of the first device. The second identity information is then sent to the second device.

31. The method as described in claim 30, characterized in that, The method further includes: Receive a fourth request message from the second device, the fourth request message carrying the second identity information, the fourth request message being used to request the publication of the second identity information in DL; A second response message is sent to the first device, the second response message being used to indicate the publication result of the second identity information in the DL.

32. A communication device, characterized in that, It includes one or more functional units or modules for performing the method as described in any one of claims 1 to 7, or for performing the method as described in any one of claims 8 to 12, or for performing the method as described in claims 13 or 14, or for performing the method as described in any one of claims 15 to 23, or for performing the method as described in any one of claims 24 to 27, or for performing the method as described in claims 28 or 29, or for performing the method as described in claims 30 or 31.

33. A communication device, characterized in that, The device includes a processor configured to execute program code such that the communication device implements the method as claimed in any one of claims 1 to 7, or implements the method as claimed in any one of claims 8 to 12, or implements the method as claimed in claims 13 or 14, or implements the method as claimed in any one of claims 15 to 23, or implements the method as claimed in any one of claims 24 to 27, or is configured to perform the method as claimed in claims 28 or 29, or is configured to perform the method as claimed in claims 30 or 31.

34. A communication system, characterized in that, include: A first device and a third device, the first device being configured to perform the method as described in any one of claims 1 to 7, and the third device being configured to perform the method as described in any one of claims 8 to 12.

35. The system as described in claim 34, characterized in that, The system further includes a second device for performing the method as described in claim 13 or 14.

36. A communication system, characterized in that, It includes a second device and a fifth device, the second device being used to perform the method as described in any one of claims 15 to 23, and the fifth device being used to perform the method as described in any one of claims 24 to 27.

37. A communication system, characterized in that, It includes a first device and a second device, the second device being used to perform the method as described in claim 28 or 29, and the first device being used to perform the method as described in claim 30 or 31.

38. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the method as described in any one of claims 1 to 7 to be executed, or causes the method as described in any one of claims 8 to 12 to be executed, or causes the method as described in claims 13 or 14 to be executed, or causes the method as described in any one of claims 15 to 23 to be executed, or causes the method as described in any one of claims 24 to 27 to be executed, or causes the method as described in claims 28 or 29 to be executed, or causes the method as described in claims 30 or 31 to be executed.

39. A computer program product, characterized in that, The method includes a computer program that, when executed, causes the method as described in any one of claims 1 to 7 to be performed, or causes the method as described in any one of claims 8 to 12 to be performed, or causes the method as described in claim 13 or 14 to be performed, or causes the method as described in any one of claims 15 to 23 to be performed, or causes the method as described in any one of claims 24 to 27 to be performed, or causes the method as described in claim 28 or 29 to be performed, or causes the method as described in claim 30 or 31 to be performed.

Images