Communication method, apparatus, and system

Abstract

The present application provides a communication method, a communication apparatus, and a system. When a first apparatus needs to operate across DLs, for example, when the first apparatus needs to join a network of a first DL from a network of a second DL, at least one parameter used for generating a first digital identity can be sent out so as to trigger issuance of the first digital identity, and the at least one parameter is obtained on the basis of a second digital identity that has been issued in the second DL. In this way, the issued second digital identity is used to generate the first digital identity to be issued, so as to implement cross-ledger authentication, which is convenient and efficient. Moreover, in the process, no real identity or other privacy information of the first apparatus is required, thereby achieving high security.

Description

Communication methods, devices and systems

[0001] This application claims priority to Chinese Patent Application No. 202510124091.8, filed with the State Intellectual Property Office of China on January 24, 2025, 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] Distributed ledgers (DL) are highly likely to be deployed in telecommunications networks in the future. When users sign up with an operator, they receive a digital identity, which the operator can store on the DL. Subsequently, if a user needs to access another operator's network, as long as the new operator and the user's original operator are on the same DL network, the user's digital identity can be verified, which is extremely convenient.

[0004] However, if a user connects to a different DL (Digital Link Provider) network than their original DL, the new DL will be unable to verify the user's digital identity. For example, if a user was originally in location A, and the DL of the telecommunications network in location A stored the user's digital identity, when the user moves to location B, nodes in the DL network of the telecommunications network in location B will no longer be able to use that identity. Summary of the Invention

[0005] This application provides a communication method and a communication device to realize cross-ledger authentication digital identity between different DL networks, so that the authentication of nodes in the DL network is no longer limited to the same DL network.

[0006] Firstly, a communication method is provided, which can be executed by a first device. The first device may be a terminal, a radio access network (RAN) node, or a core network function (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.

[0007] The method includes: sending a first request message carrying at least one parameter for publishing a first digital identity of a first device in a first distributed ledger (DL), wherein some or all of the at least one parameter is obtained based on a second digital identity of the first device already published in a second DL; and receiving a first response message indicating the result of the publication of the first digital identity in the first DL.

[0008] Based on the above scheme, when the first device needs to join the network of the first DL, it can send out at least one parameter used to generate the first digital identity to trigger the publication of the first digital identity. The at least one parameter is obtained based on the second digital identity that has been published in the second DL. Therefore, the published second digital identity is used to generate the first digital identity to be published, so as to perform cross-ledger authentication, which is convenient and efficient. Moreover, the first device's real identity or other privacy information is not required in this process, which has high security.

[0009] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes: storing the first digital identity.

[0010] The first device can save the newly generated digital identity (such as the first digital identity) locally. In this way, when the first device needs to join another DL network next time, it can first confirm whether the locally saved digital identity is valid in the DL network to be joined, that is, determine whether a new digital identity needs to be generated.

[0011] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes: updating the second digital identity, the updated second digital identity including a first identifier, the first identifier being used to identify the first device in the first DL.

[0012] It should be understood that the first digital identity is the digital identity of the first device in the first DL. Therefore, the first identifier is used to identify the first device in the first DL, and it can also be said that the first identifier identifies the first digital identity in the first DL.

[0013] Since the first digital identity is generated based on at least one parameter of the second digital identity, it can be said that the first digital identity is derived from the second digital identity. By updating the second digital identity, other digital identities derived from it (such as the first digital identity) can be associated with it. Thus, the first device can manage all digital identities associated with the second digital identity. For example, when the second digital identity needs to be revoked, the first device can easily revoke all other digital identities associated with it.

[0014] In conjunction with the first aspect, in some possible implementations of the first aspect, the first digital identity indicates one or more of the following: a domain identifier of the first digital identity, or a domain identifier of a verifiable credential (VC) of the first digital identity.

[0015] It should be understood that in this application, the key credential is an example of a VC. In other words, the domain identifier of the VC of the first digital identity can also be replaced by the domain identifier of the key credential of the first digital identity, that is, the domain identifier of the first key credential.

[0016] The domain identifier of the first digital identity can indicate the scope of use, or service area, of the first digital identity. The domain identifier of the VC of the first digital identity can also indicate the scope of use, or service area, of that VC. Based on the domain identifier of the first digital identity and / or the domain identifier of the VC of the first digital identity, the first device can determine in which areas the first digital identity can be used, and / or in which areas the VC of the first digital identity can be used.

[0017] In conjunction with the first aspect, in some possible implementations of the first aspect, the second digital identity prior to the update indicates one or more of the following: the domain identifier of the second digital identity, or the domain identifier of the VC of the second digital identity.

[0018] In conjunction with the first aspect, in some possible implementations of the first aspect, the updated second digital identity indicates one or more of the following: a domain identifier of the second digital identity, an identifier of another digital identity obtained based on the second digital identity, or a domain identifier of the VC of the second digital identity.

[0019] For an explanation of the domain identifier for the second digital identity and the domain identifier for the VC of the second digital identity, please refer to the above text, which will not be repeated here.

[0020] By specifying the usage scope of different digital identities and their respective VCs, the first device, when needing to join a DL network, can first search for the domain identifiers of existing digital identities and VCs to determine if a digital identity has been previously issued for the DL network it needs to join. If so, the previously issued digital identity can be used directly; otherwise, a new digital identity can be generated. In this way, the first device does not need to generate a digital identity every time it needs to join a DL network. This reduces the waste of computing resources caused by digital identity generation and the waste of signaling overhead caused by digital identity issuance, while also improving the efficiency of the first device joining DL networks.

[0021] The updated second digital identity also indicates the identifiers of other digital identities derived from the second digital identity, that is, to associate other digital identities derived from the second digital identity with the second digital identity, so that the first device can manage all digital identities associated with the second digital identity based on the second digital identity.

[0022] Optionally, the first digital identity or the second digital identity may also indicate one or more of the following: identifier (ID), controller, authentication method, type, service, VC version, VC serial number, VC issuer identifier, VC validity period, VC subject identifier, VC statement, VC distributed ledger record address, VC purpose, VC credential revocation list, or VC credential status service.

[0023] In conjunction with the first aspect, in some possible implementations of the first aspect, the at least one parameter includes: a second identifier and a first key credential, the second identifier being used to identify the first device in the second DL, and the first key credential being used to generate the first digital identity; before sending the first request message, the method further includes: generating a first public key and a first private key based on a second public key and / or a second private key corresponding to the second digital identity, the first public key and the first private key being used for authentication of the first device in the network of the first DL; and signing the first public key based on the first private key to obtain the first key credential.

[0024] That is, the first device generates the first key and the first key certificate on its own.

[0025] Optionally, the method further includes: obtaining a first identifier, the first identifier being used to identify the first device in the first DL; the step of signing the first public key based on the first private key to obtain the first key credential includes: signing the first public key and the first identifier based on the first private key to obtain the first key credential.

[0026] Optionally, generating the first public key and the first private key based on the second public key and / or the second private key corresponding to the second digital identity includes: generating the first public key and the first private key based on the second public key and / or the second private key corresponding to the second digital identity, and one or more of the following: timestamp, the media access control MAC address of the first device, a random number, a block hash, or a blockchain time.

[0027] Optionally, the at least one parameter may further include one or more of the following: timestamp, MAC address of the first device, random number, block hash, or blockchain time.

[0028] In conjunction with the first aspect, in some possible implementations of the first aspect, the at least one parameter includes: a second identifier and an identifier of the first DL, wherein the second identifier is used to identify the first device in the second DL.

[0029] Accordingly, the first response message carries a first key credential, which is obtained by signing the first key with the private key of the second device. The first key is used for authentication of the first device in the network of the first DL, and the public key of the second device is preset in the first DL and the second DL.

[0030] That is, the second device generates a first key credential for the first device. The second device can be a device in the network of the second DL, and the public key of the second device is pre-installed in the first DL and the second DL, so the public key of the second device can be obtained by devices in the network of the first DL and the network of the second DL.

[0031] Optionally, the first key credential is obtained by signing the first key with the private key of the second device, including: the first key credential is obtained by signing the first key and the first identifier with the private key of the second device, the first identifier being used to identify the first device in the first DL; the at least one parameter further includes one or more of the following parameters for generating the first identifier: the identifier of the algorithm for generating the first identifier, the identifier of the first DL, the timestamp, the MAC address of the first device, a random number, a block hash, or the blockchain time.

[0032] In conjunction with the first aspect, in some possible implementations of the first aspect, the at least one parameter includes: a second identifier and a first key credential, the second identifier being used to identify the first device in the second DL, the first key credential being obtained by signing the first key based on the private key of the second device, the first key being used for authentication of the first device in the network of the first DL; before sending the first request message, the method further includes: sending a second request message to the second device, the second request message being used to request the second device to generate the first key credential, the second request message carrying parameters for generating the first key credential; and receiving the first key credential from the second device.

[0033] That is, the second device generates the first key credential for the first device. The second device may not be a device in the network of the first DL and the second DL, but the public key of the second device is pre-installed in the first DL and the second DL, so the public key of the second device can be obtained by devices in the network of the first DL and the second DL.

[0034] Optionally, the first key credential is obtained by signing the first key with the private key of the second device, including: the first key credential is obtained by signing the first key and the first identifier with the private key of the second device, the first identifier being used to identify the first device in the first DL; the at least one parameter further includes one or more of the following parameters for generating the first identifier: the identifier of the algorithm for generating the first identifier, the identifier of the first DL, the timestamp, the MAC address of the first device, a random number, a block hash, or the blockchain time.

[0035] In conjunction with the first aspect, in some possible implementations of the first aspect, the at least one parameter includes: a second identifier and a first public key, wherein the second identifier is used to identify the first device in the second DL, and the first public key is used for authentication of the first device in the network of the first DL.

[0036] Optionally, the first response message carries a first key credential, which is obtained by signing the first public key based on the private key of the fifth device or the private key of the first DL, wherein the public key of the fifth device is preset in the first DL.

[0037] Optionally, the first key credential is obtained by signing the first public key based on the private key of the fifth device or the private key of the first DL, including: the first key credential is obtained by signing the first public key and the first identifier based on the private key of the fifth device or the private key of the first DL, the first identifier being used to identify the first device in the first DL; the at least one parameter further includes one or more of the following parameters for generating the first identifier: timestamp, MAC address of the first device, random number, block hash, or blockchain time.

[0038] Accordingly, the first response message carries a first key credential, which is obtained by signing the first key and the first identifier based on the private key of the fifth device or the private key of the first DL. The first identifier is used to identify the first device in the first DL.

[0039] That is, the fifth device generates the first key certificate for the first device, or the device holding the private key of the first DL in the first DL's network generates the first key certificate for the first device. The public key of the fifth device can be pre-installed in the first DL, therefore the public key of the fifth device can be obtained by devices in the first DL's network. The fifth device can be a device in the first DL's network, or it can be a device outside the first DL's network; there is no limitation on this.

[0040] In conjunction with the first aspect, in some possible implementations of the first aspect, before sending the first request message, the method further includes: determining that the first device does not have a digital identity in the network of the first DL.

[0041] Since the first request message is used to request the publication of a first digital identity in the first DL, sending the first request message can trigger the generation and publication of the first digital identity. The first device can first determine that no digital identity exists in the network of the first DL before sending the first request message. Thus, if a digital identity exists in the network of the first DL, the existing digital identity can be used instead of generating a new one. Therefore, the waste of computing resources caused by the generation of digital identities and the waste of signaling overhead caused by the publication of digital identities can be reduced, while also improving the efficiency of the first device joining the DL network.

[0042] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes: receiving a verification path, the verification path indicating the storage path of the first digital identity in the first DL; obtaining the first digital identity; and determining, based on the verification path, that the first digital identity is published in the first DL.

[0043] The first device uses a verification path to determine whether the first digital identity was indeed published in the first DL, thereby ensuring the authenticity of the received response message.

[0044] Optionally, obtaining the first digital identity includes: generating the first digital identity, or querying the first digital identity in the first DL.

[0045] In conjunction with the first aspect, in some possible implementations of the first aspect, the method further includes: saving the correspondence between the first digital identity and the first DL.

[0046] The correspondence between a first digital identity and a first DL (Data Provider) means that the scope of use of the first digital identity includes the first DL; that is, the first digital identity has been published within the first DL, and the first digital identity is legal or valid within the first DL's network. By storing the correspondence between digital identities and DLs, when a first device needs to join the network of a certain DL, it can determine whether the network of the DL it needs to join has a corresponding digital identity based on this correspondence. If it does, it can directly use the previously published digital identity; if not, it can generate a new digital identity. In this way, the first device does not need to generate a digital identity every time it needs to join the network of a certain DL. This reduces the waste of computing resources caused by the generation of digital identities and the waste of signaling overhead caused by the publication of digital identities, while also improving the efficiency of the first device joining the network of a DL. Furthermore, since this correspondence records the correspondence between digital identities and DLs, it is more direct and convenient to look up.

[0047] Secondly, a communication method is provided, which can be executed by a second device, the public key of which can be obtained by a device in the network of the first DL. The second device can be a core network element (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, an identifier (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.

[0048] The method includes: receiving a third request message from a first device, the third request message carrying an identifier of a first DL, the first DL being a DL for which the first device will issue a first digital identity; generating a first key credential, the first key credential being obtained by signing a first key and a first identifier, the first key being generated based on a second key, the first key being used for authentication of the first device in the network of the first DL, the second key being used for authentication of the first device in the network of a second DL that has issued a second digital identity; and sending the first key credential to the first device.

[0049] It should be understood that the third request message may correspond to the first request message or the second request message sent by the first device to the second device in the first aspect.

[0050] Based on the above scheme, the second device can determine the first digital identity to be published in the first DL based on the identifier of the first DL carried in the third request message. As a network element in the core network specifically responsible for managing digital identities, the second device can generate a first key credential for the first device. Since the first key credential is obtained by signing the first key, the first key is generated based on the second key, and the first key credential is used to generate the first digital identity, while the second key corresponds to the second digital identity, it can be said that the first digital identity is generated based on the second digital identity. Therefore, the already published second digital identity is used to generate the first digital identity to be published, enabling cross-ledger authentication, which is convenient and efficient; moreover, this process does not require the real identity or other privacy information of the first device, thus providing high security. Furthermore, since the second device represents the operator, the first key credential issued by the second device has higher credibility. Moreover, the second device's performance of identity derivation and verification functions reduces the resource consumption of the first device, allowing the first device's distributed ledger enabler (DLE) capabilities to be released.

[0051] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes: obtaining the first key; generating the first key credential includes: signing the first key based on the private key of the second device to obtain the first key credential.

[0052] That is, the second device issues the first key certificate, or in other words, the second device endorses the first key certificate.

[0053] Optionally, the second key is a second public key, and the first key includes a first public key and a first private key. The third request message also carries the second public key and an identifier of the algorithm used to generate the first key. Obtaining the first key includes generating the first public key and the first private key based on the second public key and the algorithm used to generate the first key. Signing the first key based on the private key of the second device to obtain the first key credential includes signing the first public key based on the private key of the second device to obtain the first key credential.

[0054] Optionally, the second key is a symmetric key, the first key is also a symmetric key, and the third request message further carries an identifier of the algorithm used to generate the first key; obtaining the first key includes: generating the first key based on the second key and the identifier of the algorithm used to generate the first key.

[0055] It should be understood that the above explanation of obtaining the first key has addressed both symmetric and asymmetric key scenarios. The second device can generate the first key credential based on different implementation methods, offering great flexibility.

[0056] It is easy to see that, regardless of whether it is a symmetric key or an asymmetric key, the first key can be generated based on the second key.

[0057] Optionally, the method further includes: obtaining the first identifier, the first identifier being used to identify the first device in the first DL; the step of signing the first key based on the private key of the second device to obtain the first key credential includes: signing the first key and the first identifier based on the private key of the second device to obtain the first key credential. The first key can be a symmetric key or a first public key in an asymmetric key, without limitation.

[0058] In conjunction with the second aspect, in some possible implementations of the second aspect, the third request message further carries a second identifier, which is used to identify the first device in the second DL. The method further includes: obtaining information in the second digital identity based on the second identifier; sending the first key credential and the information in the second digital identity to a third device in the network of the first DL, wherein the information in the second digital identity and the first key credential are used to generate the first digital identity.

[0059] In conjunction with the second aspect, in some possible implementations of the second aspect, the third request message further carries a second identifier, which is used to identify the first device in the second DL; the method further includes: sending the second identifier and the first key credential to a fourth device in the network of the second DL, wherein the second identifier is used to obtain information in the second digital identity, and the information in the second digital identity and the first key credential are used to generate the first digital identity.

[0060] The second device can use the second identifier as an index to obtain information from the second digital identity; alternatively, the second device can send the second identifier to a fourth device in the network of the second DL, allowing the fourth device to complete the acquisition of information from the second digital identity. This can provide support for the generation of the first digital identity.

[0061] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes: receiving a second response message from a fourth device in the network of the second DL, the second response message indicating the publication result of the first digital identity in the first DL; and sending a first response message to the first device, the first response message indicating the publication result of the first digital identity in the first DL.

[0062] The second device can send the publication result to the first device through the first response message so that the first device can understand the publication result of the first digital identity in the first DL.

[0063] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes: receiving an authentication path from a fourth device in the network of the second DL, the authentication path indicating the storage path of the first digital identity in the first DL; and sending the authentication path to the first device.

[0064] The second device sends the received verification path to the first device so that the first device can determine whether the first digital identity has indeed been published in the first DL based on the verification path.

[0065] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes: determining that the first device does not have a digital identity in the first DL.

[0066] After receiving the third request message, the second device can first determine whether the first device has a digital identity in the first DL. If it is determined that the identity does not exist, the second device can issue a first key credential to the first device; if it is determined that the identity exists, the second device can not issue a first key credential to the first device. In this way, the waste of computing resources caused by the generation of key credentials can be reduced.

[0067] In conjunction with the second aspect, in some possible implementations of the second aspect, the method further includes: determining that the first device is valid in the second DL.

[0068] After receiving the third request message, the second device can first determine whether the first device is valid in the second DL. Validity of the first device in the second DL can mean that the first device is legitimate in the second DL, or that the first device can be authenticated in the second DL. In other words, the identity of the first device has been authenticated by the second device.

[0069] Since the first digital identity issued by the first device in the first DL is generated based on the first key certificate, and this first key certificate is issued to the first device only after the second device has determined that the first device is valid in the second DL, this is beneficial for ensuring network security when the first device joins the network of the first DL.

[0070] Thirdly, a communication method is provided, which can be executed by a fifth device, the public key of which can be obtained by a device in the network of the first DL. The third device can be 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, an IDM, or other network elements that can be used to manage digital identities. This application includes, but is not limited to, these aspects.

[0071] The method includes: receiving a fourth request message from a third device, the fourth request message carrying a first public key, the first public key being generated based on a second public key and / or a second private key, the first public key being used for authentication of the first device in a first DL network where a first digital identity is to be issued, the second public key and the second private key being used for authentication of the first device in a second DL network where a second digital identity has been issued; generating a first key credential, the first key credential being obtained by signing the first public key based on the private key of a fifth device; and sending the first key credential to the third device.

[0072] Based on the above scheme, the fifth device, as a network element in the core network specifically responsible for managing digital identities, can issue a first key credential to the first device according to the fourth request message. Since the first key credential is obtained by signing the first public key, and the first public key is generated based on the second public key and / or the second private key, and the first key credential is used to generate the first digital identity, while the second public key and the second private key correspond to the second digital identity (for example, the second public key is a parameter in the second digital identity), it can be said that the first digital identity is generated based on the second digital identity. Therefore, the already published second digital identity is used to generate the first digital identity to be published, enabling cross-ledger authentication, which is convenient and efficient; and this process does not require the real identity or other privacy information of the first device, thus providing high security. Furthermore, since the fifth device represents the operator, the first key credential issued by the fifth device has higher credibility. Moreover, the fifth device's performance of identity derivation and verification functions reduces the resource consumption of the first device, allowing the first device's DLE (Digital Evidence Provider) capabilities to be released.

[0073] In conjunction with the third aspect, in some possible implementations of the third aspect, the method further includes: generating a first identifier, the first identifier being used to identify the first device in the first DL; the generation of the first key credential includes: signing the first identifier and the first key based on the private key of the fifth device to obtain the first key credential. The fifth device may also generate a first identifier for the first device, thereby providing support for the generation of the first key credential and the generation of the first digital identity.

[0074] In conjunction with the third aspect, in some possible implementations of the third aspect, the fourth request message also carries information from the second digital identity, and the method further includes: generating the first digital identity based on the first key credential and the information from the second digital identity; and publishing the first digital identity in the first DL.

[0075] The fifth device can directly generate the first digital identity for the first device and publish the first digital identity in the first DL. Since the fifth device represents the operator, the first digital identity published by the third device has higher credibility.

[0076] In conjunction with the third aspect, in some possible implementations of the third aspect, the method further includes: sending a third response message indicating the publication result of the first digital identity in the first DL.

[0077] Fourthly, a communication method is provided, which can be executed by a fourth device, which can be a device in the network of a second DL. The fourth device can be 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.

[0078] The method includes: receiving a fifth request message, the fifth request message being used to request the publication of a first digital identity of a first device in a first DL, the fifth request message carrying: a second identifier and a first key credential, the second identifier being used to identify the first device in a second DL where a second digital identity has been published, the first key credential being obtained by signing a first public key, the first public key being used for authentication of the first device in the network of the first DL; obtaining information in the second digital identity based on the second identifier; and sending a fourth request message to a third device in the network of the first DL, the fourth request message being used to request the generation of the first digital identity, the sixth request message carrying the first key credential for generating the first digital identity and the information in the second digital identity.

[0079] Based on the above scheme, the fourth device can obtain information from the second digital identity based on the received fifth request message, and send the information from the second digital identity and the received first key credential to the third device in the network of the first DL, so that the third device can generate the first digital identity and publish it in the first DL, thus providing support for the generation and publication of the first digital identity, thereby providing support for the cross-ledger authentication of the first device.

[0080] Furthermore, since the information in the second digital identity can be used to generate the first digital identity, the first digital identity can be said to be generated based on the second digital identity. Therefore, utilizing the already published second digital identity to generate the first digital identity to be published facilitates cross-ledger authentication, which is convenient and efficient; moreover, this process does not require the real identity or other privacy information of the first device, thus offering high security.

[0081] In conjunction with the fourth aspect, in some possible implementations of the fourth aspect, the method further includes: receiving a fourth response message from the third device, the fourth response message being used to indicate the publication result of the first digital identity in the first DL.

[0082] Optionally, the method further includes: sending a second response message to a second device in the second DL, the second response message being used to indicate the publication result of the first digital identity in the first DL.

[0083] The third device can send the publication result through a fourth response message so that the receiving device can forward the publication result to the first device, thereby enabling the first device to understand the publication result of the first digital identity in the first DL.

[0084] In conjunction with the fourth aspect, in some possible implementations of the fourth aspect, the method further includes: receiving a fourth response message from the third device, the fourth response message indicating the publication result of the first digital identity in the first DL, and the fourth response message carrying the first key credential; and sending a first response message to the first device, the first response message indicating the publication result of the first digital identity in the first DL, and the first response message carrying the first key credential.

[0085] The third device can send the publication result and the first key credential through a fourth response message, so that the receiving device can forward the publication result and the first key credential to the first device, thereby enabling the first device to understand the publication result of the first digital identity in the first DL and obtain the first key credential.

[0086] Fifthly, a communication method is provided, which can be executed by a fourth device, which can be a device in the network of a second DL. The fourth device can be 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.

[0087] The method includes: receiving a first request message from a first device, the first request message being used to request the publication of a first digital identity of the first device in a first DL, the first request message carrying: a first public key and a second identifier, the second identifier being used to identify the first device in a second DL, the first public key being used for authentication of the first device in the network of the first DL, and the second identifier being used to identify the first device in the second DL; obtaining information in the second digital identity based on the second identifier; and sending a sixth request message to a third device in the network of the first DL, the sixth request message being used to request the generation of the first digital identity, the sixth request message carrying the first public key and the information in the second digital identity, the first public key being used to generate a first key credential, and the first key credential and the information in the second digital identity being used to generate the first digital identity.

[0088] Based on the above scheme, the fourth device can obtain information from the second digital identity based on the received first request message, and send the information from the second digital identity and the received first public key to the third device in the network of the first DL, so that the third device can trigger the generation of the first key credential and the first digital identity, and publish the first digital identity in the first DL, thus providing support for the generation and publication of the first digital identity, thereby providing support for the cross-ledger authentication of the first device.

[0089] Furthermore, since the information in the second digital identity can be used to generate the first digital identity, the first digital identity can be said to be generated based on the second digital identity. Therefore, utilizing the already published second digital identity to generate the first digital identity to be published facilitates cross-ledger authentication, which is convenient and efficient; moreover, this process does not require the real identity or other privacy information of the first device, thus offering high security.

[0090] In conjunction with the fifth aspect, in some possible implementations of the fifth aspect, the method further includes: receiving a fourth response message from the third device, the fourth response message indicating the publication result of the first digital identity in the first DL, and the third response message carrying the first key credential; sending a first response message to the first device, the first response message indicating the publication result of the first digital identity in the first DL, and the first response message carrying the first key credential.

[0091] The fourth device can send the publication result and the first key credential through a fourth response message, so that the receiving device can forward the publication result and the first key credential to the first device, thereby enabling the first device to understand the publication result of the first digital identity in the first DL and obtain the first key credential.

[0092] In conjunction with the fourth or fifth aspect, in some possible implementations, the method further includes: receiving a verification path from a third device, the verification path indicating the storage path of the first digital identity in the first DL; and sending the verification path to the first device.

[0093] The fourth device sends the received verification path to the first device so that the first device can determine, based on the verification path, whether the first digital identity has indeed been published in the first DL.

[0094] Sixthly, a communication method is provided, which can be executed by a third device. This third device can be a device within the network of a first DL (Data Provider), and it holds the private key of the first DL. The third device can be a core network NF (Network Functional Node), or a component within the core network NF, such as a chip, chip system, processor, etc., or it can 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 can be, for example, a distributed ledger enable function (DLEF), and this application includes, but is not limited to, this.

[0095] The method includes: receiving a sixth request message from a fourth device, the sixth request message carrying a first public key, the first public key being generated based on a second public key and / or a second private key, the first public key being used for authentication of the first device in a first DL network where a first digital identity is to be issued, the second public key and / or the second private key being used for authentication of the first device in a second DL network where a second digital identity has been issued; generating a first key credential, the first key credential being obtained by signing the first public key based on the private key of the first DL; and sending the first key credential to the fourth device.

[0096] Based on the above scheme, the third device can issue a first key credential to the first device according to the fourth request message, and generate and publish a first digital identity, thereby realizing cross-ledger authentication for the first device. Since the first public key is generated based on the second public key and / or the second private key, and the first public key is used to generate the first key credential, which in turn is used to generate the first digital identity, while the second public key and the second private key correspond to the second digital identity (for example, the second public key is a parameter in the second digital identity), it can be said that the first digital identity is generated based on the second digital identity. Therefore, the already published second digital identity is used to generate the first digital identity to be published for cross-ledger authentication, which is convenient and efficient; moreover, this process does not require the real identity or other privacy information of the first device, thus providing high security.

[0097] In addition, since the private key of the first DL is jointly held by multiple nodes in the first DL network, when the third device fails, the issuance of the first key certificate, the generation and publication of the first digital identity can be handed over to other nodes in the first DL network, thereby mitigating the risk of single point of attack and facilitating the smooth and efficient completion of cross-ledger authentication.

[0098] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the method further includes: generating a first identifier, the first identifier being used to identify the first device in the first DL; the generation of the first key credential includes: signing the first public key and the first identifier based on the private key of the first DL to obtain the first key credential.

[0099] Because the algorithms used to generate identifiers in the first DL network and the second DL network may differ, the format of the identifier in the first DL network will also differ from that in the second DL network. If the first identifier is generated by a device in the second DL network, it may not conform to the format of the identifier in the first DL network, potentially leading to the first identifier being unverifiable by devices in the first DL network and consequently causing cross-ledger authentication failure. Therefore, having a third device in the first DL network generate the first identifier for the first device avoids the risk of the first identifier being unverifiable by devices in the first DL network, thus facilitating cross-ledger authentication for the first device.

[0100] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the fourth request message also carries information from the second digital identity, and the method further includes: generating the first digital identity based on the first key credential and the information from the second digital identity; and publishing the first digital identity in the first DL.

[0101] In conjunction with the sixth aspect, in some possible implementations of the sixth aspect, the method further includes: sending a fourth response message, the fourth response message being used to indicate the publication result of the first digital identity in the first DL.

[0102] The third device can send the publication result through a fourth response message so that the receiving device can forward the publication result to the first device, thereby enabling the first device to understand the publication result of the first digital identity in the first DL.

[0103] A seventh aspect provides a communication apparatus capable of implementing the methods described in the first to sixth aspects and any possible implementations thereof. 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 in software and / or hardware.

[0104] Eighthly, a communication device is provided, including a processor for performing the methods described in the first to sixth aspects and any possible implementation thereof.

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

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

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

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

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

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

[0111] A tenth aspect provides a communication system comprising one or more of the following: a first device, a second device, a third device, a fourth device, and a fifth device. The first device is used to implement the method in any possible implementation of the first aspect. The second device is used to implement the method in any possible implementation of the second aspect. The third device is used to implement the method in any possible implementation of the sixth aspect. The fourth device is used to implement the method in the fourth or fifth aspect and any possible implementation of the fourth or fifth aspect. The fifth device is used to implement the method in any possible implementation of the third aspect.

[0112] Eleventhly, a computer-readable storage medium is provided, including a computer program that, when run on a computer, causes the computer to implement the methods of the first to sixth aspects and any possible implementation of the first to sixth aspects.

[0113] In a twelfth aspect, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code or instructions), which, when run, causes a computer to perform the methods of the first to sixth aspects and any possible implementation thereof.

[0114] It should be understood that aspects seven to twelfth of this application correspond to the technical solutions of aspects one to six 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

[0115] Figure 1 is a schematic diagram of the VC data model;

[0116] Figure 2 is a schematic diagram of the network architecture applicable to the communication method provided in the embodiments of this application;

[0117] Figure 3 is a schematic diagram of a scenario applicable to the communication method provided in the embodiments of this application;

[0118] Figure 4 is a schematic diagram of the UCDID provided in an embodiment of this application;

[0119] Figure 5 is a schematic diagram of a Merkle tree;

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

[0121] Figure 7 is a schematic diagram of KC2 provided in an embodiment of this application;

[0122] Figure 8 is a schematic diagram of UCDID2 provided in an embodiment of this application;

[0123] Figure 9 is a schematic diagram of UCDID1 before and after the update provided in the embodiments of this application;

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

[0125] Figure 11 is another schematic diagram of KC2 provided in an embodiment of this application;

[0126] Figures 12A and 12B are two schematic flowcharts of a communication method provided in another embodiment of this application;

[0127] Figure 13 is another schematic diagram of UCDID2 provided in an embodiment of this application;

[0128] Figure 14 is another schematic diagram of UCDID1 before and after the update provided in the embodiments of this application;

[0129] Figure 15 is a schematic flowchart of a communication method provided in another embodiment of this application;

[0130] Figure 16 is another schematic diagram of KC2 provided in the embodiments of this application;

[0131] Figure 17 is another schematic diagram of UCDID2 provided in the embodiments of this application;

[0132] Figures 18A and 18B are two schematic flowcharts of a communication method provided in another embodiment of this application;

[0133] Figure 19 is a schematic flowchart of a communication method provided in another embodiment of this application;

[0134] Figure 20 is another schematic diagram of KC2 provided in the embodiments of this application;

[0135] Figure 21 is another schematic diagram of UCDID2 provided in the embodiments of this application;

[0136] Figure 22 is another schematic flowchart of a communication method provided in yet another embodiment of this application;

[0137] Figure 23 is a schematic diagram of a UCDID with a linear relationship provided in an embodiment of this application;

[0138] Figure 24 is a schematic diagram of a UCDID with a tree-like relationship provided in an embodiment of this application;

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

[0140] Figure 26 is another schematic block diagram of the communication device provided in an embodiment of this application. Detailed Implementation

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

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

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

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

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

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

[0147] Fifth, in this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to a 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 a 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 nodes in a DL network, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via a bus, wiring, or interface.

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

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

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

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

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

[0153] Distributed ledger technology, as a novel technology, is highly likely to be introduced into future networks. Users can join a distributed ledger using digital identities, allowing different operators to share the ledger simply by joining the same system, which is extremely convenient. Currently, digital identities are represented by decentralized digital identity (DID) and verifiable credential (VC) proposed by the World Wide Web Consortium (W3C).

[0154] Figure 1 is a schematic diagram of the VC data model proposed by the W3C. This model illustrates issuers, holders, verifiers, and a verifiable data registry platform. Issuers are the publishers (or signatories) of VCs, holders are the holders of VCs, and verifiers are the verifiers of VCs. Issuers issue VCs to the subject of a VC, which may include one or more claims. Issuers send VCs to holders, who may be the same as or different from the subject. Verifiers issue a request to verify certain claims of an object when needed. Holders or subjects process VCs to generate verifiable presentations (VPs) and submit them to verifiers, who then verify the VPs. VCs can be stored in a database, such as on a verifiable data registry platform.

[0155] This application aims to apply distributed ledger technology and digital identity technology to telecommunications networks to achieve cross-ledger authentication of user digital identities.

[0156] To facilitate understanding, the network architecture applicable to the methods provided in the embodiments of this application will be described in more detail first with reference to the accompanying drawings.

[0157] Figure 2 is a schematic diagram of the network architecture applicable to the communication method provided in the embodiments of this application. Figure 2(a) shows the network architecture within a single operator network. This network architecture shows distributed ledger anchor function (DLAF) network elements, distributed ledger enabler (DLE) modules, distributed ledger enable function (DLEF) network elements, identifier (ID) management (IDM) network elements, user plane (UPF) network elements, and data network (DN).

[0158] For example, DLAF and IDM can be independent entities, deployed in the core network as NF network elements, or simply NF. The DLAF network element serves as the anchor point for the overall management and association of the DL network, and can be used to perform functions such as DL network management, DLE module registration management, DL creation, DLE module activation, and access control of the DL. DLAFs are generally deployed in the core network as network functions, but may also have a hierarchical structure, i.e., sub-DLAFs are deployed in the access network. IDM can be seen as an enhancement to the unified data management (UDM) in the current 5G core network (5Gcorenet, 5GC), used to store user digital identities and credentials, and can also issue (or sign) digital identities to terminals, RAN nodes, NFs, etc.

[0159] The DLE module can accept configuration and management from the DLAF. Different node types are distinguished based on node capabilities, and it possesses one or more of the following functions: transaction proposal, transaction endorsement / execution, smart contract deployment and execution, consensus, transaction / block synchronization, ledger storage, etc. The DLE module can reside on various nodes in the network, including terminals, RAN nodes, and NF network elements in the core network. All nodes requiring DL capabilities can deploy a DLE module, either as an independent entity or as an internal module. A DLE module deployed in the core network can also function as an independent NF, i.e., a DLEF, providing DL proxy capabilities to other NFs. Furthermore, DLEs can be categorized into peer nodes or clients based on permissions. For example, a terminal can be considered a client. RAN nodes, servers, and core network elements can be considered either clients or peer nodes. Peer nodes can perform one or more of the following operations: participate in consensus, propose transactions, and save or query ledger data. Clients can execute transaction proposal operations.

[0160] The DLAF can be directly connected to the DLE module on the radio access network (RAN) side, or it can be connected through a connection function in the network, such as the access and management function (AMF) in the 5GC.

[0161] Figure 2(b) illustrates the network architecture within a multi-carrier network. As shown, Carrier A and Carrier B can transmit messages through Security Edge Protection Proxies (SEPPs). In this case, Carrier A and Carrier B may belong to the same DL network or to two different DL networks. The descriptions of the network elements in Figure 2(b) that are identical to those in Figure 2(a) can be found above in conjunction with Figure 2(a), and will not be repeated here.

[0162] Figure 3 is a schematic diagram of a scenario applicable to the communication method provided in the embodiments of this application. Figures 3(a) and (b) respectively show two possible scenarios in which a terminal (DLE0 as shown in the figure) joins the network of DL2 from the network of DL1. Corresponding to Figures 2(a) and (b) respectively, Figure 3(a) shows the scenario of a terminal joining DL2 from DL1 under the network architecture within one operator's network, and Figure 3(b) shows the scenario of a terminal joining DL2 from DL1 under the network architecture of different operators.

[0163] As shown in Figures 3(a) and (b), the DL1 network includes nodes DLE0, DLE1, and DLE2-a, which can establish trust through the DL1 network. DLE0 is the terminal, while DLE1 and DLE2-a are telecommunications network nodes, which may be access network equipment, NFs, or dedicated servers deployed by operators to run DL, etc., without limitation. The DL2 network includes nodes DLE2-b and DLE3, which establish trust through the DL2 network. IDM1 manages the digital identities of nodes within the DL1 network, and IDM2 manages the digital identities of nodes within the DL2 network.

[0164] Optionally, the IDM can be deployed in conjunction with a DLE module; that is, the IDM can act as a node within the DL network, participating in DL data queries, transaction generation, and consensus algorithms. Optionally, the IDM may also choose not to act as a node within the DL network.

[0165] Optionally, DLE2-a and DLE2-b can be co-located in a single physical entity. In this case, DLE2-a and DLE2-b can be collectively referred to as DLE2. This DLE2 belongs to both DL1 and DL2 and can query data from both DL1 and DL2. That is, DLE2 is a cross-ledger node. Trust between the two DL networks can be established through the cross-ledger node DLE2.

[0166] For example, in Figure 3(a), since DLE2 belongs to both DL1 and DL2, IDM1 and IDM2 can establish trust. That is, trust can be established between DL1 and DL2. It should be understood that the figure is only used to distinguish the nodes in the networks of the two different DLs, DL1 and DL2. From a functional perspective, DLE is exemplarily shown as DLE2-a and DLE2-b respectively. In fact, the two can be deployed in the same physical entity.

[0167] Optionally, DLE2-a and DLE2-b can be set separately. For example, DLE2-a is a node in the DL1 network, and DLE2-b is a node in the DL2 network.

[0168] Trust can also be established between two DL networks in other ways, such as in Figure 3(b), where SEPP in a multi-carrier architecture is reused. In this case, DLE2-a belongs to the DL1 network, and DLE2-b belongs to the DL2 network. SEPP may be co-located with the DLE2 module or set up independently. DLE2-a and SEPP-a belong to the same carrier, so they can trust each other; DLE2-b and SEPP-b belong to the same carrier, so they can also trust each other; the two carriers have a cooperative relationship and pre-configure each other's SEPP public keys, so SEPP-a and SEPP-b can also trust each other; through SEPP-a and SEPP-b, DLE2-a and DLE2-b can establish trust, and IDM1 and IDM2 can establish trust.

[0169] It should be understood that DL1 and DL2 can each store their own node identity information, enabling credential verification between nodes in the DL network to improve communication security. Taking DL1 as an example, if the DL1 network includes nodes DLE0, DLE1, and DLE2, then DL1 can store the identity information of nodes DLE0, DLE1, and DLE2, allowing each of them to authenticate each other. Different nodes in the DL1 network can have the same or different permissions. For example, some nodes can participate in consensus, query information, and write information; some nodes can query and write information but cannot participate in consensus; and some nodes can write information but cannot query information or participate in consensus, and so on.

[0170] It should also be understood that Figure 3 is merely an example and should not constitute any limitation on this application. There is not necessarily a one-to-one correspondence between DLs and operators. The same operator can join one or more DL networks. The same DL network can also have one or more operators joining it. For example, operator A joins the DL1 network, and operator B joins the DL2 network; or, for another example, both operators A and B join the DL1 network; or, for yet another example, operator A joins both the DL1 and DL2 networks, and so on, without further elaboration.

[0171] In addition, DL1 and DL2 can each maintain information about at least one credential issuer (or credential provider), such as maintaining the issuer's public key certificate. The issuer information maintained by DL1 and DL2 can be completely or partially the same, without limitation.

[0172] The credential issuer in this application may issue credentials, certificates, or digital identities. A credential issuer may also be referred to as a certificate issuer or a digital identity issuer. For example, a credential issuer includes one or more of the following: operators, social authorities, international organizations, or application providers. These credential issuers are further described below.

[0173] The operator can be a domestic or overseas operator. This operator may include the operator managing the distributed ledger. It may also include operators that cooperate with the operator managing the distributed ledger. Taking DL1 as an example, if the operator managing DL1 is operator A, and operator A cooperates with operators B and C, then the credential issuers maintained by DL1 include operator A. Optionally, the credential issuers maintained by distributed ledger 201 may also include at least one of operators B or C. Furthermore, when an operator acts as an issuer, an IDM can perform the issuer functions on behalf of the operator, such as issuing credentials, certificates, or digital identities.

[0174] Social authorities include one or more of the following: the state or organizations, such as customs, immigration, or education authorities.

[0175] International organizations refer to various institutions established by two or more countries, peoples, or non-governmental organizations for specific purposes in the form of certain agreements. For example, international organizations include one or more of the following: the 3rd Generation Partnership Project (3GPP), the Global System for Mobile Communications Association (GSMA), the Internet Engineering Task Force (IETF), or the International Telecommunication Union (ITU).

[0176] Application providers may include providers or suppliers of third-party applications that can be used in telecommunications networks.

[0177] In this application, the nodes included in the DL1 network and the nodes included in the DL2 network may be partially the same or completely different, and there is no limitation. The nodes in the DL1 and DL2 networks may include, but are not limited to, terminals, RAN nodes, servers, or core network elements.

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

[0179] 1. Distributed Ledger (DL) Technology: A database technology characterized by a record system maintained collaboratively by multiple participants, which can be distributed across different locations. The core characteristic of distributed ledger technology is decentralization. Data and transaction management no longer relies on a single central authority, but rather multiple nodes in the network jointly verify, store, and update data. This structure makes the system more transparent, robust, and reduces the risk of single points of failure. To ensure consensus on data consistency among nodes, distributed ledgers employ a consensus mechanism. This means that all transactions or events must be verified and agreed upon by multiple nodes in the network before being added to the ledger. Once data is added to the distributed ledger, it is difficult to modify or delete. Each data block is linked to the previous data block, forming a continuously expanding chain structure (such as a blockchain). This structure ensures that modifying any data block requires modifying the entire ledger, greatly enhancing data security and trustworthiness. A distributed ledger can be understood as a distributed database, typically with high transparency, allowing participants to view and verify the data on the ledger. However, for the processing of sensitive information, some distributed ledger technologies provide privacy protection mechanisms, such as using encryption algorithms to protect the privacy of data.

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

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

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

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

[0184] 3. UCDID: In this embodiment, UCDID can be considered a possible form of digital identity. UCDID includes an identifier (ID) and a profile. The profile includes a document and a verifiable credential (VC). UCDID can be seen as an extension of the decentralized identity (DID) defined by the World Wide Web Consortium (W3C). The decentralized identity can also be called a distributed identity, without limitation.

[0185] Figure 4 is a schematic diagram of the UCDID provided in an embodiment of this application. The UCDID includes an ID and a profile, as detailed below:

[0186] Identifier (ID): This identifier can be used to identify the subject of the UCDID. In the embodiments of this application, the identifier of the UCDID can be used to identify the device (i.e., the subject of the UCDID) in the DL. For example, the device may have different UCDIDs in different DLs, which are distinguished by different identifiers. For example, in DL1, the device's UCDID1 can be identified by identifier 1; in DL2, the device's UCDID2 can be identified by identifier 2. Since UCDID1 and UCDID2 are the same device's UCDIDs in different DLs, it can also be said that identifier 1 can be used to identify the device in DL1, and identifier 2 can be used to identify the device in DL2.

[0187] 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 a subscriber permanent identifier (SUPI) or other formats specified by the 3rd Generation Partnership Project (3GPP). The ID can be generated by the subject of the UCDID or by a single issuer (such as an operator). This application does not limit this. The UCDID can be stored on the DL in the form of key-value pairs. In this case, the ID can serve as an index to the UCDID, used to look up the profile corresponding to that ID in the DL.

[0188] profile: can include one or more of the following fields:

[0189] - Controller (sbjController): Represents the actual controller of the UCDID subject. For example, if parents control the UCDID for their child, then the UCDID ID can be the child's ID, and the sbjController can be the parent's ID.

[0190] - 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.). Generally, the entity generating the ID can also generate the corresponding key for authentication. If the entity generates an asymmetric key, the public key can be placed in this field; if the entity generates a symmetric key, this field can contain information indicating the symmetric key, rather than the plaintext key. This is because the UCDID is publicly available, and the symmetric key should be kept confidential to prevent attackers from impersonating the user.

[0191] - Type (sbjType): The type of the subject of the UCDID, such as: UE, NF, RAN node, organization.

[0192] - Services: A set of services that a UCDID subject can provide.

[0193] - Domain ID: This indicates the scope of use or service area of ​​a UCDID. For example, if a UCDID is used within a specific DL network, the domain ID can be the DL ID; similarly, if a UCDID is used within the network service area provided by a specific operator, the domain ID can be a Public Land Mobile Network (PLMN) ID, etc. It should be understood that a UCDID can be used in one or more domains; therefore, a domain ID can also have one or more identifiers indicating the scope of use of that UCDID.

[0194] - Related ID: The ID of the UCDID associated with this UCDID. In the embodiments of this application, the related ID may refer to the ID of the child UCDID derived from this UCDID as the root UCDID.

[0195] - Verifiable credential (VC): A collection of claims that are issued by other organizations or users, endorsed by the issuer, and can be verified using the issuer's public key.

[0196] For example, VC includes one or more of the following fields:

[0197] - Version: The version number of the voucher, used to determine the method and parameters for generating the voucher.

[0198] - Serial number (SN): The serial number assigned to the credential by the issuer.

[0199] - Issuer ID: The ID that indicates the UCDID of the issuer of this credential.

[0200] - Validity: The period during which the voucher is valid.

[0201] - Domain ID: This indicates the scope of use of the credential. For example, if the credential is used within a specific domain (DL), the domain ID can be the DL ID, indicating that the credential can be used within that DL. It should be understood that a credential can be used in one or more domains.

[0202] - Subject ID: The ID of the UCDID of the credential subject. It can be the subject corresponding to the UCDID or other entities. For example, if parents keep a credential for their child, the child is the subject of the credential, and the parents are the subjects corresponding to the UCDID, i.e., the holders.

[0203] - Claim: A statement about the subject of this credential. This field can be expressed using a "subject-attribute-value" relationship.

[0204] - Distributed ledger record address: Indicates the verification path of the credential in the distributed ledger.

[0205] - Usage: Indicates the scenario in which the credential will be used. For example, a KC can be used for authentication, while a VC can be used to prove a certain attribute of the subject, such as being 18 years of age or older, etc.

[0206] - Certificate revocation list (CRL) distribution point: A Uniform Resource Locator (URL) that provides access to CRL files. The CRL contains a list of VCs revoked by the issuing authority (CA).

[0207] - Credential status service: An interface that allows you to obtain the status of credentials, such as the name of a smart contract in a distributed ledger used to query the status of credentials.

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

[0209] Key credential (KC): To enhance the credibility of the key in the "authentication" field, an issuer (e.g., an operator) can endorse the user's public key and generate a KC. A single UCDID may have multiple KCs. When the credential is a KC, the claim field can be the public key of the credential subject.

[0210] Attribute credential (AC): Contains the object's attributes. When the credential is AC, the claim field contains attributes of the credential body, such as: being 18 years of age or older, being a legal citizen, and the user's subscription plan with the operator.

[0211] It should be understood that UCDID is only one possible form of digital identity and should not constitute any limitation on this application. This application does not limit the specific form of digital identity.

[0212] It should also be understood that the domain identifier of a VC and the domain identifier of a UCDID may be completely identical or partially identical. For example, the domain identifier of a VC may be a subset of the domain identifier of a UCDID. As an example, a DL network may involve two operators, for example, operator A and operator B. A terminal may have one UCDID in this DL, meaning that the terminal can use the same UCDID within the network service range of both operators. However, the terminal may have multiple VCs in this DL, corresponding to different domain identifiers. For example, within the network service range of operator A, the domain identifier of VC1 is PLMN ID1, and VC1 is used for authentication within the network service range of operator A; within the network service range of operator B, the domain identifier of VC2 is PLMN ID2, and VC2 can be used for authentication within the network service range of operator B. Both the network service ranges of operator A and operator B fall within the range corresponding to the domain identifier of the UCDID.

[0213] 3. Symmetric key encryption: also known as private key encryption or shared key encryption. This refers to both the sender and receiver using the same key to encrypt plaintext or decrypt ciphertext.

[0214] 4. Asymmetric key encryption: Also known as public-key encryption, this refers to the use of a mathematically related pair of keys by both the sender and receiver of data for encryption or decryption. In this key pair, one is a private key (SK), and the other is a public key (PK). This key pair is called a public-private key pair. The public key can be used for encryption, and the private key can be used for decryption; in this case, the encryption key is public. Alternatively, the private key can be used for encryption, and the public key can be used for decryption; in this case, the decryption key is public.

[0215] 5. Hash: A hash is a process that transforms input data of arbitrary length (such as text, files, etc.) into a fixed-length output value using a hash algorithm. This output is called the hash value. Simply put, it's a function that compresses data of arbitrary length into a fixed-length digital digest. A hash value is typically a unique string, and the output of a hash algorithm is irreversible, meaning the original input cannot be deduced from the hash value.

[0216] 6. Digital Signature: Also known as a signature, it is a technology used to verify the authenticity of information. It combines hashing and asymmetric encryption. In a digital signature, the information is first hashed, and then the sender's private key is used to encrypt the hash value to generate a signature. The sender can then send the information and the signature together to the recipient. The recipient uses the sender's public key to decrypt the signature, obtain the hash value, and compares it with the hash value calculated from the information received from the sender to ensure that the information has not been tampered with and indeed originated from the sender holding the private key.

[0217] In the following embodiments, for ease of distinction and explanation, messages carrying signatures are described as information and signature. Information is the content that the sender actually wants to send, and signature is the content after the hash value of the information has been encrypted.

[0218] 7. Validation Path: This indicates the storage path of the data in the deep learning (DL). For ease of understanding, the following explanation uses a Merkle tree as an example to illustrate the validation path.

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

[0220] Figure 5 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. EF H 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 .

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

[0222] 8. Smart Contract: A computer protocol designed to disseminate, verify, or execute contracts in an informational manner. Simply put, a smart contract can be understood as a piece of automatically executing code installed on blockchain nodes. For the same input parameters, all blockchain nodes can produce the same output parameters.

[0223] As mentioned earlier, if a user's newly joined operator participates in different ledger networks than the user's original operator, the newly joined operator cannot authenticate the user's digital identity. Furthermore, for two operators participating in different DL networks, if they need to share infrastructure or spectrum resources at geographical boundaries, or if one operator sells equipment to another, they also need to authenticate the digital identities of telecommunications network nodes (e.g., NF, RAN nodes, etc.). Therefore, it is desirable to provide a method that enables cross-ledger authentication of digital identities between different DL networks, so that the authentication of nodes within a DL network is no longer limited to the same DL network.

[0224] In view of this, this application provides a method in which a digital identity to be published to a DL (such as a first digital identity) can be generated (such as a second digital identity) based on a digital identity already published to another DL (such as a second DL). Nodes in the network of the DL to be published can publish the newly generated digital identity to the DL to be published. This enables cross-ledger authentication of digital identities between different DL networks, so that the authentication of nodes in the DL network is no longer limited to the same DL.

[0225] It should be noted that a DL network may have one operator joining it. In this case, cross-ledger authentication may be cross-operator authentication. An operator may also join multiple different DL networks, and cross-ledger authentication may not be operator authentication. A DL network may also have multiple operators joining it, and the same operator may join multiple different DL networks. In this case, cross-ledger authentication may or may not be cross-operator authentication.

[0226] Furthermore, a DL network may also have a distributed subnet joining it. In this case, cross-ledger authentication may be cross-distributed subnet authentication. A DL network may also have multiple distributed subnets joining it. In this case, cross-ledger authentication may not be cross-distributed subnet authentication. A DL network may also have multiple distributed subnets joining it, and the same distributed subnet may join multiple different DL networks. In this case, cross-ledger authentication may or may not be cross-distributed subnet authentication.

[0227] To better understand the methods provided in the embodiments of this application, it is also necessary to briefly explain several technical details involved in the embodiments below.

[0228] In several embodiments described below, the querying of UCDID or other information from the DL is frequently mentioned. Taking a consortium blockchain as an example, the data stored in the DL consists of two parts: a world state and a blockchain. The world state is a key-value table that stores the latest state of the data; the blockchain is a chained storage that stores transactions related to the data. Assuming the native distributed ledger of the telecommunications network adopts the distributed ledger data format of the consortium blockchain, the data storage for UCDIDs is as follows: The world state stores the UCDIDs of the nodes in the current DL, using the ID field of the UCDID as the key and other content as the value. For privacy protection and storage space conservation, the world state may store the hash of the ID and other content besides the ID (i.e., the hash of the profile), or the hash of the ID and the document / VC, or the hash of the ID, document, VC SN, and other parts of the VC. The blockchain stores update records involving UCDIDs (called transactions), such as: a UCDID being stored on the blockchain, a node corresponding to a UCDID obtaining a VC, and the VC being uploaded to the blockchain, etc. One or more transactions can be assembled together to form a block, and the block header contains the hash of the previous block, the block creation time, etc. Any DLE with query permissions can query the DL, retrieve UCDID content from the world state, and also retrieve information such as the hash of the current block and the current block height from the blockchain.

[0229] It should be noted that the following embodiments use the interaction between devices as an example to describe the method provided in this application. The naming of the devices in the following embodiments is only an example and should not constitute any limitation on this application. These devices are only divided from a functional perspective. In actual deployment, some devices can be housed in one entity, while some devices can be deployed separately in different entities.

[0230] Furthermore, "device" can refer to the device itself, or to components within the device, such as a chip, chip system, processor, or the logic modules or software therein that can be used to implement their respective functions, etc. This application does not limit the scope of the term.

[0231] It should also be noted that the following description uses UCDID as an example of digital identity for ease of understanding and illustration only, but this should not constitute any limitation on this application. In more embodiments, UCDID can be replaced with digital identity in the following description, and the processing method of UCDID in the following description is also applicable to other digital identities besides UCDID.

[0232] To facilitate understanding and explanation of the embodiments described below, the devices and their corresponding equipment mentioned below are described as follows.

[0233] The first device can correspond to a client, such as a terminal, RAN node, NF, etc. For example, the first device can correspond to DLE0 shown in Figures 3(a) and (b). In the embodiments described below, the first device can join the network of the first DL from the network of the second DL. The second DL, for example, corresponds to DL1 shown in Figures 3(a) and (b), and the first DL, for example, corresponds to DL2 shown in Figures 3(a) and (b).

[0234] The second device may correspond to an IDM, such as IDM1 in Figures 3(a) and (b). The public key of this second device may be pre-set in the second DL, for example, it may be obtainable by nodes in the second DL network. In some embodiments, the public key of the second device may also be pre-set in the first DL, for example, it may be obtainable by nodes in the first DL network. The second device also stores the correspondence between the keys and identifiers of each node in the second DL network generated by the second device. The second device may or may not be a device in the second DL network; there is no limitation.

[0235] The third device can correspond to a node in the network of the first DL and can establish trust with a node in the network of the second DL. For example, the third device can correspond to node DLE2-b in the network of DL2 shown in Figures 3(a) and (b) and can establish trust with node DLE2-a in the network of DL1.

[0236] The fourth device can correspond to a node in the network of the second DL and can establish trust with a node in the network of the first DL. For example, the fourth device can correspond to node DLE2-a in the network of DL1 shown in Figures 3(a) and (b) and can establish trust with node DLE2-b in the network of DL2.

[0237] In one possible design, DLE2-a and DLE2-b can be co-located in a single physical entity. In this case, DLE2-a and DLE2-b can be referred to as DLE2, and DLE2 is a cross-ledger node. That is, the third and fourth devices are deployed in the same physical entity.

[0238] The fifth device can correspond to IDM1, for example, it can correspond to IDM2 in Figures 3(a) and (b). The public key of the fifth device can be pre-set in the first DL, for example, it can be obtained by nodes in the network of the first DL. The fifth device also stores the correspondence between the keys and identifiers of each node in the network of the first DL generated by the fifth device. The fifth device can be a device in the network of the first DL, or it can be a device that is not in the network of the first DL, without limitation.

[0239] The sixth device may correspond to a node in the network of the first DL, such as a consensus node in a blockchain network. For example, the sixth device may correspond to DLE3 in Figures 3(a) and (b). In the embodiments described below, the sixth device may be shown as a device in the network of the first DL, primarily used to represent an example of a node that receives the first digital identity during the publication process in the first DL.

[0240] To facilitate distinction and explanation, a brief explanation of several terms mentioned below is also provided here.

[0241] First Digital Identity: The digital identity that the first device will publish in the first DL. The first digital identity may, for example, correspond to UCDID2, which will be published in DL2 in the scenarios shown in Figures 3(a) and (b).

[0242] First identifier: used to identify the first device in the first DL, or in other words, used to identify the first digital identity in the first DL, such as ID2 in UCDID2.

[0243] First key credential: The key credential in the first digital identity, such as KC2 in UCDID2.

[0244] Second digital identity: The digital identity that the first device has published in the second DL. The second digital identity may, for example, correspond to UCDID1 published in DL1 in the scenarios shown in Figures 3(a) and (b).

[0245] Second identifier: used to identify the first device in the second DL, or in other words, used to identify the first digital identity in the second DL, such as ID1 in UCDID1.

[0246] Second key credential: The key credential in the second digital identity, such as KC1 in UCDID1.

[0247] It should also be noted that, in order to distinguish between different senders and receivers, multiple request messages and multiple response messages are defined based on the different senders and / or receivers. These request messages and response messages are distinguished by different numbers, which should not impose any restrictions on the order in which the messages are sent.

[0248] Figure 6 is a schematic flowchart of the communication method 600 provided in an embodiment of this application. The steps in Figure 6 are described in detail below.

[0249] In step 601, the first device sends a first request message carrying at least one parameter for publishing the first digital identity of the first device in the first DL, some or all of which are obtained based on the second digital identity of the first device already published in the second DL.

[0250] The first device is the device that will publish the first digital identity across ledgers, for example, it may correspond to DLE0 shown in Figures 3(a) and (b). In this embodiment, the first device holds a second digital identity that has been published in the second DL and will publish the first digital identity in the first DL. Therefore, the aforementioned cross-ledger publication may specifically refer to publication from the second DL to the first DL.

[0251] For example, the first device may correspond to a terminal, or it may correspond to a telecommunications network node such as an NF or RAN node. For instance, due to the high mobility of the terminal, it may move from one region (e.g., region A) to another region (e.g., region B). If the operator in region A participates in the network of the second DL, and the operator in region B participates in the network of the first DL, then the terminal determines that it needs to join the network of the first DL. As another example, for two operators participating in networks of different DLs, if they need to share infrastructure or spectrum resources at geographical boundaries, or if one operator sells a piece of equipment to another operator, then the telecommunications network node (e.g., an NF, RAN node, etc.) may also determine that it needs to join the network of the first DL.

[0252] In this embodiment, the first device can send the first request message to a fourth device in the network of the first DL. Accordingly, in step 601, the fourth device receives the first request message from the first device.

[0253] The fourth device is a device in the network of the second DL, for example, it may correspond to DLE2-a shown in (a) and (b) of Figure 3.

[0254] The second digital identity is the digital identity already published by the first device in the second DL. The first digital identity is the digital identity that the first device will publish in the first DL. Both the first and second digital identities are digital identities of the first device, but they are different DLs, that is, the domain identifiers of the first and second digital identities are different, and the domain identifiers of the VCs of the first and second digital identities are different. For example, a digital identity can be a UCDID; for instance, the second digital identity already published in the second DL is UCDID1, and the first digital identity to be published in the first DL is UCDID2. A more detailed explanation of digital identities can be found in the description above in conjunction with Figure 4, and will not be repeated here.

[0255] The first request message is used to request the publication of the first digital identity in the first ledger. This first request message can also be called a cross-ledger request.

[0256] In this application, at least one parameter carried in the first request message for publishing the first digital identity can be obtained from the second digital identity. Since the first digital identity needs to be generated (or created) before it is published, it can also be said that at least one parameter used to generate the first digital identity can be obtained from the second digital identity.

[0257] In this embodiment, the at least one parameter includes a second identifier and a first key credential. That is, the first request message carries the second identifier, the first identifier, and the first key credential.

[0258] The second identifier can be used to identify the second digital identity of the first device in the second DL; that is, the second identifier can be used to identify the first device in the second DL. The second identifier can be obtained from the second digital identity.

[0259] The first key credential is obtained by signing the first public key with the private key of the first device. In this embodiment, the first public key and the first private key are a public-private key pair, which can be generated based on a second public key and / or a second private key. The second public key and the second private key are another public-private key pair used by the first device in the second DL. The second public key can be obtained from the second digital identity, and the first public key and the first private key can be generated based on the second public key and / or the second private key; therefore, it can also be said that the first public key and the first private key are obtained based on the second digital identity.

[0260] The first identifier can be used to identify the first digital identity of the first device in the first DL, that is, the first device can be used to identify the first device in the first DL.

[0261] The following details how each parameter is obtained.

[0262] Since the second digital identity is a published digital identity, the first device can obtain the second identifier from the second digital identity.

[0263] The first key credential is used to generate the first digital identity to be issued. In this embodiment, the first device can generate the first key credential itself. Optionally, before step 601, the method further includes step 601': the first device generates the first key credential.

[0264] For example, the first key credential can be obtained by signing the first public key based on the first private key. The first device generates the first key credential, which specifically includes: the first device generating a first public key and a first private key based on the second public key and / or the second private key corresponding to the second digital identity; the first device signing the first public key based on the first private key to obtain the first key credential. Since the key contained in the first key credential is the first public key, the first key credential can also be called the first public key credential.

[0265] It should be understood that the first public key and the first private key form a public-private key pair, which can be simply referred to as the first public-private key pair, and are used to obtain the first key credential, thus corresponding to the first digital identity. The second public key and the second private key form another public-private key pair, which can be simply referred to as the second public-private key pair, and can be used for authentication of the first device in the second DL network, corresponding to the published second digital identity.

[0266] For example, the first device may generate a first public key and a first private key based on at least one of a second public key or a second private key, and an algorithm for generating the key.

[0267] There can be a variety of algorithms used to generate keys.

[0268] For example, the algorithm used to generate the key can be an XOR operation. For instance, the first private key can be obtained by XORing the second private key, and the first public key can be obtained by XORing the second public key.

[0269] For example, the algorithm used to generate the key can be a cryptographic hash function (SHA), such as SHA256, which performs a hash operation on the input parameters to obtain a hash value of length 256 bits. For instance, the first private key is obtained by concatenating the second private key with the identifier of the first DL and then performing SHA256, and the first public key is obtained by concatenating the second public key with the identifier of the first DL and then performing SHA256.

[0270] For example, the algorithm used to generate the key can be a hash-based message authentication code (HMAC) algorithm, such as HMAC-SHA512, which uses the SHA512 hash function to generate the HMAC. For instance, the first private key can be calculated based on seed parameters. The seed parameters can be any string, such as a timestamp, the medium access control (MAC) address of the first device, a random number, a block hash, the blockchain time, etc., without limitation. In other words, the first private key is not limited to being generated from the second private key; it can also be generated from one or more of the following: timestamp, the MAC address of the first device, a random number, a block hash, the blockchain time, etc.

[0271] For example, the algorithm may also include some existing key derivation protocols, such as Bitcoin Improvement Proposals (BIP) 32.

[0272] It should be understood that the examples of generating the first public key and the first private key given above are provided for ease of understanding only and should not constitute any limitation on this application, which includes but is not limited thereto.

[0273] Optionally, the first key credential further includes a first identifier, which is obtained by signing the first identifier and the first public key based on the first private key. Accordingly, the aforementioned first device signing the first public key based on the first private key to obtain the first key credential includes: the first device signing the first identifier and the first public key based on the first private key to obtain the first key credential.

[0274] Before the first device signs the first identifier and the first public key based on the first private key to obtain the first key credential, the method further includes: the first device obtaining the first identifier.

[0275] The first device can generate the first identifier based on parameters used to generate the first identifier and an algorithm used to generate the first identifier.

[0276] The parameters used to generate the first identifier may include one or more of the following: second identifier, first public key, identifier of the first DL, timestamp, MAC address of the first device, random number, block hash, blockchain time, etc.

[0277] There are various algorithms that can be used to generate the first identifier. For example, ID2 can be generated based on current UUID generation methods, such as timestamps, the MAC address of the first device, random numbers, block hashes, blockchain timestamps, etc. Another example is generating the first identifier based on the first public key. For instance, the first public key can be directly used as the first identifier; or the first public key can be appended to the "method" field of the first identifier, meaning the first public key is used as part of the first identifier.

[0278] As can be seen, the first identifier can be generated based on the first public key, and the first public key can be generated based on the second public key and / or the second private key. Therefore, it can also be said that the first private key is obtained based on the second digital identity.

[0279] It should be understood that the examples of generating the first identifier given above are provided for ease of understanding only and should not constitute any limitation on this application, which includes but is not limited thereto.

[0280] It should also be understood that the parameters used to generate the first identifier and the parameters used to generate the first public-private key pair can be the same or different. During the generation of the first identifier and the first public-private key pair, the algorithms used to generate the first identifier and the first public-private key pair can be arbitrarily combined, and this application does not impose any restrictions on this.

[0281] It should also be understood that the seed parameters exemplified above are defined only to distinguish between the second public key and / or the second private key used to generate the first public key and the first private key, and the first public key and / or the first private key used to generate the first identifier, and should not constitute any limitation on this application.

[0282] The first device can generate a first key credential after obtaining a first identifier and a first public-private key pair.

[0283] For example, the first device can use the first identifier as the subject ID of the first key certificate, use the first public key in the first public-private key pair as the declaration of the first key certificate, and sign it based on the first private key in the first public-private key pair to obtain the first key certificate.

[0284] It should be understood that since the first key credential can be obtained by signing the first public key and the first identifier based on the first private key, and the first public key, the first private key and the first identifier can all be obtained based on the second digital identity, it can also be said that the first key credential is obtained based on the second digital identity.

[0285] In summary, the first request message carries at least one parameter for issuing the first digital identity, including: a second identifier and a first key credential. The first key credential can be obtained by signing the first identifier and the first public key with the first private key; therefore, the first key credential contains the first identifier and the first public key. Thus, it can also be said that the first request message carries at least one parameter for issuing the first digital identity, including: a second identifier, a first identifier, a first public key, and a first key credential.

[0286] It should be understood that the first device generating the first key certificate based on the first identifier and the first public-private key pair does not mean that the first device generates the first key certificate based solely on the first identifier and the first public-private key pair.

[0287] As illustrated above with reference to Figure 4, the key credential may include one or more of the following information: subject ID, claim, domain identifier, issuer ID, validity period or purpose, and a signature of the aforementioned information. In addition to the subject and claim mentioned above, the first device may also determine one or more of the following: the domain identifier, issuer ID, validity period, or purpose of the first key credential. The domain identifier of the first key credential may be the first DL, indicated by the identifier of the first DL; it may also be other scopes, such as an operator network, indicated by the identifier of the PLMN, etc., without limitation. In this embodiment, the first key credential is generated by the first device, therefore the issuer ID of the first key credential may be the identifier of the first device. The validity period of the first key credential may be determined by the issuer of the first key credential (i.e., the first device), for example, it may be a time length; it may be a time period, etc., without limitation. The purpose of the first key credential may be authentication.

[0288] The first device can generate information of the first key certificate according to the above items. Optionally, the first device can also sign the information of the first key certificate based on the first private key to obtain the first key certificate.

[0289] Figure 7 is a schematic diagram of the first key credential. Figure 7 uses KC2 as an example to illustrate a possible example of the first key credential. The first key credential shown in Figure 7 is a KC2 obtained by DLE0 (i.e., an example of the first device) based on the information described above. Wherein, Domain ID indicates DL2 ID, indicating that the scope of use of KC2 is DL2. Validity indicates T2, indicating that the validity period of the first key credential is T2, which can be a time length. Issuer ID indicates DLE0 ID, indicating that the issuer of this KC2 is DLE0, i.e., an example of the first device. Subject ID indicates ID2, indicating that the identifier of the subject of this KC2 is ID2. Claims indicates PK2, indicating that the claims of this KC2 are PK2, i.e., an example of the first public key. Usage indicates authentication, indicating that this KC2 is used for authentication. Sig DLE0 This indicates that it is obtained by DLE0 signing other information in the first key certificate based on the first private key. It should be understood that this Sig... DLE0 It is obtained based on the signature of the first private key, and therefore is an optional field in the first key credential shown in Figure 7.

[0290] The first key credential, as a key credential, can represent that the first public key is sent to the verifier for authentication. In this embodiment, since the first key credential is obtained by signing based on the private key (i.e., the first private key) of the first device, it can also be said that the first key credential is a credential issued by the first device itself, or that the first key credential is a credential endorsed by the first device.

[0291] Optionally, the at least one parameter may also include the identifier of the first DL.

[0292] Since the second DL is the DL that the first device wants to add, the first device can carry the identifier of the first DL in the first request message so that the fourth device that receives the first request message can determine the DL that the first device needs to add.

[0293] As previously stated, the fourth device may correspond to a node in the network of the second DL, and may establish trust with nodes in one or more DL networks in order to communicate with nodes in one or more other DL networks.

[0294] If the fourth device is simultaneously connected to the third device in the network of the first DL and devices in the networks of other DLs, the fourth device can determine that the first device needs to join the first DL based on the identifier of the first DL carried in the first request message.

[0295] If the fourth device is not connected to any other device in the network of the first DL besides the third device in the first DL's network, the fourth device can determine that the first device needs to join the first DL even if the first request message does not carry the identifier of the first DL. In other words, the first request message does not necessarily carry the identifier of the first DL.

[0296] In this embodiment, the identifier of the first DL can also be used to generate the first digital identity, for example, as a domain identifier in the first digital identity, or as a domain identifier used to determine the first digital identity. It should be understood that when the domain identifier of the first key credential contains the identifier of the first DL, or indicates the identifier of the first DL, the first request message can also be said to carry the identifier of the first DL.

[0297] Optionally, the first request message may also carry information for generating the first identifier and information for generating the first public key.

[0298] The first device may also carry the information for generating the first identifier and the information for generating the first public key in the first request message and send them to the fourth device so that the fourth device can verify the first identifier and the first public key from the first device to determine that the first key credential from the first device is valid.

[0299] The information used to generate the first identifier includes the identifier of the algorithm used to generate the first identifier and the parameters used to generate the first identifier. The parameters used to generate the first identifier include one or more of the following: a second identifier, a first public key, the identifier of the first deep layer, a random number, a block hash, blockchain time, or a MAC address. Since the first identifier can be obtained from the public key, the parameters used to generate the first identifier are optional.

[0300] The information used to generate the first public key includes an identifier for the algorithm used to generate the first public key and parameters used to generate the first public key. The parameters used to generate the first public key include one or more of the following: a second public key, and optionally one or more of the following: a random number, a block hash, a blockchain time, or a MAC address. Parameters used to generate the first identifier.

[0301] Therefore, the first request message may optionally include at least one parameter for publishing the first digital identity, as well as one or more of the following: the identifier of the first DL, a random number, a block hash, a blockchain time, or a MAC address. The block hash and blockchain time may also be obtained by the fourth device itself. Therefore, the first request message may also omit the block hash and blockchain time.

[0302] Optionally, before step 601', the method further includes 601": the first device determines that the algorithm used to generate the identifier in the network of the first DL is the same as the algorithm used to generate the identifier in the network of the second DL.

[0303] When the first device determines that a new deep learning (DL) network needs to be added, such as when adding the first DL network from the second DL network, it can determine the generator of the first identifier based on whether the algorithms used to generate the identifier are the same in the two DL networks. For example, if the algorithms used to generate the identifier are the same in the two DL networks, the first identifier can be generated by a device in the second DL network; if the algorithms used to generate the identifier are different in the two DL networks, the first identifier can be generated by a device in the first DL network.

[0304] Since different DL networks do not share the algorithms used to generate identifiers within their respective ledgers, when the algorithm used to generate identifiers (such as the second identifier) ​​in the second DL network differs from the algorithm used to generate identifiers (such as the first identifier) ​​in the first DL network, the generator of the first identifier can be a device in the first DL network. When the algorithm used to generate identifiers (such as the second identifier) ​​in the second DL network is the same as the algorithm used to generate identifiers (such as the first identifier) ​​in the first DL network, the generator of the first identifier can be a device in the first DL network, or it can be a device in the second DL network, such as the first device itself, or other devices in the second DL network, such as the fourth device, or it can be a core network element used to store the digital identity and credentials of the first device, such as the second device.

[0305] In this embodiment, it is assumed that the algorithm used to generate the identifier in the second DL network is the same as the algorithm used to generate the identifier in the first DL network, so the first device can generate the first identifier on its own.

[0306] It should be noted that in some scenarios, the identification algorithm can be represented by the identification format. For example, one possible type of digital identity is UCDID, and an example of a UCDID identifier is as follows:

[0307] ID = UCDID:method:xxxxxxxx.

[0308] The "UCDID" field is fixed and indicates that the identifier is a UCDID. The "xxxxxxxx" field is a globally unique identifier, or PK. The "method" field can be the algorithm of the identifier or the identifier of the algorithm. In other words, the identifier is generated based on the algorithm indicated by the "method" field.

[0309] Therefore, the algorithms used to generate identifiers are the same in the two DL networks, that is, the identifier formats are the same in the two DL networks. Therefore, step 601" can also be replaced by the first device determining that the ID in the second device's network has the same format as the ID in the first device's network.

[0310] It should be noted that the algorithms used to generate identifiers in different DL networks can be subscription data obtained from the operator when the first device signs a contract with the operator. Therefore, the first device can determine in advance whether the algorithms used to generate identifiers in the first DL network and the second DL network are the same.

[0311] It should be understood that the basis for the first device to determine the generator of the first identifier is not limited to whether the algorithms used to generate the ID are the same in the two DL networks. For example, it can also determine the generator of the first identifier based on network architecture, standards, etc. Therefore, step 601 is an optional step, and the first device can also determine the generator of the first identifier based on network architecture, standards, etc.

[0312] It should also be understood that since the first key credential can be obtained by signing the first identifier and the first public key based on the first private key, step 601 can also be understood as a possible way for the first device to determine the generator of the first key credential.

[0313] Optionally, prior to step 601, the method further includes: the first device determining the Internet Protocol (IP) address of the fourth device.

[0314] The first device can determine which device to send the first request message to based on the first DL to be added.

[0315] In some architectures, the fourth device and the third device are separate, and they can establish trust through the SEPP (Security Provider Protocol) of each operator. In one possible implementation, the first device can query node information in the network of the second DL (Digital Node). This node information in the second DL network can indicate the network of the DL to which each node belongs, the connected nodes, IP addresses, and other information. Based on this node information, the first device can determine that the fourth device is connected to the SEPP, and thus can determine to send the first request message to the fourth device, thereby obtaining the IP address of the fourth device.

[0316] In other architectures, the fourth device and the third device are co-located, forming a single entity, such as DLE2. In this case, other methods can also be used to determine which node to send the first request message to. For example, in one possible implementation, the first device can query the node list of the second DL's network. Based on the node list of the second DL's network, it can determine that DLE2 belongs to the first DL's network, and thus determine to send the first request message to DLE2. In another possible implementation, the first device can invoke a smart contract to query the second DL's network for devices whose digital identity domain identifier contains the first DL ID. By querying, it can determine that DLE2 belongs to both the second DL and the first DL, and thus determine to send the first request message to DLE2, thereby obtaining DLE2's IP address.

[0317] After determining that the first device will send the first request message to the fourth device (or DLE2), the first device can send the first request message according to the IP address of the fourth device (or DLE2).

[0318] If the first device cannot determine which device to send the first request message to, it may also send the first request message to the device it is connected to. For example, if the first device is a terminal, it may send the first request message to the RAN node it is connected to. Assume that the RAN node also belongs to the network of the second DL, for example, it can be denoted as DLE1. DLE1 can determine whether to send the cross-ledger request to the fourth device (or DLE2) and send the first request message through the various possible implementations provided above.

[0319] In other words, step 601 can be replaced by the following steps, or implemented through the following steps: the first device sends a first request message to DLE1; DLE1 determines the fourth device (or DLE2); DLE1 forwards the first request message to the fourth device (or DLE2).

[0320] If the RAN node does not belong to the network of the second DL, the RAN node may also send the first request message to other devices it is connected to until it determines which device to send the first request message to and forwards it to that device.

[0321] To illustrate the operation of each device more clearly, the following text will first use the separate architecture of the third and fourth devices as an example to describe the steps performed by each device, and then explain the possible changes in each step when the third and fourth devices are combined.

[0322] In step 602, the fourth device obtains information from the second digital identity based on the second identifier.

[0323] After receiving the first request message, the fourth device can determine that the first device needs to publish a digital identity across ledgers. Specifically, publishing a digital identity across ledgers can mean generating a digital identity (such as the first digital identity in this embodiment) across ledgers and publishing the generated digital identity in the newly added ledger.

[0324] The fourth device may, in response to the received first request message, obtain information from the second digital identity for use in generating the first digital identity.

[0325] The fourth device can correspond to a node in the second DL. Therefore, the fourth device can search for data in the second DL to obtain information from the second digital identity. Specifically, since the second identifier can be used to identify the second digital identity in the second DL, the fourth device can use the second identifier as an index to search for the second digital identity in the second DL in order to obtain information from the second digital identity. The information in the second digital identity can be used to generate the first digital identity.

[0326] The information in the second digital identity can be determined based on the second digital identity. Since cross-ledger security may pose risks, the fourth device can filter parameters obtained from the second digital identity before sending them to the third device. For example, the fourth device can filter parameters related to the second DL in the second digital identity for data minimization purposes, such as the issuer ID, domain identifier, and second key credential in the second digital identity. It is easy to see that the absence of these parameters does not affect the generation of the first digital identity; therefore, it can be said that the information in the second digital identity carries the parameters necessary for generating the first digital identity. For example, the information in the second digital identity indicates: type (i.e., the type of DLE0, such as a terminal (or UE), NF, or RAN node) and service (i.e., the service provided by the DLE0, such as a user's personal homepage or the service type of the NF).

[0327] In step 603, the fourth device sends a sixth request message to the third device. This sixth request message requests the generation of a first digital identity and carries information from a first key credential and a second digital identity used to generate the first digital identity. Correspondingly, the third device receives the sixth request message from the fourth device.

[0328] The third device can be a device in the first DL, for example, it can correspond to DLE2-b shown in Figures 3(a) and (b).

[0329] The fourth device sends the information in the first key credential and the second digital identity used to generate the first digital identity to the third device, so that the third device can use the information in the first key credential and the second digital identity carried in the sixth request message to generate and publish the first digital identity.

[0330] As previously stated, a trust is established between the third and fourth devices, allowing the fourth device to send a sixth request message to the third device. The information from the first key credential and the second digital identity carried in this sixth request message can be used to generate a first digital identity. This sixth request message can also be used to request the publication of the first digital identity in the first ledger. This sixth request message can also be referred to as a cross-ledger publication request.

[0331] Optionally, before step 603, that is, before the fourth device sends the sixth request message, the method further includes step 602': the fourth device determines that the first device is valid in the second DL. Accordingly, step 603 may be performed after the fourth device has determined that the first device is valid in the network of the second DL.

[0332] The validity of the first device within the second DL network can mean that the first device's credentials (the second key credential in the second digital identity) are valid within the second DL network. In other words, the second digital identity of the second device can be found within the second DL, and the second key credential within that second digital identity can be verified. Specifically, the verification of the second key credential can mean that the public key in the second key credential can be used to verify the signature made by the first device based on the first private key. The validity of the second device within the second DL network can also be interpreted as the second device being legitimate within the second DL network, or as the second device being authenticable within the second DL network.

[0333] The fourth device uses the second identifier as an index. If the second digital identity cannot be found in the second DL, it can be determined that the first device does not have a digital identity in the second DL network. If the second digital identity can be found in the second DL, it can further confirm whether the first device is valid in the second DL network. In one possible implementation, the fourth device can determine that the second key credential is valid in the second DL network based on the domain identifier of the second digital identity including the identifier of the second DL. Alternatively, in another implementation, the fourth device can also determine that the first device is valid in the second DL network based on the scope of use of the second key credential of the second digital identity including the identifier of the second DL. Furthermore, the fourth device can also combine the issuer information of the second key credential to determine whether the first device is valid in the second DL network. The fourth device can query the public key of the issuer of the second key credential from the second DL. If the public key of the issuer of the second key credential can be found in the second DL and the signature of the second key credential can be successfully verified using the issuer's public key, it can be determined that the first device is valid in the second DL network.

[0334] Optionally, before step 603, that is, before the fourth device sends the sixth request message, the method further includes step 602: the fourth device determines that the first device does not have a digital identity in the first DL.

[0335] The fourth device may also determine, before sending the sixth request message, that the first device does not have a digital identity in the first DL, that is, there is no digital identity for the first device that can be used in the network of the first DL. In one possible implementation, the fourth device may determine that the first device does not have a digital identity in the first DL based on the fact that the field identifier of the second digital identity does not include the identifier of the first DL, or it may determine that the field identifier of the second key credential in the second digital identity does not include the identifier of the first DL. Therefore, it can be determined that a digital identity for the first device to be used in the network of the first DL needs to be generated. In other words, step 602" can also be replaced by: the fourth device determines that a digital identity needs to be generated, or in other words, the fourth device determines that a digital identity needs to be generated across the ledger.

[0336] It should be understood that since steps 602' and 602' can both be achieved by querying information in the second digital identity, steps 602' and 602' can be achieved through one specific step or through two steps, and this application does not limit this. They are shown as two steps in this document only for ease of distinction and explanation.

[0337] The fourth device may send a sixth request message after executing step 602” to request the publication of the first digital identity in the first DL; or it may skip step 602” and send the sixth request message directly after step 602 or 602’ to request the publication of the first digital identity in the first DL. This application does not limit this.

[0338] It should also be understood that steps 604' and 602" can be executed after step 601, after step 602, or simultaneously with step 604. This application does not limit this, as long as they are executed before step 603.

[0339] Optionally, prior to step 603, the method further includes step 602: the fourth device determines that the first key credential from the first device is valid. Accordingly, step 603 may be performed after the fourth device has determined that the first key credential from the first device is valid.

[0340] As mentioned above, the first request message may also carry information for generating ID2 and information for generating key2, which the fourth device can use to generate the first identifier and the first public key to determine the validity of the first identifier and the first public key received from the first device.

[0341] It should be understood that the first identifier and first public key from the first device may specifically refer to the subject ID and claim contained in the first key credential. Therefore, the fourth device verifies whether the first identifier and first public key from the first device are valid, that is, the fourth device verifies whether the first key credential from the first device is valid.

[0342] For example, since the first key credential is obtained by signing with the private key of the first device, the fourth device can verify the signature of the first key credential based on the first public key it generates. If the verification is successful, it means that the first public key in the first key credential from the first device is consistent with the first public key generated by the fourth device, and thus it is determined that the first identifier and the first public key received from the first device are valid; if the verification fails, it is determined that the first identifier and the first public key received from the first device are invalid.

[0343] Alternatively, after the fourth device successfully verifies the signature of the first key certificate based on the self-generated first public key, it can further compare the first identifier and the first public key in the first key certificate with the self-generated first identifier and the first public key. If they match, the first identifier and the first public key received from the first device are determined to be valid; if they do not match, the first identifier and the first public key received from the first device are determined to be invalid.

[0344] Optionally, if it is determined that the first identifier and the first public key received from the first device are invalid, the fourth device may return a response message to the first device, requesting the first device to return the information used to generate the first public key, or requesting the first device to return the first public key and the first identifier; alternatively, the fourth device may also return a response message to the first device indicating that the verification of the first key credential has failed. This application does not limit this.

[0345] In step 604, the third device generates the first digital identity based on the information in the first key credential and the second digital identity.

[0346] In response to the received sixth request message, the third device can generate a first digital identity based on the information in the first key credential and the second digital identity.

[0347] The third device can use the first key credential as the key credential in the first digital identity, and fill in the parameters in the information of the second digital identity into the corresponding fields of the first digital identity to obtain the first digital identity.

[0348] For example, taking UCDID as an example, the "ID" field of the first digital identity can be the first identifier in the "Subject ID" field of the first key credential, and the "Verification Method" field of the first digital identity can be the first public key; the "Type" field of the first digital identity can be the type of information indicated in the second digital identity, and the "Service" field of the first digital identity can be filled with the service indicated by the information in the second digital identity.

[0349] As explained above in conjunction with Figure 4, a UCDID can contain more fields, such as the domain identifier, association identifier, and subject controller. The third device can fill in the corresponding information in each field according to the actual situation to obtain the first digital identity. For example, the "subject controller" field of the first digital identity can be the first identifier; the "domain identifier" field of the first digital identity can be the identifier of the first DL, or it can be other things, such as the identifier of the PLMN of the operator belonging to the first DL's network, etc., without limitation; the association identifier field of the first digital identity can be empty; and so on, without further listing.

[0350] Figure 8 is a schematic diagram of UCDID2 (i.e., an example of a first digital identity) provided in an embodiment of this application. Figure 8 shows some fields of UCDID2. The descriptions of each field of UCDID2 shown in Figure 8 can be understood by referring to the descriptions above in conjunction with Figures 4 and 7, and will not be repeated here. It is understood that KC2 in UCDID2 can be the KC2 generated and sent by DLE0, and is therefore the same as the KC2 shown above in conjunction with Figure 7. Furthermore, since this UCDID2 is obtained from UCDID1, and no other UCDID has been obtained from this UCDID2 at this time, in other words, this UCDID2 has not yet been associated with a UCDID. Therefore, the associated ID field is not shown in Figure 8. However, this does not mean that UCDID2 necessarily does not contain this field. In specific implementations, when UCDID2 is not associated with a UCDID, the associated ID field can be null.

[0351] Optionally, the method further includes step 605, in which the third device publishes the first digital identity in the first DL.

[0352] The third device can publish the generated first digital identity in the first DL so that the first digital identity can be synchronized to other devices in the network of the first DL.

[0353] As an example, this DL technology can be applied to a blockchain, where the first DL can be one blockchain and the aforementioned second DL can be another blockchain. One possible way for the third device to publish the first digital identity in the first DL is that the third device sends the first digital identity to the consensus nodes in the blockchain. The consensus nodes in the blockchain can execute a consensus algorithm based on the received first digital identity. For example, each consensus node can generate the first digital identity using the same parameters input when the third device generated the first digital identity (e.g., information from the first key credential and the second digital identity), and verify whether the generated first digital identity is the same as the first digital identity from the third device. Based on the verification result, a vote is held, and if the vote passes, the first digital identity can be stored on the blockchain, or in other words, stored in the first DL.

[0354] It should be understood that this deep learning (DL) technology is not limited to applications in blockchain. For example, DL technology can also be applied to distributed databases. In this case, a third device can publish a first digital identity in a first DL to synchronize that first digital identity to the storage nodes of each distributed database. This application includes, but is not limited to, this.

[0355] It should also be understood that the first DL is a distributed ledger, and the first digital identity is stored in the first DL, that is, the UCDID is stored in the ledger. In other words, the first digital identity can be found in the first DL. Since nodes in the first DL network can find the first digital identity by querying the ledger after storing the first digital identity, it can be said that the first digital identity exists in the first DL.

[0356] Devices in the first DL network can broadcast a synchronization completion indication message after saving the first digital identity, indicating that the synchronization of the first digital identity is complete. Since the third device is also a device in the first DL network, it can also receive the synchronization completion indication message, thereby confirming that the publication of the first digital identity in the first DL has been completed.

[0357] In step 606, the third device sends a fourth response message to the fourth device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the fourth device receives the fourth response message from the third device.

[0358] This fourth response message can be considered a response to the first request message mentioned above. This fourth response message can also be called a cross-ledger publication response, corresponding to the cross-ledger publication request example given earlier.

[0359] After the first digital identity is published in the first DL, the third device can send a fourth response message to the fourth device to indicate the publication result of the first digital identity in the first DL. For example, it can indicate that the first digital identity has been successfully published in the first DL, or that the publication was successful; or it can indicate that the first digital identity was not published in the first DL, or that the publication failed, etc., without limitation. For the sake of simplicity in explaining the process below, this document assumes that the first digital identity was successfully published in the first DL. For the sake of brevity, the explanations regarding the publication result below can be understood by referring to the explanation here, and will not be repeated here.

[0360] Optionally, the method further includes step 606': the third device sends a verification path to the fourth device, the verification path indicating the storage path of the first digital identity in the first DL. Accordingly, the fourth device receives the verification path from the third device.

[0361] The third device can obtain the verification path of the first digital identity in the first DL, and send the verification path to the first device through the fourth device, so that the first device can verify whether the first digital identity is stored in the first DL based on the verification path.

[0362] In one possible design, the verification path can be carried in the fourth response message. In this case, for the third device, steps 606 and 606' can be combined into a sending step; for the fourth device, steps 606 and 606' can be combined into a receiving step.

[0363] Optionally, the method further includes step 607: the fourth device updates the second digital identity.

[0364] After receiving the fourth response message from the third device, the fourth device can update the second digital identity in the second DL. In this embodiment, since the first digital identity is obtained based on the second digital identity, more specifically, some parameters in the first digital identity come from information in the second digital identity, and some parameters in the first digital identity are generated based on parameters in the second digital identity, such as the first public key, etc. Therefore, the first digital identity can be said to be derived from the second digital identity. The second digital identity can be called the root digital identity of the first digital identity, and the first digital identity can be called a sub-digital identity or associated digital identity of the second digital identity. Therefore, the fourth device can update the second digital identity, for example, by adding an "Association ID" field to the second digital identity and filling the first identifier of the first digital identity into this field; or, for example, by adding the first identifier of the newly associated first digital identity to the "Association ID" field of the second digital identity. In other words, the updated second digital identity contains the first identifier of the first digital identity. It should be understood that the "Association ID" field exemplified above is only an example, and this application does not limit the names of the various fields in the digital identity, nor does it limit how the first digital identity and the second digital identity are associated.

[0365] Figure 9 is a schematic diagram of the second digital identity before and after the update provided in the embodiments of this application. Figure 9 uses UCDID as an example of digital identity. UCDID1 shown in Figure 9(a) is the second digital identity before the update, and UCDID1 shown in Figure 9(b) is the second digital identity after the update. By comparison, it can be seen that in the updated UCDID1, the associated ID field is filled with ID2, that is, UCDID2 is the associated UCDID of UCDID1. For the understanding of the other fields of UCDID1, please refer to the description of UCDID2 in conjunction with Figure 8 above, which will not be repeated here.

[0366] Optionally, the method further includes: a fourth device storing the correspondence between the first digital identity and the identifier of the first DL.

[0367] The fourth device can maintain mapping information between digital identities and DL identifiers. This mapping information can include a correspondence between at least one digital identity and at least one DL identifier, and can be used to indicate the DL corresponding to each digital identity. In other words, each digital identity in the mapping information has been published in the DL identified by the identifier of the corresponding DL. Therefore, the digital identity can be used in the DL identified by the identifier of the corresponding DL.

[0368] Since the domain identifier in a digital identity may indicate the scope of use of a DL identifier, a PLMN identifier, or other identifiers, it does not necessarily directly reflect the correspondence between the digital identity and the DL identifier. Therefore, the fourth device can maintain this mapping information to record the correspondence between the digital identity and the DL identifier more directly. In this way, when a device in the second DL network needs to cross ledgers, it can quickly determine whether the device has a digital identity in the DL it needs to join by querying this mapping information, that is, it can quickly determine whether a new digital identity needs to be generated.

[0369] In step 608, the fourth device sends a first response message to the first device, the first response message indicating the publication result of the first digital identity in the first DL. Accordingly, the first device receives the first response message from the fourth device.

[0370] Upon receiving the fourth response message, the fourth device can indicate to the first device via a first response message that the first digital identity has been published in the first DL. This first response message can be considered a response to the first request message in step 602. Corresponding to the cross-ledger request exemplified above, this first response message can also be called a cross-ledger response.

[0371] Optionally, the method further includes step 608': the fourth device sends a verification path to the first device. Accordingly, the first device receives the verification path from the fourth device.

[0372] In one possible design, the verification path can be carried in the first response message. In this case, for the fourth device, steps 608 and 608' can be combined into a sending step; for the first device, steps 608 and 608' can be combined into a receiving step.

[0373] Optionally, the method further includes step 608: the first device determines, based on the verification path, that the first digital identity is stored in the first DL.

[0374] For example, step 608 may specifically include: the first device obtaining the first digital identity; the first device determining, based on the verification path, that the first digital identity is stored in the first DL.

[0375] For example, the first device may not have permission to query ledger data in the first DL. Therefore, the first device can generate the first digital identity based on the first key credential generated in step 601'.

[0376] For example, the first device may also have permission to query ledger data in the first DL. Therefore, the first device can obtain the first digital identity from the first DL.

[0377] After obtaining the first digital identity, the first device can calculate the hash of the generated first digital identity. If it is a transaction on the first DL, then this hash should be equal to the hash value of the data block placed in a leaf node at the bottom of the Merkle tree, such as H. K .

[0378] Using this hash value H K The hash value H of adjacent nodes L The hash value H can be obtained by calculation. KL ; Using H KL Continue with H IJ The hash value H can be obtained by calculation. IJKL ; Using H IJKL and H MNOP The hash value H is calculated. IJKMNOP ; Using H IJKMNOP and H ABCDEFGH The hash value H is calculated. ABCDEFGHIJKLMNOP If the first digital identity indicated by the verification path is authentic in the storage path of the first DL, then the hash value H calculated above is true. ABCDEFGHIJKLMNOP It should be equal to the hash value of the Merkle root (referred to as the root hash). In other words, if H ABCDEFGHIJKLMNOP If the result is equal to the root hash, it proves that the first digital identity is indeed in the storage path indicated by the verification path, that is, the first digital identity is guaranteed to exist on the first DL.

[0379] It should be understood that since the first digital identity is stored on the first DL, nodes in the network of the first DL can obtain the first digital identity by querying the ledger data in the first DL. Therefore, confirming that the first digital identity is indeed stored on the first DL can also confirm that the first digital identity has been published in the first DL.

[0380] Optionally, the method further includes step 609: the first device updates the second digital identity.

[0381] It should be understood that the process of updating the second digital identity by the first device and the second digital identity by the fourth device is the same. Please refer to the relevant explanation above regarding the fourth device updating the second digital identity, which will not be repeated here.

[0382] Optionally, the method further includes step 610: the first device stores the first digital identity.

[0383] In addition to updating the second digital identity, the first device can also save the first digital identity. In this way, the first device can directly use the first digital identity the next time it needs to join the network of the first DL, without having to generate a new digital identity for publication in the first DL.

[0384] Optionally, the method further includes: the first device storing the correspondence between the first digital identity and the first DL.

[0385] Similar to the fourth device, the first device can also maintain the mapping relationship information between the digital identity and the DL identifier. The process by which the first device saves the correspondence between the first digital identity and the first DL is the same as that of the fourth device, and can be referred to the relevant explanation above regarding the fourth device saving the correspondence between the first digital identity and the first DL, which will not be repeated here.

[0386] It should be noted that in this embodiment, the third device and the fourth device are two devices defined from a functional perspective. In actual deployment, the third device and the fourth device can be installed together or separately, and this application does not limit this. When the third device and the fourth device are installed together, the communication between the third device and the fourth device mentioned above can be regarded as internal communication of the device. For example, steps 603, 606, and 606' can be regarded as internal communication of the device; the operations performed by the third device and the fourth device can be regarded as operations performed by the same device. For example, steps 601, 602, 602', 602", 602"', 604, 607, 608, and 608' can be regarded as operations performed by the same device.

[0387] Based on the above scheme, when the first device needs to join the network of the first DL, it can generate a first public key and a first private key based on the second public key and / or the second private key. Then, it signs the first public key with the first private key to obtain a first key credential. This first key credential is then forwarded to a third device in the first DL network through a fourth device in the second DL network that has established trust with the first DL network. The fourth device can then generate a first digital identity for publication in the first DL based on the received first key credential and information from the second digital identity obtained from the second digital identity. This enables cross-ledger publication of digital identities between different DL networks, thereby achieving cross-ledger authentication of the first device. The authentication of digital identities is no longer limited to the same DL network.

[0388] The specific flow of the communication method provided in this application when the first key credential is generated by the first device, as detailed above with reference to Figures 6 to 9, is also described in detail. In another implementation, the first key credential can also be generated by other nodes, such as the second or fifth device corresponding to the IDM. It should be understood that whether the first key credential is generated by the first device or the second device can be configured by the operator, or it can be defined by the standard, or it can be selected by the first device according to a pre-configured strategy; this application does not limit this.

[0389] The specific flow of the communication method provided in this application when the second device generates the first key credential will be described below with reference to Figures 10, 12A and 12B.

[0390] In methods 900, 1000, and 1400 illustrated below, since the first key credential obtained by the second device signing needs to be used in the network of the first DL—that is, nodes in the first DL network need to be able to verify that the first key credential was issued by a legitimate issuer—the public key of the second device should be obtainable by devices in the first DL network. This could be achieved, for example, by pre-installing it in the first DL network or obtaining it from other devices (e.g., SEPP). This application provides several possible implementations.

[0391] One possible implementation is that the data of the first DL can be stored in the world state or on a blockchain, and the public key of IDM1 can be stored in the world state or on the blockchain in the form of a mapping between IDM1 ID and public key. Devices in the first DL network can obtain the public key corresponding to the IDM1 ID by querying the IDM1 ID.

[0392] Another possible implementation is that devices in both the first and second DL networks can have their key credentials issued by IDM1. Therefore, devices in both networks store IDM1's public key and can verify IDM1's signatures. In other words, devices in both networks fall under IDM1's management scope. Alternatively, the IDM in the second DL network (e.g., IDM1) and the IDM in the first DL network (e.g., IDM2) are the same IDM; that is, IDM1 and IDM2 are co-located.

[0393] Another possible implementation is that the IDM in the second DL network (e.g., IDM1) and the IDM in the first DL network (e.g., IDM2) are separate, but a trust is established between them. Devices in the first DL network can verify the signature of IDM1 through IDM2. One possible way for IDM1 and IDM2 to establish trust is through cooperation between the two operators, or by IDM1 and IDM2 belonging to different subnets of the same operator, for example, by each having the other's public key pre-configured, or by establishing trust through SEPP in a roaming architecture. Another possible way for IDM1 and IDM2 to establish trust is that all IDMs establish an identity chain, so that IDMs can authenticate each other.

[0394] To facilitate understanding and explanation, the communication method provided in this application will first be described from the perspective of the second device with reference to Figure 10, and then the specific implementation process of the communication method will be described from the perspective of interaction with reference to Figures 12A and 12B.

[0395] Figure 10 is another schematic flowchart of the communication method provided in an embodiment of this application. The method 900 shown in Figure 10 will be described in detail below.

[0396] In step 910, the second device receives a third request message from the first device, the third request message carrying the identifier of the first DL, the first DL being the DL for which the first device will issue the first digital identity.

[0397] The first device is the device that will publish the first digital identity across ledgers, for example, it may correspond to DLE0 shown in Figures 3(a) and (b). In this embodiment, the first device holds a second digital identity that has been published in the second DL and will publish the first digital identity in the first DL. Therefore, the aforementioned cross-ledger publication may specifically refer to publication from the second DL to the first DL.

[0398] The second device can correspond to a network element in the core network that can be used to manage digital identity, such as IDM1 shown in Figures 3(a) and (b). In this embodiment, the first key credential in the first digital identity can be issued by the second device. In other words, the first key credential can be obtained by signing the private key of the second device.

[0399] In this embodiment, the first device can request the second device to issue a first key credential, or in other words, generate a first key credential, by sending a third request message to the second device. This third request message can be, for example, the first request message in method 1000 below (e.g., also known as a cross-ledger request), or the second request message in method 1400 (e.g., also known as a derivative request).

[0400] The third request message may carry an identifier of the first DL. The identifier of the first DL can be used to indicate the DL that the first device wants to join. The second device can determine that the first device wants to join the first DL based on the identifier of the first DL carried in the third request message.

[0401] In step 920, the second device generates the first key credential.

[0402] The second device can generate a first key credential in response to the third request message.

[0403] In this embodiment, the first key credential can be a credential issued by the second device to the first device, that is, the second device can obtain the first key credential based on its own private key signature.

[0404] In one possible design, the first key credential is a certificate issued for a symmetric key (such as the first key), which can be obtained by signing instruction information of the first key. This first key can be used for authentication of the first device in the first DL's network. This first key can also be generated based on a second key, which is also a symmetric key and can be used for authentication of the first device in the second DL's network.

[0405] Optionally, step 920 may specifically include: the second device obtaining a second key; the second device generating a first key based on the second key and an algorithm used to generate the first key; and the second device signing the instruction information of the first key based on its private key to obtain a first key credential. The first key can be used for authentication of the first device in the first DL's network. The second key can be used for authentication of the first device in the second DL's network.

[0406] In one possible implementation, the second public key and / or the second private key are obtained locally by the second device. Since the second device can pre-store the correspondence between the identifiers and keys of devices in the network generated by it in the second DL, the second device can obtain the second key by querying the local identifier-key correspondence after receiving the third request message. The algorithm used to generate the first key can be indicated by the first device through the third request message; therefore, optionally, the third request message also carries the identifier of the algorithm used to generate the first key.

[0407] If the first key is a symmetric key, there can be multiple algorithms for generating the first key.

[0408] For example, the algorithm can be an XOR operation. The second device can perform an XOR operation on the second key to obtain the first key.

[0409] For example, the algorithm may include SHA, such as SHA256. The second device can concatenate the second key with the identifier of the first DL and then obtain the first key through SHA256.

[0410] For example, the algorithm may include HMAC, such as HMAC-SHA512. The second device can calculate the first key using a preset seed parameter for generating the first key. This seed parameter can be any string, such as a block hash, blockchain time, etc., without limitation.

[0411] For example, the algorithm may also include some existing key derivation protocols, such as BIP32. This application includes, but is not limited to, these.

[0412] In another possible design, the first key credential is a certificate issued for the public key (such as a first public key) in an asymmetric key pair. The first key credential is obtained by signing the first public key with the private key of the second device. The first public key is the public key in a first public-private key pair, which also includes a first private key. This first public-private key pair can be used for authentication of the first device in the first DL network. The first public-private key pair can be generated based on a second key, which can be one or more components of a second public-private key pair, such as including both a second public key and a second private key, or simply the second public key. This second public-private key pair can be used for authentication of the first device in the second DL network.

[0413] Optionally, step 920 may specifically include: the second device obtaining the first public key; the second device signing the first public key based on its private key to obtain a first key credential. The first public key can be used for authentication by the first device within the network of the first DL.

[0414] One possible implementation for the second device to obtain the first public key is that the second device obtains the first public key from a third request message. Accordingly, the third request message may optionally carry the first public key.

[0415] Another possible implementation of the second device obtaining the first public key is that the second device generates the first public key itself. That is, the second device obtaining the first public key may specifically include: the second device obtaining a second public key and / or a second private key, and the second device generating the first public key and the first private key based on the second public key and / or the second private key, and an algorithm used to generate the first key.

[0416] The second device obtains the second public key and / or the second private key in the following ways:

[0417] In one possible implementation, the second public key and / or the second private key are obtained locally by the second device. Since the second device can pre-store the correspondence between the identifiers and keys of devices in the network of the second DL generated by it, the second device can obtain the second public key and / or the second private key by querying the local identifier-key correspondence after receiving the third request message. The algorithm used to generate the first key can be indicated by the first device through the third request message; therefore, optionally, the third request message also carries the identifier of the algorithm used to generate the first key.

[0418] In another possible implementation, the second public key is received by the second device from the first device; in other words, the first device sends the second public key to the second device. Accordingly, the second public key may optionally be carried in the third request message. In this case, the second device obtaining the second public key and / or the second private key includes: the second device obtaining the second public key; the second device generating a first public key and a first private key based on the second public key and / or the second private key includes: the second device generating a first public key and a first private key based on the second public key.

[0419] In another possible implementation, the second public key can be obtained by the second device from the second digital identity. The second device can obtain the second digital identity by looking up the DL, and then obtain the second public key from the second digital identity.

[0420] If the first key is an asymmetric key, the algorithm used to generate the first key can be referred to the relevant description in step 601 of method 600 above, and will not be repeated here.

[0421] It should be noted that, for security reasons, the first device will not send its private key or symmetric key to the second device. Therefore, in the two different designs described above, due to the different second keys, the second device obtains the second key in different ways, the second key obtained by the second device is also different, the object signed by the second device when generating the first key certificate is also different, that is, the content contained in the first key certificate is also different. If the first key is a symmetric key, the first key certificate may contain indication information of the first key. If the first key is an asymmetric key, the first key certificate may contain the first public key.

[0422] To avoid repetition, the signing of the instruction information of the first key by the second device based on the second device's private key, and the signing of the first public key based on the second device's private key, will be collectively referred to as signing the first key information based on the second device's private key. In other words, the second device obtains the first key credential based on its private key and the first key; it can also be said that the second device obtains the first key credential by signing the first key information based on its private key.

[0423] In summary, regardless of whether it's a symmetric or asymmetric key, the first key can be generated based on the second key. This second key is used for authentication of the first device within the first DL network and can be used to generate the second key credential in the second digital identity. Therefore, it can be said that the first key can be obtained based on the second digital identity.

[0424] Furthermore, the first key credential can also be obtained by signing the first identifier and the first key information based on the private key of the second device. The first identifier is used to identify the first device in the first DL, or in other words, the first identifier is used to identify the first digital identity in the first DL.

[0425] Optionally, step 920 may specifically include: the second device obtaining the second key; the second device generating the first key based on the second key and an algorithm for generating the first key; the second device generating the first identifier based on parameters and an algorithm for generating the first identifier; and the second device signing the first identifier and the first key information based on the private key of the second device to obtain the first key credential.

[0426] The parameters used to generate the first identifier may include one or more of the following: a second identifier, a first key, an identifier of the first DL, a timestamp, a MAC address, a random number, a block hash, and a blockchain time. The second identifier may be sent from the first device to the second device, the first key may be generated by the first device based on the second key and an algorithm used to generate the first key, and the timestamp, MAC address, random number, block hash, and blockchain time may be sent from the first device to the second device or obtained by the second device itself. Therefore, optionally, the third request message may also carry one or more of the following: a second identifier, an identifier of the algorithm used to generate the first identifier, a first public key, an identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, or a blockchain time. The first key may also be generated by the second device, and the block hash and blockchain time may also be obtained by the second device itself; therefore, the third request message may not carry the first key, block hash, or blockchain time.

[0427] There are various algorithms that can be used to generate the first identifier. For example, ID2 can be generated based on current UUID generation methods, such as timestamps, medium access control (MAC) addresses, random numbers, or block hashes and blockchain timestamps. Another example is generating the first identifier based on the first public key. This could be done by directly using the first public key as the first identifier, or by appending the first public key to the "method" field of the first identifier, thus making the first public key a part of the first identifier.

[0428] Furthermore, the first key credential also includes the identifier of the first DL. The second device, based on its private key, signs the first identifier and the first key information to obtain the first key credential, which may include: the second device signing the first identifier, the first key information, and the identifier of the first DL based on its private key to obtain the first key credential.

[0429] In summary, the third request message can carry one or more of the following parameters in addition to the identifier of the first DL: the identifier of the first DL, the second identifier, the identifier of the algorithm used to generate the first identifier, the first public key, the second public key, the identifier of the algorithm used to generate the first key, the timestamp, the MAC address of the first device, the random number, the block hash, or the blockchain time.

[0430] After obtaining the above parameters, the second device can generate the first key credential. The specific process of the second device generating the first key credential can be referred to the specific process of the first device generating the first key credential in method 600 above, and will not be repeated here.

[0431] Figure 11 is another schematic diagram of the first key credential provided in the embodiments of this application. Figure 11 still uses KC2 as an example, showing another possible example of the first key credential. Comparing it with Figure 7, it can be found that the difference between the KC2 shown in Figure 11 and the KC2 shown in Figure 7 is that the Issuer ID shown in Figure 11 indicates the IDM1 ID, indicating that the issuer of the KC2 is IDM1, that is, an example of the second device. Since the KC2 is obtained by IDM1 signing other information in the KC2 based on its own private key, the signature is correspondingly represented as Sig. IDM1 Furthermore, since the first key in this embodiment can be either a symmetric key or an asymmetric key, Claims can indicate the indication information of the symmetric key, such as K2', or it can indicate the first public key in the asymmetric key, such as PK2. Other fields are the same as in Figure 7; please refer to step 601' of method 600 above for the explanation of KC2 in conjunction with Figure 7, and will not be repeated here. It is understood that since the issuer identifier of KC2 is the identifier of IDM1, in the subsequent verification process, the issuer information, such as IDM1's public key certificate, can be found through this issuer identifier.

[0432] In another implementation, the first device may send the first identifier, the first key (specifically, the first public key), and the identifier of the first DL used to generate the first key credential to the second device via a third request message. The second device can then sign the credential based on its own private key. Optionally, the third request message may also carry the first public key and, optionally, the first identifier.

[0433] In step 930, the second device sends the first key credential to the first device.

[0434] The second device can send the generated first key credential to the first device so that the first device can use the first key credential when subsequently accessing the first DL. For example, the second device can send the first key credential directly to the first device after generating it; or, for another example, the second device can send the first key credential to the first device after the first digital identity is published in the first DL. This application does not limit this.

[0435] In one possible design, the second device is neither a device in the second DL network nor a device in the first DL network. After the second device sends the generated first key credential to the first device, the first device can send it to a fourth device in the second DL network, which then forwards it to a third device so that the third device can generate a first digital identity based on it.

[0436] In another possible design, the second device is a device in the network of a second DL. Optionally, the method further includes: the second device sending the first key credential to a third device in the network of the first DL.

[0437] The second device can send the generated first key credential to a third device in the network of the first DL, so that the third device can generate a first digital identity based on it. The second device can send it directly to the third device, or it can forward it to the third device through other devices in the network of the second DL (such as a fourth device that has established trust with the third device), without limitation.

[0438] Optionally, the method further includes: the second device receiving a second response message from a fourth device in the network of the second DL, the second response message being used to indicate the publication result of the first digital identity in the first DL.

[0439] The fourth device is a device in the network of the second DL, for example, it may correspond to DLE2-a shown in (a) and (b) of Figure 3.

[0440] Optionally, the method further includes: the second device sending a first response message to the first device, the first response message being used to indicate the publication result of the first digital identity in the first DL.

[0441] The second device can receive a second response message from the fourth device indicating the publication result of the first digital identity in the first DL, and can send the publication result to the first device via a first response message. This publication result may, for example, indicate successful or failed publication.

[0442] Optionally, the method further includes: the second device receiving an authentication path from a fourth device in the network of the second DL, the authentication path indicating the storage path of the first digital identity in the first DL; and the second device sending the authentication path to the first device.

[0443] The second device can forward the verification path received from the fourth device to the first device, so that the first device can verify whether the first digital identity exists in the first DL.

[0444] In one possible design, the verification path received by the second device from the fourth device can be carried in the second response message, and the verification path sent by the second device to the first device can be carried in the first response message. In this case, for the second device, receiving the second response message and receiving the verification path can be combined into one receiving step, and sending the first response message and sending the verification path can be combined into one sending step; for the first device, receiving the first response message and receiving the verification path can be combined into one receiving step.

[0445] Based on the above scheme, the second device can respond to a third request message from the first device and determine, based on the identifier of the first DL carried therein, that the first device needs to issue a digital identity across the ledger. Since the IDM1 corresponding to the second device represents the operator, the second device can issue a first key credential to the first device, and the first key credential issued by the second device has higher credibility. Furthermore, the second device performs identity derivation and verification functions, while the first device performs DL-related functions, making the functional division clearer and reducing the computational resource consumption of the first device in performing identity derivation and verification, thus releasing the first device's DLE capabilities.

[0446] Figures 12A and 12B are flowcharts based on the method shown in Figure 10, illustrating the issuance process of the first digital identity in the first DL when the second device is a device in the network of the first DL, and when the second device is not a device in the network of the DL. Explanations of terms such as first device, second device, fourth device, first digital identity, and first key credential in the methods shown in Figures 12A and 12B can be found in the relevant descriptions in the method 900 above in conjunction with Figure 10, and will not be repeated here.

[0447] Figure 12A is a schematic flowchart of a communication method 1000 provided in another embodiment of this application. In the method 1000 shown in Figure 12A, the second device is a device in the network of the second DL, and the public key of the second device can be obtained by a device in the network of the first DL. The various steps in Figure 12A are described in detail below.

[0448] In step 1001, the first device sends a first request message to the second device, the first request message carrying at least one parameter, a second identifier, for publishing the first digital identity of the first device in the first DL, and an identifier of the first DL. Accordingly, the second device receives the first request message from the first device.

[0449] Since the first request message is used to request the publication of the digital identity of the first device in the first DL, and the first device has already published the second digital identity in the second DL, the first request message is used to request the publication of the first digital identity across ledgers, and the first request message can also be called a cross-ledger request.

[0450] As an example, this DL technology can be applied to a blockchain, where the second DL can be one blockchain and the first DL can be another. In this case, the cross-ledger request can also be called a cross-chain request.

[0451] In this embodiment, the at least one parameter includes a second identifier and an identifier of the first DL. In other words, the first request message carries the second identifier and the identifier of the first DL. The second identifier is obtained from the second digital identity of the first device that has been published in the second DL.

[0452] The second identifier can be used by the second device to query the ledger. Since the second device in this embodiment can be a device in the network of the second DL, it has permissions such as querying the ledger and uploading transactions. Therefore, carrying the second identifier in the first request message can facilitate the second device to obtain the second digital identity corresponding to the first device, and thus obtain the information in the second digital identity.

[0453] The identifier of the first DL can be used to identify the first DL so that the second device can determine that the received first request message is a request to join the network of the first DL. A more detailed description of the second identifier and the identifier of the first DL can be found in the detailed description of step 601 in method 600 above, and will not be repeated here.

[0454] In addition to the identifiers ID1 and the first DL mentioned above, optionally, the first request message may also include (or in other words, the first request message may also carry) an identifier of the algorithm used to generate the first key. The identifier of the algorithm used to generate the first key can be used by the second device to generate the first key. If the first key is an asymmetric key, optionally, the first request message may also carry a second public key. This second public key can be used by the second device to generate the first public key and the first private key.

[0455] Optionally, the first request message also carries parameters for generating the first identifier and an identifier for the algorithm used to generate the first identifier. The parameters for generating the first identifier and the algorithm used to generate the first identifier have been described in method 900 above, and can be referred to in the relevant description in step 920 of method 900 above, and will not be repeated here.

[0456] Optionally, before step 1001, the method further includes step 1001': the first device determines that the algorithm used to generate the second identifier in the network of the second DL is the same as the algorithm used to generate the first identifier in the network of the first DL.

[0457] For a more detailed explanation of step 1001', please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0458] In step 1002, the second device generates the first key credential.

[0459] After receiving the first request message, the second device can determine that it is necessary to generate a first digital identity across the ledger, and the first key credential contained in the first digital identity is issued by the second device. Therefore, the second device can determine that it is necessary to generate a first key credential for generating the first digital identity.

[0460] After receiving the first request message, the second device can determine that it is necessary to generate a first digital identity across the ledger, and the first key credential contained in the first digital identity is issued by the second device. Therefore, the second device can determine that it is necessary to generate a first key credential for generating the first digital identity.

[0461] In one example, the second device can obtain parameters locally for generating a first identifier and a first key, and then generate a first key credential. In this case, the first key can be a symmetric key, and the first key credential can be obtained by signing the instruction information of the first key based on the private key of the second device; or, the first key can also be an asymmetric key, including a first public key and a first private key, and the first key credential can be obtained by signing the first public key based on the private key of the second device.

[0462] In another example, the second device may also obtain information for generating the first identifier and information for generating the first key from the first request message, thereby generating the first identifier and the first key, and then generating the first key credential.

[0463] Optionally, the first request message may also carry: an identifier for the algorithm used to generate the first key and an identifier for the algorithm used to generate the first identifier. Optionally, it may also carry one or more of the following: a second public key, a second identifier, a MAC address, a random number, a block hash, or a blockchain time. That is, the second device can generate the first identifier, the first public key, and the first private key itself based on the parameters carried in the first request message. In this case, the first key includes the first public key and the first private key, and the first key credential can be obtained by signing the first public key with the private key of the second device.

[0464] In another example, the first device can directly send the first identifier and the first public key to the second device.

[0465] Optionally, the first request message also carries a first identifier and a first public key. That is, the second device can obtain the first identifier and the first public key from the first request message. In this case, the first key includes a first public key and a first private key, and the first key credential can be obtained by signing the first public key based on the private key of the second device.

[0466] Optionally, the first key credential is also obtained by signing the first key information and the first identifier based on the private key of the second device.

[0467] Therefore, the second device can also obtain the first identifier before generating the first key credential. This first identifier can be generated by the second device, or it can be sent to the second device by the first device; there is no limitation on this.

[0468] Optionally, the first key credential is also obtained by signing the first key information, the first identifier, and the identifier of the first DL based on the private key of the second device. Therefore, the second device can also obtain the identifier of the first DL from the third request message before generating the first key credential. The relationship between the first key credential and the parameters in the first request message, as well as the generation process of the first key credential, has been explained in detail in step 920 of method 900 above, which can be referred to for understanding, and will not be repeated here.

[0469] Optionally, prior to step 1002, the method further includes step 1002': the second device determines that the first device is valid in the network of the second DL.

[0470] The validity of the first device within the second DL network can mean that the credential of the first device (the second key credential in the second digital identity) is valid within the second DL network. In other words, the second digital identity of the second device can be found within the second DL, and the second key credential within that second digital identity can be verified. In this embodiment, the verification of the second key credential specifically means that the public key of the second device can be used to verify a signature based on the private key of the second device, i.e., it can be used to verify the second key credential. The validity of the second device within the second DL network can also be interpreted as the second device being legitimate within the second DL network, or the second device being authenticable within the second DL network.

[0471] Optionally, the second device can obtain the second key credential from the second DL. It can first verify the signature of the second key credential based on its private key to determine if the second key credential was issued by itself. If the second device successfully verifies the second key credential based on its public key, it can determine that the second key credential was issued by itself, and thus the first device is valid in the second DL network. If the second device fails to verify the second key credential based on its public key, it can determine that the second key credential was not issued by itself, and thus the first device is invalid in the second DL network.

[0472] For ease of explanation, this embodiment assumes that the first device is valid in the network of the second DL. Optionally, before step 1002, the method further includes step 1002", where the second device determines that the first device does not have a digital identity in the first DL.

[0473] The second device can also determine before sending the seventh request message that the first device does not have a digital identity in the first DL, that is, there is no digital identity for the first device that can be used in the network of the first DL. In one possible implementation, the fourth device can determine that the first device does not have a digital identity in the first DL based on the fact that the field identifier of the second digital identity does not include the identifier of the first DL, or based on the fact that the field identifier of the second key credential in the second digital identity does not include the identifier of the first DL. Therefore, it can be determined that a digital identity for the first device to be used in the network of the first DL needs to be generated. In other words, step 1002" can also be replaced by: the fourth device determines that a digital identity needs to be generated, or in other words, the fourth device determines that a digital identity needs to be generated across the ledger.

[0474] The specific implementation of step 1002 is the same as that of step 602 in method 600 above. Please refer to the detailed explanation above, and it will not be repeated here.

[0475] If the first key is an asymmetric key, the first device can also send the generated first public key and first identifier to the second device so that the second device can verify the first public key and first identifier from the first device based on the first public key and first identifier it generated.

[0476] Optionally, the method further includes: the first device generating a first public key, a first private key, and a first identifier. The first request message also carries the first public key and the first identifier.

[0477] The method by which the first device generates the first public key, the first private key, and the first identifier can be found in the relevant description in step 920 of method 900 above, and will not be repeated here.

[0478] The second device can compare the first public key and first identifier from the first device with its own generated first public key and first identifier. If they match, the verification is successful; if they differ, the verification fails. If the verification fails, the second device can return a response message to the first device, requesting the first device to return the parameters used to generate the first public key and the identifier of the algorithm used to generate the first public key, or requesting the first device to return the first public key and the first identifier. This application does not limit this.

[0479] In step 1003, the second device sends the first key credential to the first device.

[0480] The second device sends the generated first key credential to the first device so that the first device can use the first key credential when it subsequently accesses the first DL.

[0481] In step 1004, the second device sends a seventh request message to the fourth device, the seventh request message carrying a second identifier and a first key credential. Correspondingly, the fourth device receives the seventh request message from the second device.

[0482] This seventh request message can be called, for example, a ledger update request.

[0483] The second identifier can be used to identify the first device in the second DL, or in other words, it can be used to identify the second digital identity in the second DL. The first key credential can be used to generate the first digital identity. Optionally, the first request message also carries the identifier of the first DL. The identifier of the first DL can be used to identify the DL to be joined, and the fourth device can determine, based on the identifier of the first DL, that the seventh request message requests an update of the first DL. A more detailed explanation of the identifier of the first DL can be found in the detailed description of step 601 in method 600 above, and will not be repeated here.

[0484] It should be understood that since the field identifier of the first key credential may indicate the identifier of the first DL, when the field identifier of the first key credential indicates the identifier of the first DL, it can also be said that the ledger update request carries the identifier of the first DL.

[0485] Optionally, prior to step 1004, the method further includes: the second device determining the IP address of the fourth device.

[0486] In this embodiment, the second device is a device in the network of the second DL. Therefore, the second device can query the node information in the network of the second DL, and then determine that the fourth device is a node connected to SEPP based on the node information in the network of the second DL. Therefore, it can determine to send the seventh request message to the fourth device, and then obtain the IP address of the fourth device.

[0487] In step 1005, the fourth device obtains information from the second digital identity based on the second identifier.

[0488] The fourth device can retrieve the second digital identity from the second DL based on the second identifier, and then obtain the information in the second digital identity. The information in the second digital identity can be used to generate the first digital identity. A more detailed description of the information in the second digital identity can be found in the relevant description in step 602 of method 600 above, and will not be repeated here.

[0489] Optionally, before step 1005, the method further includes step 1005': the fourth device verifies the signature of the first key credential.

[0490] The fourth device can determine that the second device is the issuer of the first key certificate based on the first key certificate. The fourth device can obtain the public key of the second device and verify the signature of the first key certificate based on the public key of the second device to determine that the first key certificate was indeed issued by the second device. If it is determined that the first key certificate was issued by the second device, the fourth device can determine that the first key certificate is valid.

[0491] For example, the fourth device can obtain the public key of the second device by querying the second DL; or, the public key of the second device can also be stored locally on the fourth device or on other nodes (e.g., SEPP), and the second device can also obtain the public key of the second device from the local device or other nodes. This application does not limit this.

[0492] Based on the above steps, the fourth device can obtain the information in the first key credential and the second digital identity used to generate the first digital identity.

[0493] In another implementation, after generating the first key credential, the second device may further retrieve the second digital identity from the second DL based on the second identifier, and then obtain the information in the second digital identity. In this case, the seventh request message in step 1003 may carry the information in the first key credential and the second digital identity. Step 1004' may also be omitted. It is understood that in this implementation, after the fourth device receives the first key credential and the information in the second digital identity from the second device, it can transparently transmit the information in the first key credential and the second digital identity to the third device in the network of the first DL. At this time, the seventh request message in step 1003 and the sixth request message in step 1005 below can be the same request message, that is, carrying the same information.

[0494] In step 1006, the fourth device sends a sixth request message to the third device, the sixth request message carrying information from the first key credential and the second digital identity. Correspondingly, the third device receives the sixth request message from the fourth device.

[0495] The sixth request message, also known as a cross-ledger publication request, can be used to request a third device to publish a first digital identity across the ledger.

[0496] In step 1007, the third device generates the first digital identity based on the information in the first key credential and the second digital identity.

[0497] In step 1008, the third device publishes the first digital identity in the first DL.

[0498] Figure 13 is another schematic diagram of UCDID2 (i.e., an example of a first digital identity) provided in an embodiment of this application. Comparing it with Figure 8, it can be seen that the difference between the UCDID2 shown in Figure 13 and the UCDID2 shown in Figure 8 is that the KC2 shown in Figure 12 uses the KC2 generated by IDM1, which is the KC2 exemplified above in conjunction with Figure 11. Other fields are the same as in Figure 8; please refer to step 604 of method 600 above for the explanation of UCDID2 in conjunction with Figure 8, which will not be repeated here.

[0499] It should be understood that the specific processes of steps 1005 to 1007 are the same as those of steps 603 to 605 of method 600, and can be referred to the detailed explanation above, which will not be repeated here.

[0500] In step 1009, the third device sends a fourth response message to the fourth device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the fourth device receives the fourth response message from the third device.

[0501] This fourth response message can be considered a response to the sixth request message. This fourth response message can also be called a cross-ledger publication response, and can be viewed as a response to the cross-ledger publication request.

[0502] Optionally, the method further includes: a fourth device storing the correspondence between the first digital identity and the identifier of the first DL.

[0503] Optionally, the method further includes step 1009': the third device sends a verification path to the fourth device, the verification path being used to indicate the storage path of the first digital identity in the first DL.

[0504] It should be understood that the specific processes of steps 1008, 1009, and 1009' are the same as those of steps 605, 606, and 606' in method 600 above. Please refer to the detailed explanation above, which will not be repeated here.

[0505] In one possible design, the verification path can be carried in the fourth response message. In this case, for the third device, steps 1009 and 1009' can be combined into a sending step; for the fourth device, steps 1009 and 1009' can be combined into a receiving step.

[0506] In step 1010, the fourth device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0507] Figure 14 is another schematic diagram of the second digital identity before and after the update provided in the embodiments of this application. Figure 14 still uses UCDID as an example of digital identity. UCDID1 shown in Figure 14(a) is the second digital identity before the update, and UCDID1 shown in Figure 14(b) is the second digital identity after the update. Comparing with Figure 9, it can be found that the difference between the second digital identity shown in Figure 14 and the second digital identity described in Figure 9 is that the second key credential shown in Figure 9 uses a second key credential issued by a second device, and the issuer is also correspondingly the second device. The signature is also correspondingly a signature based on the private key of the second device. Other fields are the same as in Figure 9; please refer to step 607 of method 600 above for the description of the second digital identity in conjunction with Figure 9, which will not be repeated here.

[0508] In step 1011, the fourth device sends a second response message to the second device, which indicates the publication result of the second digital identity in the first DL. Accordingly, the second device receives the second response message from the fourth device.

[0509] This second response message can be considered a response to the seventh request message mentioned above. This second response message can also be called a ledger update response, and can be considered a response to the ledger update request.

[0510] The specific processes of steps 1010 and 1011 are similar to those of steps 607 and 608 in method 600. Please refer to the detailed explanation above, and they will not be repeated here.

[0511] Optionally, the method further includes step 1011': the fourth device sends a verification path to the second device. Accordingly, the second device receives the verification path from the fourth device.

[0512] In this embodiment, the fourth device can send the received verification path to the first device through the second device, so that the first device can determine, based on the verification path, the existence of the first digital identity in the first DL.

[0513] For example, the fourth device can send the verification path directly to the second device, or it can encrypt the verification path and then send it to the second device.

[0514] One possibility is that the first key is an asymmetric key. The first key credential of the first digital identity stores the first public key. Since any node with query permissions in the first DL can obtain the first digital identity from the first DL, and thus obtain the first public key, for security reasons, the verification path can only be obtained by the relevant nodes. This verification path can be encrypted based on the first public key before being sent.

[0515] In one possible design, the verification path (or, the encrypted verification path) can be carried in the ledger update response. In this case, for the fourth device, steps 1011 and 1011' can be combined into a sending step; for the second device, steps 1011 and 1011' can be combined into a receiving step.

[0516] In step 1012, the second device sends a first response message to the first device, which indicates the publication result of the first digital identity in the first DL. Correspondingly, the first device receives the first response message from the second device.

[0517] This first response message can be considered a response to the first request message mentioned above. This first response message can also be called a cross-ledger response, and can be considered a response to a cross-ledger request.

[0518] After receiving the second response message from the fourth device, the second device can send a first response message to the first device to indicate the publication result of the first digital identity in the first DL.

[0519] In one possible design, the first key credential sent by the second device to the first device can be carried in the first response message. That is, the second device can send the first key credential via the first response message after receiving the second response message. In this case, for the second device, steps 1012 and 1003 can be combined into a sending step, and for the first device, steps 1012 and 1003 can be combined into a receiving step.

[0520] Optionally, the first key credential can be sent separately. That is, the second device can send the first key credential to the first device after generating it in step 1002, and it is not necessary to send it after receiving the second response message from the fourth device in step 1011. In this case, steps 1012 and 1003 can be executed separately.

[0521] Optionally, the method further includes step 1012': the second device sends a verification path to the first device. Accordingly, the first device receives the verification path from the second device.

[0522] The second device can directly forward the verification path received from the first device to the first device. If the second device receives an unencrypted verification path from the first device, then the second device will also send an unencrypted verification path to the first device; if the second device receives an encrypted verification path from the first device, then the second device will also send an encrypted verification path to the first device.

[0523] In one possible design, both the aforementioned verification path and the first key credential can be carried in the first response message. In this case, for the second device, steps 1012 and 1012' can be combined into a single sending step; for the first device, steps 1012 and 1012' can be combined into a single receiving step.

[0524] Optionally, the method further includes step 1012: the first device determines, based on the verification path, that the first digital identity is stored in the first DL.

[0525] The first device can verify whether the first digital identity is stored in the first DL based on the received verification path, that is, verify the authenticity of the first response message. If the first device receives an encrypted verification path, it can decrypt it using the first private key to obtain the original text of the verification path; if the first device receives a signature of the verification path, it can verify the signature using the first public key to determine whether the verification path has been tampered with. Afterwards, the first device can verify whether the first digital identity is stored in the first DL based on the verification path.

[0526] Optionally, the method further includes: the first device obtaining the first digital identity. Step 1012 specifically includes: the first device determining, based on the first digital identity and the verification path, whether the first digital identity is stored in the first DL.

[0527] As explained in method 600, the first device may not have permission to query ledger data in the first DL; therefore, the first device can generate a first digital identity based on the first key credential from the second device. Alternatively, the first device may have permission to query ledger data in the first DL; therefore, the first device can also obtain the first digital identity by querying the first DL.

[0528] The specific process by which the first device determines whether the first digital identity is stored in the first DL based on the verification path can be found in step 608 of method 600 above, and will not be repeated here.

[0529] In step 1013, the first device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0530] In step 1014, the first device stores the first digital identity.

[0531] The specific processes of steps 1013 and 1014 are the same as those of steps 609 and 610 in method 600 above. Please refer to the detailed explanation above, and they will not be repeated here.

[0532] Optionally, the method further includes: the first device storing the correspondence between the first digital identity and the first DL.

[0533] It should be understood that in this embodiment, the fourth device and the first device can respectively store the correspondence between the first digital identity and the first DL. For the specific process of the fourth device and the first device storing the correspondence between the first digital identity and the first DL, please refer to the detailed description of the fourth device storing the correspondence between the first digital identity and the first DL in method 600 above, which will not be repeated here.

[0534] It should be noted that in this embodiment, the third device and the fourth device are two devices defined from a functional perspective. In actual deployment, the third device and the fourth device can be installed together or separately, and this application does not limit this. When the third device and the fourth device are installed together, the communication between the third device and the fourth device mentioned above can be regarded as internal communication of the device. For example, steps 1006, 1009, and 1009' can be regarded as internal communication of the device; the operations performed by the third device and the fourth device can be regarded as operations performed by the same device. For example, steps 1005, 1005', 1007, 1008, and 1010 can be regarded as operations performed by the same device.

[0535] Based on the above scheme, when the first device needs to join the first DL, it can request the second device to issue a first key credential. This first key credential can be sent to a third device in the first DL's network, so that the third device in the first DL's network can generate a first digital identity for publication in the first DL based on the first key credential and information obtained from the second digital identity. This enables cross-ledger publication of digital identities between different DL networks, thereby achieving cross-ledger authentication of the first device, and the authentication of digital identities is no longer limited to the same DL network.

[0536] Figure 12B is a schematic flowchart of a communication method 1400 provided in another embodiment of this application. In the method 1400 shown in Figure 12B, the first device is not a device in the network of the first DL and the second DL, and the public key of the second device can be obtained by a node in the network of the first DL.

[0537] The steps in method 1400 are explained in detail below.

[0538] In step 1401, the first device sends a second request message to the second device, the second request message carrying the identifier of the first DL. Correspondingly, the second device receives the second request message from the first device.

[0539] The second request message can be used to request the second device to issue a first key credential to the first device. Since the first key credential contains a first key generated based on the second key, it can be said that the first key credential is derived from the second key. This second request message can also be called a derivation request.

[0540] The identifier of the first DL can be used to identify the first DL. In this embodiment, since the second device is not a device in the DL's network, the second device needs to determine whether it needs to generate a digital identity across the ledger based on the identifier of the first DL. A more detailed description of the identifier of the first DL can be found in the relevant description in step 601 of method 600 above, and will not be repeated here.

[0541] Optionally, the second request message may also carry a second key credential.

[0542] The second key credential is the key credential in the second digital identity issued by the first device in the second DL. In this embodiment, since the second device is responsible for issuing the key credential, and the second key credential is also issued by the second device, the second key credential carried in the second request message can be used by the second device to verify it, as detailed in step 1402 below.

[0543] Optionally, before step 1401, the method further includes step 1401': the first device determines that the algorithm used to generate the identifier in the network of the first DL is the same as the algorithm used to generate the identifier in the network of the second DL.

[0544] For a more detailed explanation of step 1401', please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0545] In step 1402, the second device generates the first key credential.

[0546] After receiving the second request message, the second device can determine that it is necessary to generate a first digital identity across the ledger, and the first key credential contained in the first digital identity is issued by the second device. Therefore, the second device can determine that it is necessary to generate a first key credential for generating the first digital identity.

[0547] In one example, the second device can obtain parameters locally for generating a first identifier and a first key, and then generate a first key credential. In this case, the first key can be a symmetric key, and the first key credential can be obtained by signing the instruction information of the first key based on the private key of the second device; or, the first key can also be an asymmetric key, including a first public key and a first private key, and the first key credential can be obtained by signing the first public key based on the private key of the second device.

[0548] In another example, the second device may also obtain information for generating the first identifier and information for generating the first key from the second request message, thereby generating the first identifier and the first key, and then generating the first key credential.

[0549] Optionally, the second request message may also carry: an identifier for the algorithm used to generate the first key and an identifier for the algorithm used to generate the first identifier. Optionally, it may also carry one or more of the following: a second public key, a second identifier, a MAC address, a random number, a block hash, or a blockchain time. That is, the second device can generate the first identifier, the first public key, and the first private key itself based on the parameters carried in the second request message. In this case, the first key includes the first public key and the first private key, and the first key credential can be obtained by signing the first public key with the private key of the second device.

[0550] In another example, the first device can directly send the first identifier and the first public key to the second device.

[0551] Optionally, the second request message also carries a first identifier and a first public key. That is, the second device can obtain the first identifier and the first public key from the second request message. In this case, the first key includes a first public key and a first private key, and the first key credential can be obtained by signing the first public key based on the private key of the second device.

[0552] Optionally, the first key credential is also obtained by signing the first key information and the first identifier based on the private key of the second device.

[0553] Therefore, the second device can also obtain the first identifier before generating the first key credential. This first identifier can be generated by the second device, or it can be sent to the second device by the first device; there is no limitation on this.

[0554] Optionally, the first key credential is also obtained by signing the first key information, the first identifier, and the identifier of the first DL based on the private key of the second device. Therefore, the second device can also obtain the identifier of the first DL from the third request message before generating the first key credential.

[0555] The relationship between the first key credential and the parameters in the second request message, as well as the generation process of the first key credential, has been explained in detail in step 920 of method 900 above. Please refer to the above for understanding, and it will not be repeated here.

[0556] Optionally, prior to step 1402, the method further includes step 1402', whereby the second device determines that the first device is valid in the network of the second DL.

[0557] In this embodiment, after receiving the second key credential, the second device can first verify the signature of the second key credential based on the private key of the second device to determine whether the second key credential was issued by itself, thereby determining that the first device is valid in the network of the second DL.

[0558] Optionally, before step 1402, the method further includes step 1402, where the second device determines that the first device does not have a digital identity in the first DL.

[0559] For a more detailed explanation of steps 1402' and 1402", please refer to the relevant descriptions in steps 1002' and 1002" of method 1000 above, which will not be repeated here.

[0560] Similar to method 1000, in this embodiment the first key credential is generated by the second device. Therefore, the first key credential generated by the second device can be referred to the example above in conjunction with Figure 13, and will not be repeated here.

[0561] In step 1403, the second device sends the first key credential to the first device. Accordingly, the first device receives the first key credential from the second device.

[0562] In this embodiment, since the second device is not a device in the network of the second DL, or in other words, the second device does not belong to the node of the DL, the second device cannot determine which device to send the first key credential to. Therefore, the second device sends the generated first key credential to the first device for processing.

[0563] Optionally, the first key credential may be carried in a derived response, which can be regarded as a response to the derived request in step 1401.

[0564] In step 1404, the first device sends a first request message to the fourth device, the first request message carrying a first key credential and a second identifier. Correspondingly, the first request message from the first device is received.

[0565] This first request message can also be called a cross-ledger request, for example.

[0566] ID1 can be used to identify the second digital identity. DLE2-a can retrieve data from the second DL based on ID1 to obtain the second digital identity. The first key credential can be used to generate the first digital identity.

[0567] Optionally, the first request message also carries an identifier of the first DL. The identifier of the first DL can be used to identify the DL to be joined, and the fourth device can determine from the identifier of the first DL that the first request message requests to join the first DL. For a more detailed explanation of the identifier of the first DL, please refer to the detailed description in step 601 of method 600 above, which will not be repeated here.

[0568] Optionally, before step 1404, the method further includes: the first device determining the IP address of the fourth device. For details regarding the process of the first device determining the IP address of the fourth device, please refer to the detailed description in method 600 above, which will not be repeated here.

[0569] Optionally, prior to step 1404, the method further includes step 1404': the first device determines that the first key credential from the second device is valid. Step 1404 can be performed after determining that the first key credential is valid.

[0570] As mentioned above, although the second device is not a node in the second DL network, its public key is obtained by devices in the second DL network. Therefore, the first device can obtain the second device's public key and verify the signature of the first key credential based on the second device's public key to ensure that the first key credential was issued by the second device. The second device's public key can be obtained by querying the second DL, or it can be stored locally on the fourth device or in another device (e.g., SEPP). The first device can also obtain it locally or from other nodes; this application does not limit this. Since determining the validity of the first key credential is achieved by verifying its signature, step 1404' can also be referred to as the first device verifying the signature of the first key credential.

[0571] Furthermore, if the second request message sent in step 1401 does not carry the first identifier and the first public key, the first device can also compare the first identifier and the first public key in the received first key credential with its own generated first identifier and first public key. If they are the same, it is determined that the first key credential was issued by the second device. That is, the verification is successful.

[0572] If the first device fails to verify the signature of the first key credential based on the public key of the second device, or if the first identifier and the first public key in the first key credential received by the first device are different from the first identifier and the first public key it generated, then the verification is determined to have failed.

[0573] Optionally, the method further includes step 1405, in which the first device sends a verification failure message to the second device.

[0574] The first device notifies the second device of a verification failure message, indicating that the verification of the first key credential or the first identifier and the first public key has failed. Optionally, the message may carry the first identifier and the first public key generated by the first device itself, or, if the second request message does not carry an identifier of the algorithm used to generate the first identifier, the message may also carry an identifier of the algorithm used by the second device to generate the first identifier.

[0575] It should be understood that steps 1404 and 1405 are operations performed separately when the verification results of step 1404' are different. That is, steps 1404 and 1405 can be performed separately, rather than both. For ease of distinction, step 1405 is shown as a dashed line in the figure.

[0576] To facilitate a detailed explanation of the process in this embodiment, it is assumed here that the first device determines that the first key credential from the first device is valid.

[0577] In step 1406, the fourth device obtains information from the second digital identity based on the second identifier.

[0578] The fourth device can retrieve information from the second digital identity obtained from the second DL based on the second identifier.

[0579] Optionally, prior to step 1406, the method further includes step 1406': a fourth device verifies the signature of the first key credential.

[0580] The fourth device can obtain the public key of the second device by querying the second DL, or it can obtain the public key of the second device from a local device or another device (such as SEPP), and use the public key of the second device to verify the signature of the first key credential. If the verification is successful, it can be determined that the first key credential was indeed issued by the second device; if the verification fails, it can be determined that the first key credential was not issued by the second device.

[0581] To facilitate a detailed explanation of the process in this embodiment, it is assumed here that the fourth device successfully verifies the signature of the first key credential.

[0582] Optionally, prior to step 1406, the method further includes: a fourth device determining that the first device is valid in the network of the second DL.

[0583] The specific process by which the fourth device determines that the first device is valid in the network of the second DL can be found in step 602' of method 600 above, and will not be repeated here.

[0584] In step 1407, the fourth device sends a sixth request message to the third device, the sixth request message carrying information from the first key credential and the second digital identity. Correspondingly, the third device receives the sixth request message from the fourth device.

[0585] This first request message can also be called a cross-ledger publication request.

[0586] In step 1408, the third device generates the first digital identity based on the information in the first key credential and the second digital identity.

[0587] Similar to method 1000, in this embodiment, the first digital identity is generated by a third device, and the first key credential is generated by a second device. Therefore, the first digital identity generated in this embodiment can be referred to the example above in conjunction with Figure 13, and will not be repeated here. In step 1409, the third device publishes the first digital identity in the first DL.

[0588] It should be understood that the specific processes of steps 1408 and 1409 are the same as those of steps 604 and 605 in method 600, which can be referred to in the detailed explanation above and will not be repeated here.

[0589] In step 1410, the third device sends a fourth response message to the fourth device, the fourth response message indicating the publication result of the first digital identity in the first DL. Accordingly, the fourth device receives the fourth response message from the third device.

[0590] This fourth response message can be considered a response to the sixth request message mentioned above. This fourth response message can also be called a cross-ledger publication response, corresponding to the cross-ledger publication request.

[0591] Optionally, the method further includes: a fourth device storing the correspondence between the first digital identity and the identifier of the first DL.

[0592] Optionally, the method further includes step 1410': the third device sends a verification path to the fourth device, which can be used to indicate the storage path of the first digital identity in the first DL.

[0593] In one possible design, the verification path can be carried in the cross-ledger publish response. In this case, for the third device, steps 1410 and 1410' can be combined into a single send step; for the fourth device, steps 1410 and 1410' can be combined into a single receive step.

[0594] It should be understood that the specific processes of steps 1407 to 1410 and step 1410' are the same as those of steps 603 to 606 and step 606' in method 600 above. Please refer to the detailed explanation above, and it will not be repeated here.

[0595] In step 1411, the fourth device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0596] Optionally, the method further includes: a fourth device storing the correspondence between the first digital identity and the identifier of the first DL.

[0597] In step 1412, the fourth device sends a first response message to the first device, which indicates the publication result of the first digital identity in the first DL. Correspondingly, the first device receives a first response message from the second device.

[0598] This first response message can be considered a response to the first request message mentioned above. This first response message can also be called a cross-ledger response, corresponding to a cross-ledger request.

[0599] Optionally, the method further includes step 1412': the fourth device sends a verification path to the first device, the verification path indicating the storage path of the first digital identity in the first DL. Accordingly, the first device receives the verification path from the fourth device.

[0600] In one possible design, the aforementioned verification path can be carried in the first response message. In this case, for the second device, steps 1412 and 1412' can be combined into a sending step; for the first device, steps 1412 and 1412' can be combined into a receiving step.

[0601] Optionally, the method further includes step 1412: the first device determines a digital identity based on the verification path. The first digital identity is stored in the first DL.

[0602] In step 1413, the first device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0603] In step 1414, the first device stores the first digital identity. It should be understood that the specific processes of steps 1411 to 1414 are the same as those of steps 607 to 610 in method 600 above, and can be referred to the detailed description above, which will not be repeated here.

[0604] Optionally, the method further includes: the first device storing the correspondence between the first digital identity and the identifier of the first DL.

[0605] It should be understood that in this embodiment, the fourth device and the first device can respectively store the correspondence between the first digital identity and the identifier of the first DL. For the specific process of the fourth device and the first device storing the correspondence between the first digital identity and the identifier of the first DL, please refer to the detailed description of the fourth device storing the correspondence between the first digital identity and the identifier of the first DL in method 600 above, which will not be repeated here.

[0606] It should be noted that in this embodiment, the third device and the fourth device are two devices defined from a functional perspective. In actual deployment, the third device and the fourth device can be installed together or separately, and this application does not limit this. When the third device and the fourth device are installed together, the communication between the third device and the fourth device mentioned above can be regarded as internal communication of the device. For example, steps 1407, 1410, and 1410' can be regarded as internal communication of the device; the operations performed by the third device and the fourth device can be regarded as operations performed by the same device. For example, steps 1406, 1406', 1407, 1408, 1409, 1411, and 1411' can be regarded as operations performed by the same device.

[0607] Based on the above scheme, when the first device needs to join the first DL, it can request the second device to issue a first key credential. The second device can return the issued first key credential to the first device, which can then send the first key credential to a third device in the first DL's network. This allows the third device in the first DL's network to generate a first digital identity for publication in the first DL based on the first key credential and information obtained from the second digital identity. This enables cross-ledger publication of digital identities between different DL networks, thereby achieving cross-ledger authentication of the first device. The authentication of digital identities is no longer limited to the same DL network.

[0608] Furthermore, since method 1000 shown in Figure 12A and method 1400 shown in Figure 12B are based on method 900 shown in Figure 10, they have the same technical effects as method 900, and will not be described in detail for the sake of brevity.

[0609] It is readily apparent that in method 1000 shown in Figure 12A above, the fourth device can receive a seventh request message from the second device, which carries a first key credential. Optionally, the fifth request message also carries a second identifier, which can be used by the fifth device to obtain information from the second digital identity based on the second identifier; alternatively, the fifth request message may also carry information from the second digital identity. The fifth device can send the first key credential and the information from the second digital identity to the third device, so that the third device can generate a first digital identity based on the first key credential and the information from the second digital identity.

[0610] In method 1400 shown in Figure 12B, a fourth device may receive a first request message from a first device, the first request message carrying a first key credential and a second identifier. A fifth device may obtain information from a second digital identity based on the second identifier. The fifth device may send the information from the first key credential and the second digital identity to a third device, so that the third device may generate a first digital identity based on the information from the first key credential and the second digital identity.

[0611] In summary, the seventh request message and the first request message have similar functions, only the sender is different. They can be regarded as two examples of the fifth request message received by the fifth device.

[0612] The above description, in conjunction with Figures 10, 12A, and 12B, details the specific process of the communication method provided in this application when the second device generates the first key credential. However, in some cases, the public key of the second device may not be stored in the first DL; in other words, the public key of the second device may not be obtainable by devices in the first DL network. In this case, if the second device still generates the first key credential, the devices in the first DL network cannot verify the signature based on the private key of the second device because they cannot obtain the public key of the second device, i.e., they cannot determine whether the first key credential is legitimate. In other cases, the algorithm used to generate the identifier in the second DL network is different from the algorithm used to generate the identifier in the first DL network. In this case, if the first identifier and the first key credential are still generated in the second DL network, the different algorithms for generating the identifier in the second DL network and the first DL network result in different identifier formats in the second DL network and the first DL network, which may cause the first identifier and the first key credential to be unverifiable by devices in the first DL network.

[0613] Based on this, this application also provides a solution in which a fifth device generates the first key credential. This fifth device may correspond to an IDM, for example, denoted as IDM2. Unlike IDM1, the public key of IDM2 can be obtained by devices in the network of the first DL. The fifth device may or may not be a device in the network of the first DL, and there is no limitation thereto.

[0614] This application also provides a solution in which a first key credential is generated by a third device in the network of the first DL, the third device holding the private key of the first DL.

[0615] For ease of understanding, the communication method provided in this application will first be described from the perspective of the fifth device, referring to Figure 15, for the first solution. Then, the specific implementation process of the communication method will be described from the perspective of interaction, referring to Figures 18A and 18B. Next, the communication method provided in this application will be described from the perspective of the third device, referring to Figure 19. Then, the specific implementation process of the communication method will be described from the perspective of interaction, referring to Figure 22.

[0616] Figure 15 is another schematic flowchart of the communication method provided in an embodiment of this application. The method 1500 shown in Figure 15 can be executed by a fifth device. The public key of this fifth device can be obtained by devices in the network of the first DL, for example, it can be pre-installed in the first DL, such as in devices in the network of the first DL, or obtained from other devices (e.g., SEPP). The implementation of the fifth device's public key being pre-installed in the first DL can be understood by referring to the several possible implementations listed above in conjunction with IDM1, and will not be repeated here.

[0617] The method 1500 shown in Figure 15 is described in detail below.

[0618] In step 1510, a fourth request message is received, which carries the first public key.

[0619] The first public key can be used for authentication of the first device within the network of the first DL (Digital Provider Interface), and can also be used to generate the first key credential. This first public key can be generated based on a second public key, which can be used for authentication of the first device within the network of the second DL, where the second DL is the DL for which the first device has issued a second digital identity. Therefore, it can be seen that the first public key used to generate the first key credential can be generated based on the second public key in the second digital identity.

[0620] The fourth request message in step 1510 can be a fourth request message sent by the first device to the fifth device via the fourth device and the third device. In other words, the first public key is generated by the first device.

[0621] In this embodiment, the second public key used to generate the first public key can be carried in the fourth request message. For security reasons, the first device will not send out the symmetric key. Therefore, the first key used to generate the first key credential is the public key, i.e., the aforementioned first public key. This first key credential can also be called the first public key credential.

[0622] In step 1520, a first key credential is generated based on the first public key.

[0623] In this embodiment, the first key credential can be obtained by the fifth device signing the first public key based on its own private key. Step 1520 may specifically include: signing the first public key based on the private key of the fifth device to obtain the first key credential.

[0624] Optionally, the first key credential is also generated based on the first identifier. Step 1520 may specifically include: signing the first public key and the first identifier based on the private key of the fifth device to obtain the first key credential. Before step 1520, the method further includes: generating the first identifier.

[0625] Optionally, the first key credential is also generated based on the identifier of the first DL. Step 1520 may specifically include: signing the first public key, the first identifier, and the identifier of the first DL based on the private key of the fifth device to obtain the first key credential. The identifier of the first DL may be obtained by the fifth device itself, for example, the fifth device may be a device in the network of the first DL, or the identifier of the first DL may be carried in the fourth request message, without limitation.

[0626] For a more detailed explanation of how to obtain the first key credential by signing based on the private key of the fifth device, please refer to the relevant description of obtaining the first key credential by signing based on the private key of the first device in Method 600 above, which will not be repeated here.

[0627] The first identifier may be generated by the fifth device. Optionally, the fourth request message may also carry: an identifier of the algorithm used to generate the first identifier, and optionally, one or more of the following: a second identifier, an identifier of the first DL, a random number, a timestamp, a block hash, a blockchain time, or a MAC address.

[0628] The fifth device may generate a first identifier based on the parameters obtained from the fourth request message. The generation of this first identifier is described in step 601 of method 600 above, and will not be repeated here.

[0629] Figure 16 is another schematic diagram of the first key credential provided in the embodiments of this application. Figure 16 still uses KC2 as an example, showing another possible example of the first key credential. Comparing Figures 7 and 11, it can be found that the difference between the KC2 shown in Figure 16 and the KC2 shown in Figures 7 and 11 is that the Issuer ID shown in Figure 16 indicates the IDM2 ID, indicating that the issuer of the KC2 is IDM2, i.e., an example of the fifth device. Since the KC2 is obtained by IDM2 signing other information in the KC2 based on its own private key, the signature is correspondingly represented as Sig. IDM2 Furthermore, since the first key in this embodiment is an asymmetric key, Claims indicates PK2, i.e., an example of the first public key. Other fields are the same as in Figures 7 and 11; refer to step 601' of method 600 above for the explanation of KC2 in conjunction with Figure 7, and will not be repeated here. It is understandable that since the issuer identifier of KC2 is the identifier of IDM2, in the subsequent verification process, the issuer's information, such as the public key certificate of IDM2, can be found through this issuer identifier.

[0630] After generating the first key credential, the fifth device can perform different operations depending on whether it is a device in the network of the first DL.

[0631] In one possible design, the fifth device is a device in the network of the first DL. After generating the first key credential, the fifth device can further generate and publish the first digital identity. Optionally, the fourth request message also carries information from the second digital identity. The method further includes: generating the first digital identity based on the information from the first key credential and the second digital identity; and publishing the first digital identity.

[0632] Optionally, the fourth request message may also carry information from the second digital identity. The fifth device may generate and publish the first digital identity based on the information from the first key credential and the second digital identity.

[0633] Figure 17 is another schematic diagram of UCDID2 (i.e., an example of a first digital identity) provided in the embodiments of this application. Comparing it with Figure 8, it can be seen that the difference between the UCDID2 shown in Figure 17 and the UCDID2 shown in Figure 8 is that the KC2 shown in Figure 18 uses the KC2 generated by IDM2, which is the KC2 exemplified above in conjunction with Figure 16. Other fields are the same as in Figure 8; please refer to step 607 of method 600 above for the explanation of UCDID2 in conjunction with Figure 8, which will not be repeated here.

[0634] For details regarding the information in the second digital identity, and the generation and publication of the first digital identity, please refer to the relevant descriptions of steps 603 to 605 of method 600 above, which will not be repeated here.

[0635] In another possible design, the fifth device is not a device in the first DL's network. After generating the first key credential, the fifth device can send the first key credential to a third device in the first DL's network, so that the third device can generate and publish the first digital identity. Optionally, the method further includes sending the first key credential to the third device.

[0636] Based on the above scheme, when the first device needs to join the first DL, it can request the fifth device to issue a first key certificate. Since the IDM2 corresponding to the fifth device represents the operator, the first key certificate issued by the second device has higher credibility. Furthermore, the fifth device performs identity derivation and verification functions, while the first device performs DL-related functions, making the functional division clearer. This also reduces the computational resource consumption of the first device in performing identity derivation and verification, thus releasing the DLE capability of the first device.

[0637] Figure 18A is a schematic flowchart of a communication method 1600 provided in another embodiment of this application. In the method 1600 shown in Figure 18A, the fifth device is a device corresponding to IDM2. This fifth device can be a device in the network of the first DL, and the public key of the fifth device can be obtained by a device in the network of the first DL. For example, it can be pre-set in the first DL, such as in a device in the network of the first DL, or it can be obtained from other devices (such as SEPP). The various steps in Figure 18A are described in detail below.

[0638] In step 1601, the first device sends a first request message to the fourth device, the first request message carrying a second identifier and a first public key. Accordingly, the fourth device receives the first request message from the first device.

[0639] This first request message can also be called a cross-ledger request, for example.

[0640] As an example, this DL technology can be applied to a blockchain, where the second DL can be one blockchain and the first DL can be another. In this case, the cross-ledger request can also be called a cross-chain request.

[0641] In this embodiment, the fourth device is a device in the network of the second DL, and has permissions such as querying the ledger and uploading transactions. The second identifier can be used by the fourth device to query the ledger, so that the fourth device can obtain the second digital identity corresponding to the first device, and then obtain the information in the second digital identity.

[0642] The first request message carries a first public key, that is, the first public key is generated by the first device and sent to the fifth device.

[0643] Optionally, before step 1601, the method further includes step 1601': the first device generates a first public key and a first private key based on the second public key and / or the second private key.

[0644] In this embodiment, the first key credential is generated by the fifth device, and the first key credential needs to be generated based on the first public key. However, the algorithms used to generate the key in the two DL networks may be the same or different, and the devices in the first DL network do not know the algorithms used to generate the key in the second DL network, nor do the devices in the second DL network know the algorithms used to generate the key in the first DL network. Therefore, in this embodiment, the first device sends its generated first public key to the fourth device in the first request message, so that the fourth device can forward it to the fourth device in the first DL network.

[0645] For security reasons, the first device will not send out its own symmetric key. Therefore, the first device can generate a first public-private key pair, including a first public key and a first private key. That is to say, the first key credential in this embodiment can be generated based on the first public key.

[0646] The first device can generate a first public key and a first private key based on a second public key and / or a second private key. The second public key and the second private key can be used for authentication by the first device in a second DL network where the second digital identity has been issued. The first public key and the first private key generated based on the second public key and / or the second private key can be used for authentication by the first device in a first DL network where the first digital identity is to be issued.

[0647] For a more detailed explanation of how the first device generates the first public key and the first private key based on the second public key and / or the first private key, please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0648] Optionally, the first request message may also carry the identifier of the first DL.

[0649] The identifier of the first DL is used to identify the first DL to be joined, so that the fourth device can determine which DL the sender of the first request message (i.e., the first device) requests to join. For more details about the identifier of the first DL also being carried in the first request message, please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0650] Optionally, the first request message may also carry one or more of the following: a random number, a timestamp, a block hash, a blockchain time, or a MAC address. These parameters can be used to generate the first identifier.

[0651] Optionally, before step 1601, the method further includes step 1601”: the first device determines that the algorithm used to generate the identifier in the network of the second DL is different from the algorithm used to generate the identifier in the network of the first DL.

[0652] For a more detailed explanation of step 1601, please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0653] Optionally, before step 1601, the method further includes: the first device determining the IP address of the fourth device. The specific process by which the first device determines the IP address of the fourth device can be found in the detailed description of method 600 above, and will not be repeated here.

[0654] In step 1602, the fourth device obtains information from the second digital identity based on the second identifier.

[0655] Optionally, the method further includes step 1602', whereby the fourth device determines that the first device is valid in the network of the second DL.

[0656] Optionally, the method further includes step 1602, where the fourth device determines that the first device does not have a digital identity in the first DL.

[0657] The specific processes of steps 1602, 1602' and 1602" are the same as those of steps 602, 602' and 602" in method 600 above. Please refer to the detailed explanation above, and it will not be repeated here.

[0658] In step 1603, the fourth device sends a sixth request message to the third device, the sixth request message carrying information from the first public key and the second digital identity. Correspondingly, the third device receives the sixth request message from the fourth device.

[0659] The sixth request message is used to request an update to the first ledger entry (DL), that is, to request the generation of a new digital identity and its storage in the first DL. This sixth request message can also be called a ledger update request.

[0660] Specifically, a first key credential is generated using a first identifier and a first public key, and the information in the first key credential and the second digital identity can be used to generate the first digital identity.

[0661] Optionally, the sixth request message also carries an identifier of the first DL. The identifier of the first DL can be used to identify the first DL so that the third device can determine that a digital identity needs to be published in the first DL.

[0662] Since the third device may only be a device in the network of the first DL and not belong to the network of other DLs, in this case, the sixth request message may not carry the identifier of the first DL. After receiving the sixth request message from the fourth device, the third device can determine that a new digital identity needs to be generated and published in the first DL.

[0663] In step 1604, the third device sends a fourth request message to the fifth device, the fourth request message carrying information from the first public key and the second digital identity. Correspondingly, the fifth device receives the fourth request message from the third device.

[0664] This fourth request message can also be called a registration request.

[0665] In this embodiment, since the public key of the fifth device can be obtained by devices in the network of the first DL, the fifth device can generate the first key credential; and since the fifth device is a device in the network of the first DL, the fifth device can also generate and publish the first digital identity. Therefore, the fourth request message can be used to request the fifth device to generate the first key credential and the first digital identity for the first device.

[0666] In step 1605, the fifth device generates the first key credential.

[0667] Optionally, the first key credential can be generated based on the first public key. Accordingly, step 1605 may specifically include: the fifth device signing the first public key based on the private key of the fifth device to obtain the first key credential.

[0668] Optionally, the first key credential is also generated based on the first identifier. Accordingly, step 1605 may specifically include: the fifth device signing the first identifier and the first public key based on the private key of the fifth device to obtain the first key credential. In this case, before step 1605, the method further includes: the fifth device generating the first identifier.

[0669] The fifth device can generate the first identifier based on the parameters used to generate the first identifier and the algorithm used to generate the first identifier.

[0670] As described in step 601 of method 600, the parameters used to generate the first identifier may include one or more of the following: a second identifier, a first public key, an identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, and blockchain time. Therefore, in addition to carrying the aforementioned first public key and second identifier, the first request message in this embodiment may optionally also carry one or more of the following: the identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, or blockchain time. Correspondingly, the fourth request message and the sixth request message may also optionally carry one or more of the following: the identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, or blockchain time. It is understood that if the first identifier is generated based on the first public key and / or the second identifier, the first request message, the fourth request message, and the sixth request message may also omit the timestamp, the MAC address of the first device, the random number, the block hash, and the blockchain time.

[0671] In this embodiment, since the algorithm used to generate the first identifier in the first DL network is different from the algorithm used to generate the second identifier in the second DL network, the fifth device can first obtain the algorithm used to generate the first identifier in the first DL network, and then generate the first identifier based on that algorithm.

[0672] Optionally, the first key credential is also generated based on the identifier of the first DL. Accordingly, step 1605 may specifically include: the fifth device signing the first identifier, the first public key, and the identifier of the first DL based on the private key of the fifth device to obtain the first key credential.

[0673] The identifier of the first DL can be carried by the first device in the first request message; that is, the first request message can also carry the identifier of the first DL. The identifier of the first DL can be carried in the first request message so that it can be sent to the fifth device via the fourth device and the third device, and the fifth device can obtain the identifier of the first DL from the fourth request message received by the third device.

[0674] Alternatively, the identifier of the first DL can also be determined by the fifth device itself. In this embodiment, since the fifth device is a device in the network of the first DL, the fifth device can determine the identifier of the first DL itself.

[0675] Since the fifth device may only be a device in the network of the first DL and not belong to other DLs, the fifth device can determine to generate the first key credential for use in the first DL after receiving the fourth request message from the third device, without necessarily needing to carry the identifier of the first DL after the fourth request message.

[0676] For a more detailed explanation of how the fifth device generates the first key credential, please refer to the relevant descriptions in step 601 of method 600 and step 1520 of method 1500 in conjunction with Figure 16, which will not be repeated here.

[0677] In step 1606, the fifth device generates the first digital identity based on the information in the first key credential and the second digital identity.

[0678] In step 1607, the fifth device publishes the first digital identity in the first DL.

[0679] It should be understood that the specific processes of steps 1606 and 1607 are the same as those of steps 604 and 605 in method 600 above. Please refer to the detailed explanation above, which will not be repeated here.

[0680] In step 1608, the fifth device sends a third response message to the third device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the third device receives the third response message from the fifth device.

[0681] This third response message can be a response to the fourth request message mentioned above. This third response message can also be called a registration response, corresponding to the registration request.

[0682] After the first digital identity has been published in the first DL, the fifth device can send the third response message to the fourth device to indicate that the first digital identity has been published in the first DL.

[0683] Optionally, the method further includes step 1608', in which the fifth device sends the first key credential to the third device. Accordingly, the third device receives the first key credential from the fifth device.

[0684] In this embodiment, the first key credential is generated by the fifth device, which can send the first key credential to the first device through the third device and the fourth device.

[0685] In one possible design, the first key credential is carried in the third response message. In this case, for the fifth device, steps 1608 and 1608' can be combined into a single sending step; for the third device, steps 1608 and 1608' can be combined into a single receiving step.

[0686] In step 1609, the third device sends a fourth response message to the fourth device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the fourth device receives the fourth response message from the third device.

[0687] This fourth response message can be considered a response to the fourth request message mentioned above. This fourth response message can also be called a registration response, corresponding to the registration request.

[0688] After receiving the fourth response message from the fifth device, the fourth device can publish the result in the first DL using the first digital identity. The fourth device can then send a first response message to the first device to forward the publication result to the first device.

[0689] This fourth response message can be considered a response to the sixth request message mentioned above. The first response message could be called a cross-ledger response, corresponding to a ledger update request.

[0690] Optionally, the method further includes step 1609', in which the third device sends the first key credential to the fourth device. Accordingly, the fourth device receives the first key credential from the third device.

[0691] The third device may forward the first key credential to the fourth device upon receiving it from the fifth device.

[0692] It should be understood that step 1609' does not necessarily have to be executed after step 1608. The fifth device can execute step 1609' after generating the first key credential in step 1605.

[0693] Optionally, the method further includes step 1609,” whereby the fourth device sends a verification path to the third device, the verification path indicating the storage path of the first digital identity in the first DL. Accordingly, the third device receives the verification path from the fourth device.

[0694] Since the third device is a device in the network of the first DL and has the authority to query data in the first DL, the third device can obtain the verification path of the first digital identity in the first DL and send the verification path to the first device through the fourth device so that the first device can verify whether the first digital identity is stored in the first DL based on the verification path.

[0695] In one possible design, the first key credential and / or authentication path are carried in the fourth response message. In this case, for the third device, step 1609 and steps 1609' and / or 1609" can be combined into a single sending step; for the fourth device, steps 1609 and steps 1609' and / or 1609" can be combined into a single receiving step.

[0696] In step 1610, the fourth device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0697] It should be understood that the specific process of step 1610 can be found in the detailed explanation of step 607 of method 600 above, and will not be repeated here.

[0698] It should be noted that, in this embodiment, since the second digital identity is a digital identity issued by the first device in the second DL, it can be issued by the second device (i.e., the device corresponding to IDM1 mentioned above). Therefore, the issuer of the second key credential in the second digital identity can be the second device. Taking IDM1 as an example, the signature of the second key credential can be, for example, Sig. IDM1 For details, please refer to the examples above in conjunction with Figures 13 and 14; the first digital identity is the digital identity issued by the first device in the first DL, and is issued by the fifth device (i.e., the device corresponding to IDM2). Therefore, the issuer of the first key credential in the first digital identity can be the fifth device. Taking IDM2 as an example, the signature of the first key credential can be, for example, Sig. IDM2 For details, please refer to the examples in Figures 16 and 17 above, which will not be repeated here.

[0699] Optionally, the method further includes: a fourth device storing the correspondence between the first digital identity and the first DL.

[0700] In step 1611, the fourth device sends a first response message to the first device, the first response message indicating the publication result of the first digital identity in the first DL. Accordingly, the first device receives the first response message from the fourth device.

[0701] This first response message can be considered a response to the first request message mentioned above. This first response message could be, for example, called a cross-ledger response, corresponding to a cross-ledger request.

[0702] Optionally, the method further includes step 1611', in which the fourth device sends a first key credential to the first device. Accordingly, the first device receives the first key credential from the fourth device.

[0703] The fourth device may forward the first key credential to the first device upon receiving it from the third device.

[0704] Optionally, the method further includes step 1611", whereby the fourth device sends a verification path to the first device. Accordingly, the first device receives the verification path from the fourth device.

[0705] In one possible design, the first key credential and / or authentication path are carried in the first response message. In this case, for the fourth device, step 1611 and steps 1611' and / or 1611" can be combined into a single sending step; for the first device, steps 1611 and steps 1611' and / or 1611" can be combined into a single receiving step.

[0706] Optionally, the method further includes step 1611”', whereby the first device determines, based on the verification path, that the first digital identity is stored in the first DL.

[0707] It should be understood that the specific processes of steps 1611, 1611” and 1611”' are the same as those of steps 1011, 1011’ and 1011” in method 1000. Please refer to the detailed explanation above, which will not be repeated here.

[0708] It should also be understood that step 1608' does not necessarily have to be executed after step 1607. For example, it can also be executed after step 1605. In this case, the associated steps 1609' and 1611' do not necessarily have to be executed after step 1607. That is, the first key credential does not necessarily have to be carried in the third response message sent by the fifth device to the third device, the fourth response message sent by the third device to the fourth device, and the first response message sent by the fourth device to the first device.

[0709] In step 1612, the first device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, that is, the first identifier.

[0710] In step 1613, the first device stores the first digital identity.

[0711] It should be understood that the specific processes and methods of steps 1612 and 1613 are the same as those of steps 609 and 610 in 600. Please refer to the detailed explanation above, which will not be repeated here.

[0712] Optionally, the method further includes: the first device storing the correspondence between the first digital identity and the first DL.

[0713] It should be understood that in this embodiment, the fourth device and the first device can respectively store the correspondence between the first digital identity and the identifier of the first DL. For the specific process of the fourth device and the first device storing the correspondence between the first digital identity and the identifier of the first DL, please refer to the detailed description of the fourth device storing the correspondence between the first digital identity and the identifier of the first DL in method 600 above, which will not be repeated here.

[0714] It should be noted that in this embodiment, the third device and the fourth device are two devices defined from a functional perspective. In actual deployment, the third device and the fourth device can be installed together or separately, and this application does not limit this. When the third device and the fourth device are installed together, the communication between the third device and the fourth device mentioned above can be regarded as internal communication of the device. For example, steps 1603, 1609, 1609' and 1609" can be regarded as internal communication of the device; the operations performed by the third device and the fourth device can be regarded as operations performed by the same device. For example, steps 1602, 1602', 1602" and 1608, 1608' and 1610, 1611, 1611' and 1611" can be regarded as operations performed by the same device.

[0715] Based on the above scheme, when the first device needs to join the first DL, it can initiate a request to devices in the first DL's network. The fifth device in the first DL's network can issue a first key credential to it, and further generate and publish the first device's first digital identity in the first DL based on the first key credential and the information in the obtained second digital identity. This enables cross-ledger publishing of digital identities between different DL networks, thereby achieving cross-ledger authentication of the first device, and the authentication of the digital identity is no longer limited to the same DL network.

[0716] Figure 18B is a schematic flowchart of a communication method 1800 provided in another embodiment of this application. In the method 1800 shown in Figure 18B, the fifth device is a device corresponding to IDM2, and the public key of the second device can be obtained by a device in the network of the first DL. For example, it can be pre-set in the first DL, such as in a device in the network of the first DL, or it can be obtained from other devices (such as SEPP). The various steps in Figure 18B are described in detail below.

[0717] In step 1801, the first device sends a first request message to the fourth device, the first request message carrying a second identifier and a first public key. Accordingly, the fourth device receives the first request message from the first device.

[0718] This first request message can also be called a cross-ledger request, for example.

[0719] Optionally, before step 1801, the method further includes step 1801': the first device generates a first public key and a first private key based on the second public key and / or the second private key.

[0720] Optionally, before step 1801, the method further includes step 1801”: the first device determines that the algorithm used to generate the identifier in the network of the first DL is different from the algorithm used to generate the identifier in the network of the second DL.

[0721] In step 1802, the fourth device obtains information from the second digital identity based on the second identifier.

[0722] Optionally, the method further includes step 1802', whereby the fourth device determines that the first device is valid in the network of the second DL.

[0723] Optionally, the method further includes step 1802, where the fourth device determines that the first device does not have a digital identity in the first DL.

[0724] In step 1803, the fourth device sends a sixth request message to the third device, the sixth request message carrying information from the first public key and the second digital identity. Correspondingly, the third device receives the sixth request message from the fourth device.

[0725] This sixth request message can also be called a ledger update request.

[0726] It should be understood that the specific processes of steps 1801 to 1803 are the same as those of steps 1601 to 1603 in method 1600 above. Please refer to the detailed explanation above, and it will not be repeated here.

[0727] In step 1804, the third device sends a fourth request message to the fifth device, the fourth request message carrying the first public key. Accordingly, the fifth device receives the fourth request message from the third device.

[0728] This fourth request message can also be called a registration request, for example.

[0729] Unlike method 1600, in this embodiment, the fifth device is not a device in the network of the first DL. Therefore, the fifth device is responsible for issuing the first key credential, but not for generating and publishing the first digital identity. Thus, the third device only needs to send the first public key used to generate the first key credential to the fifth device.

[0730] In step 1805, the fifth device generates the first key credential.

[0731] Optionally, the first key credential is generated based on the first public key. Step 1805 may specifically include: the fifth device signing the first public key based on the private key of the fifth device to obtain the first key credential.

[0732] Optionally, the first key credential may also be generated based on the first identifier. Step 1805 may specifically include: the fifth device signing the first identifier and the first public key based on the private key of the fifth device to obtain the first key credential. In this case, before step 1805, the method may further include: the fifth device generating the first identifier.

[0733] The fifth device can generate the first identifier based on the parameters used to generate the first identifier and the algorithm used to generate the first identifier.

[0734] As described in step 601 of method 600, the parameters used to generate the first identifier may include one or more of the following: a second identifier, a first public key, an identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, and blockchain time. Therefore, in addition to carrying the aforementioned first public key and second identifier, the first request message in this embodiment may optionally also carry one or more of the following: the identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, or blockchain time. Correspondingly, the fourth request message and the sixth request message may also optionally carry one or more of the following: the second identifier, the identifier of the first DL, a timestamp, the MAC address of the first device, a random number, a block hash, or blockchain time. It is understood that if the first identifier is generated based on the first public key and / or the second identifier, the first request message, the fourth request message, and the sixth request message may also omit the timestamp, the MAC address of the first device, the random number, the block hash, and the blockchain time.

[0735] In this embodiment, since the algorithm used to generate the first identifier in the first DL network is different from the algorithm used to generate the second identifier in the second DL network, the fifth device can first obtain the algorithm used to generate the first identifier in the first DL network, and then generate the first identifier based on that algorithm.

[0736] Optionally, the first key credential is also generated based on the identifier of the first DL. Step 1805 may specifically include: the fifth device signing the first identifier, the first public key, and the identifier of the first DL based on the private key of the fifth device to obtain the first key credential.

[0737] The identifier of the first DL can be carried by the first device in the first request message; that is, the first request message can also carry the identifier of the first DL. The identifier of the first DL can be carried in the first request message so that it can be sent to the fifth device through the fourth device and the third device. The fifth device can obtain the identifier of the first DL in the fourth request message received from the third device.

[0738] Alternatively, the identifier of the first DL can also be determined by the fifth device itself. In this embodiment, since the public key of the fifth device is pre-set in the first DL, for example, pre-stored in a device in the network of the first DL, the fifth device can also determine the identifier of the first DL itself.

[0739] In this embodiment, since the public key of the fifth device may only be preset in the first DL, or can only be obtained by devices in the network of the first DL, the fifth device can determine to generate the first key credential for use in the first DL after receiving the fourth request message from the third device, and does not necessarily need to carry the identifier of the first DL after the first request message.

[0740] For a more detailed explanation of how the fifth device generates the first key credential, please refer to the relevant descriptions in step 601 of method 600 and step 1520 of method 1500 in conjunction with Figure 16, which will not be repeated here.

[0741] In step 1806, the fifth device sends a third response message to the third device, the third response message carrying the first key credential. Correspondingly, the third device receives the third response message from the fifth device.

[0742] This third response message can be considered a response to the fourth request message in step 1804. This third response message can also be called a registration response, corresponding to the registration request.

[0743] In this embodiment, since IDM2 is not a node in the first DL network, or in other words, IDM2 does not belong to the DL network, IDM1 cannot determine which node to send KC2 to. Therefore, IDM2 can send the generated KC2 to the third device for processing.

[0744] In step 1807, the third device generates the first digital identity based on the information in the first key credential and the second digital identity.

[0745] It should be understood that the specific process of step 1807 is the same as that of step 604 of method 600, and can be referred to in the detailed explanation above, so it will not be repeated here.

[0746] Optionally, prior to step 1807, the method further includes step 1807': a third device verifies the signature of the first key credential. Step 1807 can be performed if the verification is successful.

[0747] As mentioned earlier, although the fifth device is not a node in the first DL's network, its public key can be pre-installed on the first DL, for example, stored in a device within the first DL's network, or obtained by a device in the first DL's network from another node (such as SEPP). Therefore, the third device can obtain the fifth device's public key and verify the signature of the first key credential based on the fifth device's public key to ensure that the first key credential was issued by the fifth device.

[0748] In step 1808, the third device publishes the first digital identity in the first DL.

[0749] It should be understood that the specific process of step 1808 is the same as that of step 608 in method 600, as can be seen in the detailed explanation above, and will not be repeated here.

[0750] In step 1809, the third device sends a fourth response message to the fourth device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the fourth device receives the fourth response message from the third device.

[0751] This fourth response message can be considered a response to the sixth request message in step 1803. This fourth response message can also be called a ledger update response, corresponding to the ledger update request.

[0752] Optionally, the method further includes step 1809', in which the third device sends the first key credential to the fourth device. Accordingly, the fourth device receives the first key credential from the third device.

[0753] It should be understood that the first key credential does not necessarily have to be sent to the fourth device after step 1808. The third device may also send the first key credential to the fourth device after receiving it from the fifth device in step 1806, so that it can be forwarded to the first device through the fourth device. Therefore, step 1809' may also be executed after step 1806.

[0754] Optionally, the method further includes step 1809”, whereby the third device sends a verification path to the fourth device, the verification path indicating the storage path of the first digital identity in the first DL. Accordingly, the fourth device receives the verification path from the third device.

[0755] Optionally, the verification path can be sent encrypted. That is, in step 1809, the third device sends the encrypted verification path to the fourth device.

[0756] In one possible design, the first key credential and / or authentication path are carried in the fourth response message. In this case, for the third device, step 1819 and steps 1809' and / or 1809" can be combined into a single sending step; for the fourth device, step 1819 and steps 1809' and / or 1809" can be combined into a single receiving step.

[0757] In step 1810, the fourth device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, namely, the first identifier.

[0758] In step 1811, the fourth device sends a first response message to the first device, which indicates the publication result of the first digital identity in the first DL. Accordingly, the first device receives the first response message from the fourth device.

[0759] Optionally, the method further includes step 1811', in which the fourth device sends a first key credential to the first device. Accordingly, the first device receives the first key credential from the fourth device.

[0760] Optionally, the method further includes step 1811", whereby the fourth device sends a verification path to the first device. Accordingly, the first device receives the verification path from the fourth device.

[0761] Optionally, the verification path can be sent encrypted. That is, in step 1811", the fourth device sends the encrypted verification path to the first device.

[0762] In one possible design, the first key credential and / or authentication path are carried in the first response message. In this case, for the fourth device, step 1811, step 1811', and / or 1811" can be combined into a single sending step; for the first device, step 1811, step 1811', and / or 1811" can be combined into a single receiving step.

[0763] Optionally, the method further includes step 1811”', whereby the first device determines, based on the verification path, that the first digital identity is stored in the first DL.

[0764] It should be understood that the specific process of step 1811” is the same as the specific process of 608” in method 600. Please refer to the detailed explanation above, which will not be repeated here.

[0765] In step 1812, the first device updates the second digital identity, and the updated second digital identity includes the identifier of the first digital identity, namely, the first identifier.

[0766] In step 1813, the first device updates the first digital identity.

[0767] It should be understood that the specific processes and methods of steps 1812 and 1813 are the same as those of steps 609 and 610 in 600. Please refer to the detailed explanation above, which will not be repeated here.

[0768] Optionally, the method further includes: the first device storing the correspondence between the first digital identity and the identifier of the first DL.

[0769] It should be understood that in this embodiment, the fourth device and the first device can respectively store the correspondence between the first digital identity and the identifier of the first DL. For the specific process of the fourth device and the first device storing the correspondence between the first digital identity and the identifier of the first DL, please refer to the detailed description of the fourth device storing the correspondence between the first digital identity and the identifier of the first DL in method 600 above, which will not be repeated here.

[0770] Based on the above scheme, when the first device needs to join the first DL, it can initiate a request to the third device in the first DL's network. The third device in the first DL's network can issue a first key credential to it through the fifth device corresponding to IDM2. Nodes in the first DL's network can generate a first digital identity for publication in the first DL based on the first key credential and the information in the obtained second digital identity. Thus, cross-ledger publication of digital identities between different DL networks is realized, thereby enabling cross-ledger authentication of the first device. The authentication of digital identities is no longer limited to the same DL's network.

[0771] Furthermore, since the method 1600 shown in FIG18A and the method 1600 shown in FIG18B are based on the method 1500 shown in FIG15, they have the same technical effects as the method 1500, and will not be described again for the sake of brevity.

[0772] The above, in conjunction with Figures 15 and 18A to 18B, details the specific flow of the communication method provided in this application when the first key credential is generated by the fifth device corresponding to IDM2. In another implementation, the first key credential can also be generated by other devices, such as devices in the network of the first DL, such as DLE2-b when DLE2-a and DLE2-b are deployed separately as shown in the above embodiments, or DLE2 when DLE2-a and DLE2-b are co-located. For ease of explanation, the generation of the first key credential and the generation and issuance of the first digital identity will be described below using a third device as an example. It should be understood that this third device is only a device corresponding to DLE2-b from a functional perspective; it can be an independent physical entity when DLE2-a and DLE2-b are deployed separately, or it can be a module when DLE2-a and DLE2-b are deployed separately and co-located.

[0773] The specific flow of the communication method provided in this application when the third device generates the first key credential will be described below with reference to Figures 19 to 21.

[0774] It should be noted that, in this embodiment, the third device can hold the private key of the first DL. The private key of the first DL can be the private key in the public-private key pair generated by the operator when the first DL is created. The public key in the public-private key pair of the first DL can be uploaded to the first DL; that is, the data stored in the first DL includes the public key of the first DL. For example, the first piece of data stored in the first DL is the identifier of the first DL and the public key of the first DL. The private key in the public-private key pair of the first DL can be pre-configured in some devices within the first DL's network. One possible implementation is that the first DL is a blockchain, and the private key of the first DL is pre-installed in a smart contract, which is installed in some devices within the first DL's network. The first key credential can be obtained by signing based on the private key of the first DL; therefore, the public key of the first DL can be used to verify the first key credential. Since the first key credential is issued based on the private key of the first DL, the first digital identity generated based on the first key credential can be regarded as a digital identity issued by the first DL.

[0775] It should be understood that the first DL can be participated in by one operator, and the public and private keys of the first DL can be generated by the operator in the network participating in the first DL; the first DL can also be participated in by multiple operators, and the public and private key pair of the first DL can also be generated through negotiation among multiple operators in the network participating in the first DL.

[0776] Figure 19 is another schematic flowchart of the communication method provided in an embodiment of this application. The method 1900 shown in Figure 19 can be executed by a third device. The method 1900 shown in Figure 19 will be described in detail below.

[0777] In step 1910, a sixth request message is received from the fourth device, which carries the first public key.

[0778] In this embodiment, the second public key used to generate the first public key can be carried in a sixth request message sent by the fourth device to the third device. This sixth request message can be used to request the third device to generate the first key credential.

[0779] For security reasons, the first device does not send out the symmetric key, but instead sends the public key from the asymmetric key. In other words, in this embodiment, the first key used to generate the first key credential is the public key, i.e., the aforementioned first public key. This first key credential can also be called the first public key credential.

[0780] In step 1920, a first key credential is generated based on the first public key.

[0781] The third device can generate a first key credential based on the first public key carried in the received sixth request message.

[0782] As mentioned earlier, when the first DL is created, the operator can generate a public-private key pair for the first DL, including the public key and the private key of the first DL. The public key of the first DL can be uploaded to DL2, meaning that devices in the network of the first DL can obtain the public key of the first DL by querying the first DL. The private key of the first DL can be obtained by some devices in the network of the first DL. For example, when DLE2-a and DLE2-b are deployed separately, it can be pre-configured in DLE2-b; or when DLE2-a and DLE2-b are co-located, it can be pre-configured in DLE2.

[0783] In this embodiment, the first key credential can be obtained by a third device signing the first public key based on the private key of the first DL. Step 1920 may specifically include: signing the first public key based on the private key of the first DL to obtain the first key credential.

[0784] Optionally, the first key credential is also generated based on the first identifier. Step 1920 may specifically include: signing the first public key and the first identifier based on the private key of the first DL to obtain the first key credential.

[0785] Optionally, the first key credential is also generated based on the identifier of the first DL. Step 1920 may specifically include: signing the first public key, the first identifier, and the identifier of the first DL based on the private key of the first DL to obtain the first key credential. The identifier of the first DL may be obtained by the third device itself, for example, the third device is a device in the network of the first DL, or the identifier of the first DL may be carried in the sixth request message; this application does not limit this. In other words, the sixth request message may optionally also carry the identifier of the first DL.

[0786] For a more detailed explanation of how to obtain the first key credential by signing based on the private key of the first DL, please refer to the relevant description in step 601 of method 600 above, which will not be repeated here.

[0787] The first identifier may be generated by a third device. Optionally, the sixth request message may also carry an identifier of the algorithm used to generate the first identifier, and optionally, one or more of the following: a second identifier, an identifier of the first DL, a random number, a timestamp, a block hash, a blockchain time, or a MAC address.

[0788] The fifth device may generate a first identifier based on the parameters obtained from the sixth request message. The generation of this first identifier is described in step 601 of method 600 above, and will not be repeated here.

[0789] Figure 20 is another schematic diagram of the first key certificate provided in the embodiments of this application. Figure 20 still uses KC2 as an example, showing another possible example of the first key certificate. Comparing Figures 7, 11, and 13, it can be found that the KC2 shown in Figure 20 differs from the KC2 shown in Figures 7, 11, and 13 in that the Issuer ID shown in Figure 20 indicates the DL2 ID, indicating that the issuer of the KC2 is DL2, i.e., an example of the first DL. Since the KC2 is obtained by signing other information in the KC2 based on the private key of the first DL, the signature is correspondingly represented as Sig. DL2 Furthermore, since the first key in this embodiment is an asymmetric key, Claims indicates PK2, i.e., an example of the first public key. Other fields are the same as in Figures 7, 11, and 13, and can be found in step 601' of method...

Claims

1. A communication method characterized by comprising: The method includes: Send a first request message, the first request message carrying at least one parameter for publishing a first digital identity of the first device in a first distributed ledger DL, wherein some or all of the at least one parameter is obtained based on a second digital identity of the first device that has been published in a second DL; Receive a first response message, which indicates the publication result of the first digital identity in the first DL.

2. The method of claim 1, wherein, The method further includes: Save the first digital identity.

3. The method of claim 1 or 2, wherein, The method further includes: The second digital identity is updated, and the updated second digital identity includes a first identifier, which is used to identify the first device in the first DL.

4. The method of claim 3, wherein, The updated second digital identity indicates one or more of the following: the domain identifier of the second digital identity, the identifier of another digital identity obtained based on the second digital identity, or the domain identifier of the verifiable credential (VC) of the second digital identity.

5. The method of any one of claims 1 to 4, wherein, The at least one parameter includes: a second identifier and a first key credential, wherein the second identifier is used to identify the first device in the second DL, and the first key credential is used to generate the first digital identity; Before sending the first request message, the method further includes: A first public key and a first private key are generated based on the second public key and / or the second private key corresponding to the second digital identity. The first public key and the first private key are used for authentication of the first device in the network of the first DL. The first public key is signed based on the first private key to obtain the first key credential.

6. The method of claim 5, wherein, The method further includes: Obtain a first identifier, which is used to identify the first device in the first DL; The step of signing the first public key based on the first private key to obtain the first key credential includes: The first key credential is obtained by signing the first public key and the first identifier based on the first private key.

7. The method of claim 6, wherein, The step of generating a first public key and a first private key based on the second public key and / or the second private key corresponding to the second digital identity includes: The first public key and the first private key are generated based on the second public key and / or the second private key corresponding to the second digital identity, and one or more of the following: timestamp, the media access control MAC address of the first device, a random number, a block hash, or a blockchain time.

8. The method of claim 7, wherein, The at least one parameter also includes one or more of the following: timestamp, MAC address of the first device, random number, block hash, or blockchain time.

9. The method of any one of claims 1 to 4, wherein, The at least one parameter includes: a second identifier and an identifier of the first DL, wherein the second identifier is used to identify the first device in the second DL.

10. The method of claim 9, wherein, The first response message carries a first key credential, which is obtained by signing the first key with the private key of the second device. The first key is used for the authentication of the first device in the network of the first DL. The public key of the second device is preset in the first DL and the second DL.

11. The method of claim 10, wherein, The first key credential is obtained by signing the first key with the private key of the second device, including: the first key credential is obtained by signing the first key and the first identifier with the private key of the second device, and the first identifier is used to identify the first device in the first DL; The at least one parameter further includes one or more of the following parameters for generating the first identifier: the identifier of the algorithm for generating the first identifier, a timestamp, the MAC address of the first device, a random number, a block hash, or a blockchain time.

12. The method of any one of claims 1 to 4, wherein, The at least one parameter includes: a second identifier and a first key credential, wherein the second identifier is used to identify the first device in the second DL, the first key credential is obtained by signing the first key with the private key of the second device, and the first key is used for authentication of the first device in the network of the first DL; Before sending the first request message, the method further includes: Send a second request message to the second device. The second request message is used to request the second device to generate the first key certificate. The second request message carries parameters for generating the first key certificate. Receive the first key credential from the second device.

13. The method of claim 12, wherein, The first key credential is obtained by signing the first key with the private key of the second device, including: the first key credential is obtained by signing the first key and the first identifier with the private key of the second device, and the first identifier is used to identify the first device in the first DL; The at least one parameter further includes one or more of the following parameters for generating the first identifier: the identifier of the algorithm for generating the first identifier, the identifier of the first DL, the timestamp, the MAC address of the first device, a random number, a block hash, or the blockchain time.

14. The method of any one of claims 1 to 4, wherein, The at least one parameter includes: a second identifier and a first public key, wherein the second identifier is used to identify the first device in the second DL, and the first public key is used for authentication of the first device in the network of the first DL.

15. The method of claim 14, wherein, The first response message carries a first key credential, which is obtained by signing the first public key based on the private key of the fifth device or the private key of the first DL.

16. The method of claim 15, wherein, The first key credential is obtained by signing the first public key based on the private key of the fifth device or the private key of the first DL, including: the first key credential is obtained by signing the first public key and the first identifier based on the private key of the fifth device or the private key of the first DL, wherein the first identifier is used to identify the first device in the first DL; The at least one parameter also includes one or more of the following parameters used to generate the first identifier: timestamp, MAC address of the first device, random number, block hash, or blockchain time.

17. The method of any one of claims 1 to 16, wherein, The method further includes: Receive a verification path, the verification path being used to indicate the storage path of the first digital identity in the first DL; Obtain the first digital identity; Based on the verification path, it is determined that the first digital identity is published in the first DL.

18. The method of claim 17, wherein, Obtaining the first digital identity includes: Generate the first digital identity; or Query the first digital identity in the first DL.

19. The method of any one of claims 1 to 18, wherein, The method further includes: Save the correspondence between the first digital identity and the identifier of the first DL.

20. A method of communication, comprising: The method includes: Receive a third request message from the first device, the third request message carrying an identifier of a first distributed ledger (DL), the first DL being the DL for which the first device will issue a first digital identity; Generate a first key credential, which is obtained by signing a first key. The first key is generated based on a second key. The first key is used for authentication of the first device in the network of the first DL, and the second key is used for authentication of the first device in the network of the second DL where a second digital identity has been issued. Send the first key credential to the first device.

21. The method of claim 20, wherein, The method further includes: Obtain the first key; The generation of the first key credential includes: The first key credential is obtained by signing the first key with the private key of the second device.

22. The method of claim 21, wherein, The second key is a second public key, and the first key includes a first public key and a first private key. The third request message also carries the second public key and an identifier of the algorithm used to generate the first key. Obtaining the first key includes: Based on the second public key and the algorithm used to generate the first key, the first public key and the first private key are generated; The step of signing the first key with the private key of the second device to obtain the first key certificate includes: The first key credential is obtained by signing the first public key with the private key of the second device.

23. The method of claim 21, wherein, The second key is a symmetric key, the first key is also a symmetric key, and the third request message also carries an identifier of the algorithm used to generate the first key; Obtaining the first key includes: The first key is generated based on the second key and the identifier of the algorithm used to generate the first key.

24. The method of claim 21, wherein, The method further includes: Obtain the first identifier, which is used to identify the first device in the first DL; The step of signing the first key with the private key of the second device to obtain the first key certificate includes: The first key credential is obtained by signing the first key and the first identifier using the private key of the second device.

25. The method of any one of claims 20 to 24, wherein, The third request message also carries a second identifier, which is used to identify the first device in the second DL; The method further includes: Information from the second digital identity is obtained based on the second identifier; The first key credential and the information in the second digital identity are sent to a third device in the network of the first DL. The information in the second digital identity and the first key credential are used to generate the first digital identity.

26. The method of any one of claims 20 to 24, wherein, The third request message also carries a second identifier, which is used to identify the first device in the second DL; the method further includes: The second identifier and the first key credential are sent to a fourth device in the network of the second DL. The second identifier is used to obtain information in the second digital identity. The information in the second digital identity and the first key credential are used to generate the first digital identity.

27. A method of communication, comprising: The method includes: Receive a fourth request message from a third device, the fourth request message carrying a first public key, the first public key being generated based on a second public key and / or a second private key, the first public key being used for authentication of the first device in a first distributed ledger DL network where a first digital identity is to be issued, and the second public key and the second private key being used for authentication of the first device in a second DL network where a second digital identity has been issued. Generate a first key credential, which is obtained by signing the first public key with the private key of the fifth device; The first key credential is sent to the third device.

28. The method of claim 27, wherein, The method further includes: Generate a first identifier, which is used to identify the first device in the first DL; The generation of the first key credential includes: The first key credential is obtained by signing the first identifier and the first public key using the private key of the fifth device.

29. The method of claim 27 or 28, wherein, The fourth request message also carries information from the second digital identity, and the method further includes: The first digital identity is generated based on the information in the first key credential and the second digital identity; Publish the first digital identity in the first DL.

30. A method of communication, comprising: include: A fifth request message is received, which is used to request the publication of a first digital identity of a first device in a first distributed ledger (DL). The fifth request message carries: a second identifier and a first key credential. The second identifier is used to identify the first device in a second DL where the second digital identity has been published. The first key credential is obtained by signing a first public key. The first public key is used for the authentication of the first device in the network of the first DL. Based on the second identifier, obtain the information in the second digital identity; A sixth request message is sent to a third device in the network of the first DL. The sixth request message is used to request the generation of the first digital identity. The sixth request message carries the first key credential used to generate the first digital identity and information from the second digital identity.

31. A method of communication, comprising: include: A first request message is received from a first device. The first request message is used to request the publication of the first device's first digital identity in a first distributed ledger (DL). The first request message carries: a first public key and a second identifier. The second identifier is used to identify the first device in the second DL. The first public key is used for the authentication of the first device in the network of the first DL. The second identifier is used to identify the first device in the second DL. Based on the second identifier, obtain the information in the second digital identity; A sixth request message is sent to a third device in the network of the first DL. The sixth request message is used to request the generation of the first digital identity. The sixth request message carries the first public key and information from the second digital identity. The first public key is used to generate a first key credential, and the first key credential and information from the second digital identity are used to generate the first digital identity.

32. The method of claim 30 or 31, wherein, The method further includes: Receive a fourth response message from the third device, the fourth response message being used to indicate the publication result of the first digital identity in the first DL, and the fourth response message carrying the first key credential; A first response message is sent to the first device. The first response message is used to indicate the publication result of the first digital identity in the first DL, and the first response message carries the first key credential.

33. A method of communication, comprising: The method includes: Receive a sixth request message from a fourth device, the sixth request message carrying a first public key, the first public key being generated based on a second public key and / or a second private key, the first public key being used for authentication of the first device in a first distributed ledger DL network where a first digital identity is to be issued, and the second public key and / or the second private key being used for authentication of the first device in a second DL network where a second digital identity has already been issued; Generate a first key credential, which is obtained by signing the first public key with the private key of the first DL; The first key credential is sent to the fourth device.

34. The method of claim 23, wherein, The method further includes: Generate a first identifier, which is used to identify the first device in the first DL; The generation of the first key credential includes: The first key credential is obtained by signing the first public key and the first identifier using the private key of the first DL.

35. The method of claim 34, wherein, The sixth request message also carries information from the second digital identity, and the method further includes: The first digital identity is generated based on the information in the first key credential and the second digital identity; Publish the first digital identity in the first DL.

36. A communications device, characterized by It includes one or more functional units or modules for performing the method as described in any one of claims 1 to 19, or for performing the method as described in any one of claims 20 to 26, or for performing the method as described in any one of claims 27 to 29, or for performing the method as described in any one of claims 30 to 32, or for performing the method as described in any one of claims 33 to 35.

37. A communications device, characterized by The device includes a processor for executing program code to cause the communication device to implement the method as described in any one of claims 1 to 19, or the method as described in any one of claims 20 to 26, or the method as described in any one of claims 27 to 29, or the method as described in any one of claims 30 to 32, or the method as described in any one of claims 33 to 35.

38. A communication system, characterized by It includes one or more of the following: a first device, a second device, a third device, a fourth device, and a fifth device; the first device is used to perform the method as described in any one of claims 1 to 19, the second device is used to perform the method as described in any one of claims 20 to 26, the third device is used to perform the method as described in any one of claims 27 to 29, the fourth device is used to perform the method as described in any one of claims 30 to 32, and the fifth device is used to perform the method as described in any one of claims 33 to 35.

39. A computer readable storage medium having stored thereon a computer program, 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 19 to be executed, or causes the method as described in any one of claims 20 to 26 to be executed, or causes the method as described in any one of claims 27 to 29 to be executed, or causes the method as described in any one of claims 30 to 32 to be executed, or causes the method as described in any one of claims 33 to 35 to be executed.

40. A computer program product, characterised in that, The method includes a computer program that, when executed, causes the method as described in any one of claims 1 to 19 to be performed, or causes the method as described in any one of claims 20 to 26 to be performed, or causes the method as described in any one of claims 27 to 29 to be performed, or causes the method as described in any one of claims 30 to 32 to be performed, or causes the method as described in any one of claims 33 to 35 to be performed.

Images