Identity information migration method and device

Abstract

The invention provides an identity information migration method and device, and relates to the technical field of communication. The method comprises the steps of obtaining information of at least one voucher issuer maintained by a first distributed account book and information of a first voucher, and determining whether to migrate the first voucher to the first distributed account book or not according to the information of the at least one voucher issuer. Wherein the first voucher is the voucher of the first node in the second distributed account book. Through the method, whether the first voucher is migrated to the first distributed account book or not can be determined. If the first voucher can be migrated to the first distributed account book, the first distributed account book can verify the identity of the first node through the first voucher, so that the service corresponding to the first node is executed, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to methods and apparatus for migrating identity information. Background Technology

[0002] A distributed ledger (DL) is a database that is shared, replicated, and synchronized among network members. Distributed ledgers can record transactions between network members, such as the exchange of assets or data. Essentially, a distributed ledger is a shared database where the data or information stored is characterized by being unforgeable, fully traceable, auditable, transparent, and collectively maintained. Therefore, distributed ledger technology has a high probability of being introduced into communication networks in the future to improve communication network security.

[0003] If distributed ledger technology is introduced into communication networks, multiple operators can establish distributed ledgers based on equipment within the network, such as access network equipment or core network equipment. A distributed ledger can store the identity information of its nodes, used to verify the node's identity when it joins the network. However, if a node wants to join another distributed ledger, the other ledger may be unable to verify its identity, preventing the corresponding services from executing and thus impacting user experience. Summary of the Invention

[0004] This application provides a method and apparatus for migrating identity information, which can migrate the credentials of a node in one distributed ledger to another distributed ledger, enabling the other distributed ledger to verify the identity of the node and improve user experience.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, a method for migrating identity information is provided, which can be executed by a second node. Here, the second node can refer to the second node itself, or to a processor, circuit, module, logic node, chip, or chip system within the second node that implements the method. For example, the second node can be any node in the first distributed ledger, such as a terminal, a radio access network (RAN) node, or a network element in the core network. Alternatively, the second node can be a node related to the first distributed ledger, such as an ID management (IDM) network element, a decentralized shared profile repository (DSPR) network element, a distributed ledger anchor function (DLAF) network element, or a unified data management (UDM) network element.

[0007] The method includes: obtaining first information, obtaining first identity information, and determining whether to migrate the first credential to the first distributed ledger based on the first information. The first information includes information about at least one credential issuer maintained by the first distributed ledger. The first identity information includes information about the first credential, which is a credential of a first node in a second distributed ledger.

[0008] Based on the method provided in the first aspect above, after the second node obtains the first identity information, it can determine whether to migrate the first credential to the first distributed ledger based on the credential issuer information maintained by the first distributed ledger. If the first credential is migrated to the first distributed ledger, then the nodes in the first distributed ledger can verify the first node based on the first credential, enabling the first node's business to be executed, thereby improving the user experience.

[0009] In one possible implementation, the first credential is issued by a first issuer; determining whether to migrate the first credential to the first distributed ledger based on the first information includes: if the first issuer is at least one credential issuer, determining to migrate the first credential to the first distributed ledger; or, if the first issuer is not at least one credential issuer, determining not to migrate the first credential to the first distributed ledger.

[0010] Based on the above possible implementation methods, the second node can determine whether to migrate the first credential to the first distributed ledger.

[0011] In one possible implementation, the information of any one of the at least one credential issuers includes the credential issuer's identifier and the credential issuer's key information, and the information of the first credential includes the first issuer's signature of the first credential; the above-mentioned determination to migrate the first credential to the first distributed ledger if the first issuer belongs to at least one credential issuer includes: if the first issuer belongs to at least one credential issuer, and the signature of the first credential is successfully verified according to the first issuer's key information in the first information, determining to migrate the first credential to the first distributed ledger.

[0012] Based on the above possible implementation methods, the second node can determine that the first issuer belongs to at least one credential issuer, and if the signature of the first credential is successfully verified according to the key information of the first issuer in the first information, then migrate the first credential to the first distributed ledger.

[0013] In one possible implementation, the information of the first credential may also include at least one of the following: the identifier of the first issuer, the serial number of the first credential, the hash value of the first credential, or the content of the first credential declaration.

[0014] Based on the above possible implementation methods, the above information can be migrated to the first distributed ledger.

[0015] In one possible implementation, the method further includes: upon determining that the first credential will be migrated to the first distributed ledger, sending a first confirmation message to confirm that the first credential will be migrated to the first distributed ledger.

[0016] Based on the above possible implementation methods, the node that receives the first confirmation information, such as the third node, can determine to migrate the first voucher to the first distributed ledger.

[0017] In one possible implementation, the second node is any node in the first distributed ledger. The first identity information is received by the second node after being forwarded by the first security edge protection agent and the second security edge protection agent. The first security edge protection agent is the security edge protection agent corresponding to the first distributed ledger, and the second security edge protection agent is the security edge protection agent corresponding to the second distributed ledger.

[0018] Based on the above possible implementation methods, the first identity information can reach the second node after being forwarded by the first security edge protection agent and the second security edge protection agent.

[0019] In one possible implementation, the issuer of the first credential belongs to at least one credential issuer maintained by the second distributed ledger, and the domain to which the first credential belongs includes the first distributed ledger.

[0020] Based on the above possible implementation methods, when the first credential meets the above conditions, it can be migrated to the first distributed ledger.

[0021] In one possible implementation, the method further includes: receiving information about a first verification path, wherein the first verification path is the verification path of the transaction for migrating the first credential in the second distributed ledger; and determining, based on the information about the first verification path, that a transaction for migrating the first credential exists in the second distributed ledger.

[0022] Based on the above possible implementation methods, the second node can determine that there is a transaction in the second distributed ledger that migrates the first voucher.

[0023] In one possible implementation, the method further includes: generating information about a first transaction, wherein the first transaction is a transaction for migrating a first credential, and the information about the first transaction includes an identifier of a second distributed ledger, an identifier of the digital identity of a first node, and information about the first credential; and sending the information about the first transaction to nodes in the first distributed ledger.

[0024] Based on the above possible implementation methods, the second node can put the first transaction on the blockchain.

[0025] In one possible implementation, the method further includes: sending a first request to a first node, the first request being used to request the content of a first credential statement, the first request including the identifier of the digital identity of the first node and the serial number of the first credential; and receiving a first response from the first node, the first response including the content of the first credential statement.

[0026] Based on the above possible implementation methods, the content of the first credential declaration can be obtained from the first node.

[0027] In one possible implementation, the first response further includes access policy information of the first credential; the method further includes setting the access policy of the first credential according to the access policy information of the first credential.

[0028] Based on the above possible implementation methods, an access policy for the first credential can be set.

[0029] Secondly, a method for migrating identity information is provided, which can be executed by a third node. Here, the third node can refer to the third node itself, or to a processor, circuit, module, logic node, chip, or chip system within the third node that implements the method. For example, the third node can be any node in the second distributed ledger, such as a terminal, RAN node, or network element in the core network. Alternatively, the third node can be an IDM network element, DSPR network element, DLAF network element, or UDM network element, etc.

[0030] The method includes: obtaining second information, obtaining first identity information, and determining, based on the second information, to send the first identity information to a node in a first distributed ledger. The second information includes information about at least one credential issuer maintained by the second distributed ledger. The first identity information includes information about a first credential, where the first credential is a credential of a first node, and the first node is a node in the second distributed ledger.

[0031] Based on the method provided in the second aspect above, the third node can determine whether to send the first identity information to the nodes in the first distributed ledger based on the information of the credential issuer maintained by the second distributed ledger, so that the nodes in the first distributed ledger can determine whether to migrate the first credential to the first distributed ledger.

[0032] In one possible implementation, the first credential is issued by a first issuer; the determination to send the first identity information to a node in the first distributed ledger based on the second information includes: if the first issuer belongs to at least one credential issuer and the domain to which the first credential belongs includes the first distributed ledger, determining to send the first identity information to a node in the first distributed ledger.

[0033] Based on the above possible implementations, the third node may determine to send the first identity information to the nodes in the first distributed ledger if the first issuer belongs to at least one credential issuer and the domain to which the first credential belongs includes the first distributed ledger.

[0034] In one possible implementation, the information of the first credential includes at least one of the following: the identifier of the issuer of the first credential, the serial number of the first credential, the hash value of the first credential, or the content of the first credential declaration.

[0035] Based on the above possible implementation methods, the third node can send the above information to the nodes in the first distributed ledger.

[0036] In one possible implementation, obtaining the first identity information includes: sending first query information, the first query information indicating the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the identifier of the first distributed ledger; receiving a first query result, the first query result including the serial number of the first credential, the first query result being used to obtain information about the first credential.

[0037] Based on the above possible implementation methods, the third node can obtain the first identity information.

[0038] In one possible implementation, the method further includes: sending first identity information to nodes in the first distributed ledger through a first security edge protection agent and a second security edge protection agent; wherein the first security edge protection agent is the security edge protection agent corresponding to the first distributed ledger, and the second security edge protection agent is the security edge protection agent corresponding to the second distributed ledger.

[0039] Based on the above possible implementation methods, the third node can send the first identity information to the nodes in the first distributed ledger through the first and second secure edge protection proxies.

[0040] In one possible implementation, the method further includes: receiving first confirmation information from a node in the first distributed ledger, the first confirmation information being used to confirm the migration of the first credential to the first distributed ledger.

[0041] Based on the above possible implementation methods, the third node can confirm the migration of the first voucher to the first distributed ledger based on the first confirmation information.

[0042] In one possible implementation, the method further includes: sending information about a first verification path to a node in a first distributed ledger, wherein the first verification path is the verification path of the transaction that migrates the first credential in a second distributed ledger.

[0043] Based on the above possible implementation methods, the node that receives the information of the first verification path, such as the second node, can determine that there is a transaction in the second distributed ledger that migrates the first voucher.

[0044] In one possible implementation, the method further includes: generating information for a second transaction, the second transaction being a transaction for migrating a first credential, the information for the second transaction including the identifier of the first distributed ledger, the identifier of the digital identity of the first node, and the information of the first credential; and sending the information for the second transaction to nodes in the second distributed ledger.

[0045] Based on the above possible implementation methods, the third node can put the second transaction on the blockchain.

[0046] Thirdly, a method for migrating identity information is provided, which can be executed by a first node. Here, the first node can refer to the first node itself, or to a processor, circuit, module, logic node, chip, or chip system within the first node that implements the method. For example, the first node can be any node in the second distributed ledger, such as a terminal or RAN node.

[0047] The method includes: sending first identity information to a third node in a second distributed ledger, the first identity information including information about a first credential, the first credential being a credential of the first node; receiving second confirmation information from the third node, the second confirmation information being used to confirm the migration of the first credential to the first distributed ledger, the second confirmation information including the sequence number of the first credential and the identifier of the first distributed ledger; and saving the correspondence between the first credential and the first distributed ledger.

[0048] Based on the method provided in the third aspect above, the first node can save the correspondence between the first voucher and the first distributed ledger after the first voucher is migrated to the first distributed ledger, so that the first node can determine which vouchers can be used in the first distributed ledger.

[0049] In one possible implementation, the first credential is issued by a first issuer, and the information of the first credential includes at least one of the following: the identifier of the first issuer, the domain information to which the first credential belongs, the identifier of the digital identity of the first node, the serial number of the first credential, the hash value of the first credential, the content of the first credential declaration, or the signature of the first issuer on the first credential.

[0050] Based on the above possible implementation methods, the first node can send the above information to the third node.

[0051] In one possible implementation, the method further includes: receiving a first request for requesting the content of a first credential declaration, the first request including an identifier of the digital identity of the first node and a serial number of the first credential; and sending a first response including the content of the first credential declaration.

[0052] Based on the above possible implementation methods, the first node can send the content of the first credential statement based on the first request.

[0053] In one possible implementation, the first response may also include access policy information for the first credential.

[0054] Based on the above possible implementation methods, the node that receives the first response can set the access policy information of the first credential.

[0055] Fourthly, a method for migrating identity information is provided, which can be executed by a verification node. Here, the verification node can refer to the verification node itself, or to the processor, circuit, module, logic node, chip, or chip system within the verification node that implements the method. For example, the verification node can be a node in the first distributed ledger, an IDM network element, or a DSPR network element.

[0056] The method includes: receiving a second request, obtaining first information, and verifying a first credential based on the first information and the second request. The second request is used to request verification of the first credential, which is a credential of a first node, and the first node is a node in a first distributed ledger. The second request includes the signature of the first credential issued by the issuer of the first credential. The first information includes information about at least one credential issuer maintained by the first distributed ledger.

[0057] Based on the method provided in the fourth aspect above, the verification node can verify the first credential.

[0058] In one possible implementation, the information of any one of the at least one credential issuers includes the credential issuer's identifier and the credential issuer's key information. The verification of the first credential based on the first information and the second request includes: querying the key information of the issuer of the first credential from the first information according to the second request; and verifying the signature of the first credential based on the key information.

[0059] Based on the above possible implementation methods, the verification node can obtain the key information of the issuer of the first credential according to the second request, and verify the first credential according to the key information.

[0060] In one possible implementation, the second request further includes the domain information to which the first credential belongs; verifying the first credential based on the first information and the second request further includes: verifying whether the domain information to which the first credential belongs includes the identifier of the first distributed ledger.

[0061] Based on the above possible implementation methods, the verification node can also verify whether the domain information to which the first credential belongs includes the identifier of the first distributed ledger.

[0062] In one possible implementation, the method further includes sending the verification result of the first credential.

[0063] Based on the above possible implementation methods, the node that receives the verification result can determine whether the first credential has been successfully verified.

[0064] Fifthly, a communication device is provided for implementing the method provided in the first aspect. This communication device can be the second node in the first aspect. The communication device includes modules, units, or means corresponding to the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0065] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions described in the first aspect and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions described in the first aspect and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0066] In one possible implementation, the processing module is configured to acquire first information, which includes information about at least one credential issuer maintained by the first distributed ledger; the processing module is further configured to acquire first identity information, which includes information about a first credential, which is a credential of a first node in the second distributed ledger; the processing module is further configured to determine, based on the first information, whether to migrate the first credential to the first distributed ledger.

[0067] In one possible implementation, the first credential is issued by a first issuer, and the processing module is specifically configured to determine, if the first issuer is one of the at least one credential issuers, to migrate the first credential to the first distributed ledger; or, if the first issuer is not one of the at least one credential issuers, to determine not to migrate the first credential to the first distributed ledger.

[0068] In one possible implementation, the information of any one of the at least one credential issuers includes the issuer's identifier and key information, and the information of the first credential includes the first issuer's signature of the first credential. The processing module is further configured to determine to migrate the first credential to the first distributed ledger if the first issuer belongs to the at least one credential issuer and the signature of the first credential is successfully verified based on the first issuer's key information in the first information.

[0069] In one possible implementation, the information of the first credential may further include at least one of the following: the identifier of the first issuer, the serial number of the first credential, the hash value of the first credential, or the content of the first credential declaration.

[0070] In one possible implementation, the interface module is configured to send a first confirmation message upon determining that the first credential will be migrated to the first distributed ledger, the first confirmation message being used to confirm the migration of the first credential to the first distributed ledger.

[0071] In one possible implementation, the first identity information is forwarded by a first security edge protection agent and a second security edge protection agent before being received by the second node; wherein the first security edge protection agent is the security edge protection agent corresponding to the first distributed ledger, and the second security edge protection agent is the security edge protection agent corresponding to the second distributed ledger.

[0072] In one possible implementation, the issuer of the first credential belongs to at least one credential issuer maintained by the second distributed ledger, and the domain to which the first credential belongs includes the first distributed ledger.

[0073] In one possible implementation, the interface module is configured to receive information about a first verification path, which is the verification path of the transaction that migrates the first credential in the second distributed ledger; the processing module is further configured to determine, based on the information about the first verification path, that the transaction exists in the second distributed ledger.

[0074] In one possible implementation, the processing module is further configured to generate information about a first transaction, which is a transaction for migrating the first credential. The information about the first transaction includes the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the information about the first credential. The interface module is configured to send the information about the first transaction.

[0075] In one possible implementation, the interface module is configured to send a first request to the first node, the first request being for requesting the content of the first credential declaration, the first request including the identifier of the digital identity of the first node and the serial number of the first credential; the interface module is also configured to receive a first response from the first node, the first response including the content of the first credential declaration.

[0076] In one possible implementation, the first response further includes access policy information of the first credential; the processing module is further configured to set the access policy of the first credential based on the access policy information of the first credential.

[0077] Sixthly, a communication device is provided for implementing the method provided in the second aspect. This communication device can be a third node in the second aspect. The communication device includes modules, units, or means that implement the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0078] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions in the second aspect described above and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions in the second aspect described above and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0079] In one possible implementation, the processing module is configured to acquire second information, the second information including information about at least one credential issuer maintained by the second distributed ledger; the processing module is further configured to acquire first identity information, the first identity information including information about a first credential, the first credential being a credential of a first node, the first node being a node in the second distributed ledger; the processing module is further configured to determine, based on the second information, to send the first identity information to a node in the first distributed ledger.

[0080] In one possible implementation, the first credential is issued by a first issuer, and the processing module is specifically configured to determine, if the first issuer belongs to the at least one credential issuer and the domain to which the first credential belongs includes the first distributed ledger, to send the first identity information to a node in the first distributed ledger.

[0081] In one possible implementation, the information of the first credential includes at least one of the following: the identifier of the issuer of the first credential, the serial number of the first credential, the hash value of the first credential, or the content of the declaration of the first credential.

[0082] In one possible implementation, the processing module is specifically configured to control the interface module to send first query information, the first query information indicating the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the identifier of the first distributed ledger; the processing module is also specifically configured to control the interface module to receive a first query result, the first query result including the serial number of the first credential, the first query result being used to obtain information about the first credential.

[0083] In one possible implementation, the interface module is used to send the first identity information to a node in the first distributed ledger through a first security edge protection proxy and a second security edge protection proxy; wherein the first security edge protection proxy is the security edge protection proxy corresponding to the first distributed ledger, and the second security edge protection proxy is the security edge protection proxy corresponding to the second distributed ledger.

[0084] In one possible implementation, the interface module is configured to receive first confirmation information from a node in the first distributed ledger, the first confirmation information being used to confirm the migration of the first credential to the first distributed ledger.

[0085] In one possible implementation, the interface module is used to send information about a first verification path to a node in the first distributed ledger, the first verification path being the verification path for the transaction that migrates the first credential in the second distributed ledger.

[0086] In one possible implementation, the processing module is further configured to generate information for a second transaction, which is a transaction for migrating the first credential. The information for the second transaction includes the identifier of the first distributed ledger, the identifier of the digital identity of the first node, and the information of the first credential. The interface module is configured to send the information for the second transaction.

[0087] In a seventh aspect, a communication device is provided for implementing the method provided in the third aspect. The communication device can be the first node in the third aspect. The communication device includes modules, units, or means that implement the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0088] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions in the third aspect described above and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions in the third aspect described above and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0089] In one possible implementation, the interface module is configured to send first identity information to a third node in the second distributed ledger, the first identity information including information about a first credential, the first credential being the credential of the first node; the interface module is also configured to receive second confirmation information from the third node, the second confirmation information being used to confirm the migration of the first credential to the first distributed ledger, the second confirmation information including the sequence number of the first credential and the identifier of the first distributed ledger; and the processing module is configured to save the correspondence between the first credential and the first distributed ledger.

[0090] In one possible implementation, the first credential is issued by a first issuer, and the information of the first credential includes at least one of the following: the identifier of the first issuer, the domain information to which the first credential belongs, the identifier of the digital identity of the first node, the serial number of the first credential, the hash value of the first credential, the content of the declaration of the first credential, or the signature of the first issuer on the first credential.

[0091] In one possible implementation, the interface module is further configured to receive a first request for the content of the first credential declaration, the first request including the identifier of the digital identity of the first node and the serial number of the first credential; the interface module is further configured to send a first response including the content of the first credential declaration.

[0092] In one possible implementation, the first response also includes access policy information for the first credential.

[0093] Eighthly, a communication device is provided for implementing the method provided in the fourth aspect above. The communication device can be the verification node in the fourth aspect. The communication device includes modules, units, or means that implement the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0094] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions in the fourth aspect described above and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions in the fourth aspect described above and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0095] In one possible implementation, an interface module is configured to receive a second request for verification of a first credential, the first credential being a credential of a first node, the first node being a node in a first distributed ledger, the second request including a signature of the first credential issued by the issuer of the first credential; a processing module is configured to obtain first information, the first information including information on at least one credential issuer maintained by the first distributed ledger; the processing module is further configured to verify the first credential based on the first information and the second request.

[0096] In one possible implementation, the information of any one of the at least one credential issuers includes the issuer's identifier and key information. The processing module is specifically configured to query the key information of the issuer of the first credential from the first information according to the second request. The processing module is also configured to verify the first credential based on the key information.

[0097] In one possible implementation, the second request also includes the domain information to which the first credential belongs; the processing module is further specifically used to verify whether the domain information to which the first credential belongs includes the identifier of the first distributed ledger.

[0098] In one possible implementation, the interface module is used to send the verification result of the first credential.

[0099] A ninth aspect provides a communication device, comprising: a processor; configured to cause the communication device to perform the method described in any of the preceding aspects by executing a computer program (or computer-executable instructions) stored in a memory, and / or by means of logic circuitry. The communication device may be a second node in the first aspect; or, the communication device may be a third node in the second aspect; or, the communication device may be a first node in the third aspect; or, the communication device may be a verification node in the fourth aspect. Optionally, the number of processors may be one or more.

[0100] In one possible implementation, the communication device also includes a memory.

[0101] In one possible implementation, the processor and memory are integrated together; or, the memory is independent of the processor.

[0102] In one possible implementation, the communication device further includes a communication interface for communicating with other devices, such as transmitting or receiving data and / or signals. Exemplarily, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0103] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of chips or may include chips and other discrete components.

[0104] A tenth aspect provides a communication device, comprising: a processor and an interface circuit; the interface circuit being configured to receive a computer program or instructions and transmit them to the processor; the processor being configured to execute the computer program or instructions to cause the communication device to perform the method described in any of the preceding aspects. The communication device may be a second node in the first aspect; or, the communication device may be a third node in the second aspect; or, the communication device may be a first node in the third aspect; or, the communication device may be a verification node in the fourth aspect. Optionally, the number of processors may be one or more.

[0105] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of chips or may include chips and other discrete components.

[0106] Eleventhly, a computer-readable storage medium is provided, which stores instructions that, when executed on a computer, enable the computer to perform the methods described in any of the preceding aspects.

[0107] In a twelfth aspect, a computer program product containing instructions is provided that, when run on a computer, enables the computer to perform the methods described in any of the preceding aspects.

[0108] In a thirteenth aspect, a communication system is provided, comprising at least one of the following: a second node for performing the method described in the first aspect, a third node for performing the method described in the second aspect, a first node for performing the method described in the third aspect, or a verification node for performing the method described in the fourth aspect.

[0109] The technical effects of any possible implementation of aspects 5 to 13 can be found in the technical effects of any one of aspects 1 to 4 above, or different possible implementations of any one of aspects, and will not be repeated here.

[0110] Understandably, provided that the solutions do not contradict each other, the solutions in the above aspects can be combined. Attached Figure Description

[0111] Figure 1 A schematic diagram of the communication system architecture provided in this application;

[0112] Figure 2A A diagram illustrating the digital identity provided for this application;

[0113] Figure 2B Schematic diagram of the communication network provided in this application Figure 1 ;

[0114] Figure 2C Schematic diagram 2 of the communication network provided in this application;

[0115] Figure 3 A schematic diagram of the hardware structure of the communication device provided in this application;

[0116] Figure 4 Flowchart of the method for migrating identity information provided in this application Figure 1 ;

[0117] Figure 5A Illustration of the general list of issuers provided for this application Figure 1 ;

[0118] Figure 5B Schematic diagram 2 of the general list of issuers provided for this application;

[0119] Figure 6 Flowchart 2 of the method for migrating identity information provided in this application;

[0120] Figure 7 A diagram illustrating the first identity information and the second information provided in this application;

[0121] Figure 8 Flowchart of the method for migrating identity information provided in this application Figure 3 ;

[0122] Figure 9 Flowchart of the method for migrating identity information provided in this application Figure 4 ;

[0123] Figure 10 A schematic diagram of the communication device provided in this application. Detailed Implementation

[0124] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0125] The method provided in this application can be used in various communication systems. For example, the communication system can be a long-term evolution (LTE) system, a 5th generation (5G) communication system, a wireless fidelity (WiFi) system, a 3rd generation partnership project (3GPP) related communication system, a communication system evolving after 5G, or a system integrating multiple systems, etc., without limitation. Among them, 5G can also be referred to as new radio (NR). The following uses... Figure 1 The method provided in this application will be described using the communication system 20 shown as an example. Figure 1 This is merely an illustrative diagram and does not constitute a limitation on the applicable scenarios of the technical solutions provided in this application.

[0126] like Figure 1 The diagram shown is a schematic representation of the architecture of the communication system 20 provided in this application. Figure 1 In the communication system 20, at least one node in the distributed ledger 201 (such as one or more nodes among nodes 2011 to 2018) and at least one node in the distributed ledger 202 (such as one or more nodes among nodes 2021 to 2028).

[0127] In this application, distributed ledgers 201 and 202 can respectively store the identity information of their respective nodes, enabling credential verification between nodes in the distributed ledgers to improve communication security. Taking distributed ledger 201 as an example, if distributed ledger 201 includes nodes 2011 and 2012, then distributed ledger 201 can store the identity information of node 2011 and node 2012, allowing nodes 2011 and 2012 to mutually verify credential information. Different nodes in distributed ledger 201 can have the same or different permissions. Similarly, different nodes in distributed ledger 202 can have the same or different permissions. Taking nodes 2011 and 2013 in distributed ledger 201 as examples, node 2011 can query information in distributed ledger 201 but cannot write information to it. Node 2013 can query information, write information, and participate in consensus in distributed ledger 201. Alternatively, both nodes 2011 and 2013 can query information, write information, and participate in consensus in distributed ledger 201. In this application, "credential verification" can also be referred to as "credential authentication".

[0128] For example, such as Figure 2A As shown, the identity information of any node can include the node's digital identity identifier (ID), the digital identity document, and attribute credential. The digital identity document and attribute credential can also be called a digital identity profile. The digital identity identifier is a globally unique identifier, such as a string of random numbers.

[0129] The digital identity document may include the issuer of the digital identity and authentication information. The authentication information may include the public key of the digital identity. Optionally, the digital identity document may also include the domain ID of the digital identity. The domain ID of the digital identity indicates the domain that can use the digital identity or the domain to which the digital identity belongs, such as one or more distributed ledgers.

[0130] Attribute credentials are issued by organizations or users and endorsed by the issuer. They describe the attributes possessed by the aforementioned nodes, such as "the user corresponding to the node is 18 years of age or older" or "this node has subscribed to a certain service." Attribute credentials may include a serial number (SN), the issuer of the credential (or the identifier of the attribute credential issuer), and the content of the credential claim. The SN is the serial number assigned to the credential by the issuer. The content of the credential claim may include the specific content of the credential, such as "the user corresponding to the node is 18 years of age or older." Optionally, attribute credentials may also include one or more of the following: the identifier of the credential owner, or the domain identifier of the credential. The content of the credential claim and the identifier of the credential owner can be referred to as the credential subject. The domain identifier of the credential indicates the domain that can use the credential or the domain described in the credential, such as one or more distributed ledgers.

[0131] The digital identity in this application can also be referred to as a self-control identity (scID). Therefore, the identifier of the aforementioned digital identity can also be abbreviated as scID-ID.

[0132] In this application, distributed ledger 201 and distributed ledger 202 may belong to different operators or different network domains of the same operator. For example, distributed ledger 201 belongs to operator A, and distributed ledger 202 belongs to operator B. As another example, distributed ledger 201 belongs to the network deployed by operator A in location B, and distributed ledger 202 belongs to the network deployed by operator A in location C.

[0133] Distributed ledgers 201 and 202 can each maintain information on at least one credential issuer. The credential issuer information maintained by distributed ledger 202 is used by nodes in distributed ledger 202 to determine whether to send the identity information of nodes in distributed ledger 202 to distributed ledger 201. The credential issuer information maintained by distributed ledger 201 is used by nodes in distributed ledger 201 to determine whether to migrate the identity information of nodes in distributed ledger 202 to distributed ledger 201. Optionally, the credential issuer information maintained by distributed ledger 202 can also be used by nodes in distributed ledger 202 to verify the validity of credentials from other nodes, and the credential issuer information maintained by distributed ledger 201 can also be used by nodes in distributed ledger 201 to verify the validity of credentials from other nodes.

[0134] The credential issuers maintained by distributed ledger 201 and distributed ledger 202 can be completely or partially the same. The credential issuers maintained by distributed ledger 201 can include credential issuers that have joined distributed ledger 201, as well as those that have not joined distributed ledger 201. Similarly, the credential issuers maintained by distributed ledger 202 can include credential issuers that have joined distributed ledger 202, as well as those that have not joined distributed ledger 202.

[0135] The credential issuer in this application may issue credentials, certificates, or digital identities, etc. A credential issuer may also be referred to as a certificate issuer or a digital identity issuer. For example, credential issuers include one or more of the following: operators, authoritative institutions, international organizations, or application providers. The following provides further descriptions of each of these credential issuers.

[0136] The operator can be a domestic operator or an 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 distributed ledger 201 as an example, if the operator managing distributed ledger 201 is operator A, and operator A cooperates with operators B and C, then the issuers of the credentials maintained by distributed ledger 201 include operator A. Optionally, the issuers of the credentials maintained by distributed ledger 201 may also include at least one of operators B or C.

[0137] Authoritative bodies include national or governmental organizations, such as the Public Security Bureau, Immigration Bureau, or Education Bureau, or one or more of these.

[0138] International organizations refer to various institutions established by two or more governments, 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 organizations: 3GPP, GSMA, IETF, or ITU.

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

[0140] In this application, the nodes included in distributed ledger 201 and distributed ledger 202 may be partially the same or completely different, without limitation. The nodes in distributed ledger 201 or distributed ledger 202 may be devices with wireless transceiver capabilities, such as terminals, RAN nodes, servers, or core network elements.

[0141] In this application, RAN nodes can provide wireless access services to terminals. Specifically, each RAN node corresponds to a service coverage area, and terminals entering this area can communicate with the RAN node through the air interface to receive the wireless access services provided by the RAN node.

[0142] RAN nodes are nodes within an RAN (Radio Network Area Network) or in an Open RAN (O-RAN or ORAN). RAN nodes can also be referred to as access network equipment, RAN entities, access nodes, or network equipment. RAN nodes include, but are not limited to: evolved Node Bs (NodeBs or eNBs or e-NodeBs) in LTE, next-generation eNBs (ng-eNBs) in next-generation LTE, base stations (gNodeBs or gNBs) in NR, transmitting points (TPs) or transmission receiving points / transmission reception points (TRPs), base stations in subsequent 3GPP evolutions, base stations in future mobile communication systems, satellites, access points (APs) in WiFi systems, wireless relay nodes, wireless backhaul nodes, integrated access and backhaul (IAB) nodes, and network equipment in non-terrestrial network (NTN) communication systems in mobile switching centers. These can be deployed on low-altitude platforms, high-altitude platforms, or satellites. Base stations can be macro base stations, micro base stations, pico base stations, small stations, relay stations, or balloon stations, etc. Multiple base stations can support networks using the same technology mentioned above, or networks using different technologies mentioned above. A base station can contain one or more co-located or non-co-located TRPs. RAN nodes can also be devices that function as base stations in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. RAN nodes can also be radio controllers in cloud radio access network (CRAN) scenarios. RAN nodes can also be centralized units (CU), distributed units (DU), CU-control plane (CP), CU-user plane (UP), radio units (RU), roadside units (RSU) with base station functions, wired access gateways, or core network elements, etc. RAN nodes can also be servers, wearable devices, machine-to-machine communication devices, or vehicle-mounted devices, etc. For example, the access network device in V2X technology can be an RSU. The following explanation uses RAN nodes as base stations as an example. The multiple RAN nodes can be base stations of the same type or base stations of different types.Base stations can communicate with terminals directly, or they can communicate with terminals via relay stations. Terminals can communicate with multiple base stations using different technologies. For example, a terminal can communicate with a base station that supports LTE networks, or it can communicate with a base station that supports 5G networks, and it can also support dual connections with both LTE and 5G network base stations.

[0143] In this application, the CU can implement the functions of the radio resource control (RRC) layer and the packet data convergence protocol (PDCP) layer in the 3GPP standard. The CU can also implement the functions of the service data adaptation protocol (SDAP) layer. The DU can implement the functions of the radio link control (RLC) layer and the medium access control (MAC) layer in the 3GPP standard. The DU can also implement some or all physical layer functions, such as forward error correction (FEC) encoding / decoding, scrambling / descrambling, or modulation / demodulation. The RU can be used to implement radio frequency signal transmission and reception functions. The CU and DU can be set up separately, or they can be included in the same network element, such as in the baseband unit (BBU). It is understood that the CU can be classified as a network device in the access network or a network device in the core network; no limitation is made here. Furthermore, the CU can be further divided into CU-CP and CU-UP. CU-CP can implement the functions of the RRC layer and the control plane functions of the PDCP layer. CU-UP can implement the functions of the SDAP layer and the user plane functions of the PDCP layer.

[0144] In this application, the RU can be included in a radio frequency (RF) device or RF unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). The RU can implement some physical layer functions and RF functions in the 3GPP standard. The physical layer functions that the RU can implement include one or more of the following: Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), digital beamforming, or extraction and filtering of the Physical Random Access Channel (PRACH), etc.

[0145] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0146] Terminals can be deployed on land, including indoors, outdoors, handheld, or vehicle-mounted; they can also be deployed on water (such as ships); and they can be deployed in the air (such as airplanes, balloons, and satellites). Terminals can also be called terminal equipment, which can be user equipment (UE), mobile station (MS), mobile terminal (MT), or any device used to provide voice or data connectivity to users. UEs include handheld devices with wireless communication capabilities, vehicle-mounted devices (e.g., cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains), wearable devices (e.g., smartwatches, smart bracelets, pedometers), or computing devices. For example, a UE can be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device (MID), satellite terminal, or computer with wireless transceiver capabilities. UE can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless modem, a point-of-sale (POS) machine, a customer-premises equipment (CPE), a smart robot, a robotic arm, workshop equipment, smart home devices (e.g., refrigerators, televisions, air conditioners, electricity meters, etc.), a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in intelligent transportation, a wireless terminal in a smart city, a wireless terminal in a smart home, an in-vehicle terminal, an RSU with terminal functionality, or flying equipment (e.g., a smart robot, a hot air balloon, a drone, an airplane), etc. A terminal can also be other devices with terminal functionality; for example, a terminal can also be a device that performs terminal functionality in D2D communication.

[0147] The terminal can be an on-board module, on-board component, on-board chip, on-board unit (OBU), or telematics box (T-BOX) built into the vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in on-board module, on-board component, on-board chip, on-board unit, or T-BOX. The terminal can also be a complete vehicle device.

[0148] Understandably, in some scenarios, the roles of RAN nodes and terminals are relative. For example, a helicopter or drone, which is usually configured as a terminal, can also be configured as a mobile base station, and a device that accesses the RAN via a helicopter or drone is configured as a terminal.

[0149] Core network elements refer to network elements in the core network, such as network slice selection function (NSSF) network elements, network exposure function (NEF) network elements, network repository function (NRF) network elements, policy control function (PCF) network elements, UDM network elements, application function (AF) network elements, authentication server function (AUSF) network elements, access and mobility management function (AMF) network elements, session management function (SMF) network elements, or user plane function (UPF) network elements, etc.

[0150] One or more nodes in Distributed Ledger 201 or Distributed Ledger 202 can be Distributed Ledger Enabler (DLE) network elements. A DLE network element is a distributed ledger enabling module in a communication network, which can be configured and managed by the DLAF. A DLE network element can have one or more of the following functions: transaction proposal, transaction endorsement / execution, deployment and execution of smart contracts, consensus, transaction / block synchronization, or ledger storage. DLE network elements can be deployed on various nodes in the network, such as terminals, RAN nodes, core network elements, or network functions (NFs). A DLE network element can also act as an independent NF, providing distributed ledger proxy capabilities to other NFs. Furthermore, DLE network elements can be categorized into peer nodes or clients based on their roles. For example, a terminal can be considered a client. RAN nodes, servers, and core network elements can be considered 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. The client can perform one or more of the following operations: generate transactions or query ledger data.

[0151] As is understandable, distributed ledgers are usually represented by blockchains, so in this application, "distributed ledger" can be replaced with "blockchain", "nodes in a distributed ledger" can be replaced with "nodes in a blockchain" or "blockchain node", and other similar expressions can also be replaced in a similar way, which will not be elaborated further.

[0152] Optionally, the communication system 20 may further include one or more of the following network elements: network element 203, which can communicate with nodes in distributed ledger 201; network element 204, which can communicate with nodes in distributed ledger 202; network element 205, which can communicate with nodes in distributed ledger 201 and network element 203; or network element 204, which can communicate with nodes in distributed ledger 202 and network element 206. The functions of each of the above network elements are further explained below.

[0153] Network element 203 can store the digital identity or credentials of nodes in distributed ledger 201. Network element 203 can also issue digital identities to nodes in distributed ledger 201. For example, network element 203 can be an ID management (IDM) network element, a DSPR network element, a DLAF network element, or a UDM network element. Network element 204 can be used to store the digital identity or credentials of nodes in distributed ledger 202. Network element 204 can also issue digital identities to nodes in distributed ledger 202. For example, network element 204 can be an IDM network element, a DSPR network element, a DLAF network element, or a UDM network element. Optionally, an IDM network element can be considered an enhancement of a UDM network element.

[0154] Network element 205 serves as the anchor point for the management and association of distributed ledger 201. For example, network element 205 can perform one or more functions such as management of distributed ledger 201, registration management of distributed ledger entries (DLEs), creation of distributed ledger 201, activation of DLEs, and access control of distributed ledger 201. For example, network element 205 is a DLAF network element. Network element 206 serves as the anchor point for the management and association of distributed ledger 202. For example, network element 206 can perform one or more functions such as management of distributed ledger 202, registration management of distributed ledger entries (DLEs), creation of distributed ledger 202, activation of DLEs, and access control of distributed ledger 202. For example, network element 206 is a DLAF network element. DLAF network elements are generally deployed in the core network in the form of network functions. DLAF network elements may also have a hierarchical structure, such as deploying sub-DLAFs in the access network; that is, DLAFs can be deployed on RAN nodes.

[0155] Network element 205 and network element 206 can belong to different operators or different network domains of the same operator, without restriction. When network element 205 and network element 206 belong to different operators, they can connect via SEPP.

[0156] In this application, network elements 203 to 206 can be deployed on the same physical device, or network elements 203 to 206 can be deployed on different physical devices, or some of the network elements 203 to 206 can be deployed on the same physical device and other network elements can be deployed on different physical devices, without any restrictions.

[0157] In this application, the nodes of distributed ledger 201 and distributed ledger 202 can communicate directly or indirectly through other devices.

[0158] For example, taking direct communication between nodes of distributed ledger 201 and distributed ledger 202 as an example, if node 2013 is a terminal and node 2026 is a RAN node, then node 2013 and node 2026 can communicate via the air interface. If node 2014 is a RAN node and node 2023 is an AMF network element, then node 2014 and node 2023 can communicate via the N2 interface. If node 2015 is an SMF network element and node 2022 is an AMF network element, then node 2014 and node 2023 can communicate via the service-oriented interface of the core network.

[0159] For example, nodes in distributed ledger 201 and distributed ledger 202 can communicate via a gateway. Alternatively, nodes in distributed ledger 201 and distributed ledger 202 can establish a trust relationship through a roaming architecture to enable communication. Figure 1 The communication system 20 shown can be applied to Figure 2B The communication network is shown. Specifically, one or more nodes in distributed ledger 201 can directly communicate with security and edge protection proxy (SEPP) 207, SEPP 207 can communicate with SEPP 208, and SEPP 208 can directly communicate with one or more nodes in distributed ledger 202. Taking node 2013 directly communicating with SEPP 207 and SEPP 208 directly communicating with node 2026 as an example, if node 2013 needs to communicate with node 2026, the information sent by node 2013 can be forwarded to node 2026 sequentially via SEPP 207 and SEPP 208; if node 2014 needs to communicate with node 2023, the information sent by node 2014 can be forwarded to node 2023 sequentially via node 2013, SEPP 207, SEPP 208, and node 2026.

[0160] Optionally, SEPP 207 can be deployed in conjunction with the DLE network element corresponding to Distributed Ledger 201, and SEPP 208 can be deployed in conjunction with the DLE network element corresponding to Distributed Ledger 202.

[0161] It is understood that the above-mentioned communication system 20 can be applied to a variety of communication networks, such as the 5G network currently under discussion, or other future networks, etc. This application embodiment does not specifically limit it in this regard.

[0162] For example, communication system 20 is suitable for Figure 2C The communication network shown includes IDM network elements, DLE network elements, DLAF network elements, distributed ledger repository function (DLRF) network elements, UPF network elements, RAN nodes, terminals, and a data network (DN). It should be understood that... Figure 2C The communication network shown may also include other network elements (NFs), such as the NF in the dashed box, which can be AMF, SMF, or UDM, etc., without limitation. In addition, terminals, RAN nodes, or some core network elements (such as...) Figure 2C The NF in the middle can also have DLE function.

[0163] exist Figure 2C In this architecture, terminals can access the communication network through RAN nodes. RAN nodes can communicate with DLAF and UPF network elements, and UPF network elements can access DN. RAN nodes can communicate directly with DLAF network elements or indirectly through AMF network elements. DLE, DLAF, DLRF, IDM, and NF network elements can interact using service-oriented interfaces. Optionally, DLRF network elements can be used to provide storage functionality for the software components required for managing and configuring the distributed ledger. For example, a DLRF network element can store one or more software libraries, toolkits, or binary code for a distributed ledger implementation. When a DLE network element lacks specific software capabilities, the DLRF network element can provide the corresponding software to that DLE network element.

[0164] Understandably, the devices or entities corresponding to the nodes in the distributed ledger 201 of the communication system 20 are... Figure 2C The terminals, RAN nodes, or NF network elements in the communication network shown, and the devices or entities corresponding to network element 203 in communication system 20 are... Figure 2C The IDM network element in the communication network shown, and the device or entity corresponding to network element 205 in communication system 20 are... Figure 2CThe DLAF network element in the communication network shown. Alternatively, the device or entity corresponding to the node in the distributed ledger 202 of the communication system 20 is... Figure 2C The terminals, RAN nodes, or NF network elements in the communication network shown, and the devices or entities corresponding to network element 204 in communication system 20 are... Figure 2C The IDM network element in the communication network shown, and the device or entity corresponding to network element 206 in communication system 20 are... Figure 2C The DLAF network element in the communication network shown.

[0165] Understandable. Figure 1 The communication system 20 shown is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art should understand that in specific implementations, the communication system 20 may also include other devices, and the number of network elements or nodes in the distributed ledger may be determined according to specific needs without limitation.

[0166] Optionally, this application Figure 1 Each network element or device (such as a node in distributed ledger 201, a node in distributed ledger 202, network element 203, network element 204, network element 205 or network element 206, etc.) can also be called a communication device, which can be a general-purpose device or a special-purpose device. This application does not make specific limitations in this regard.

[0167] Optionally, this application Figure 1 The functions of each network element or device (e.g., nodes in distributed ledger 201, nodes in distributed ledger 202, network element 203, network element 204, network element 205, or network element 206, etc.) can be implemented by one device, multiple devices working together, or one or more functional modules within a single device. This application does not impose specific limitations on these aspects. It is understood that the aforementioned functions can be network elements in hardware devices, software functions running on dedicated hardware, a combination of hardware and software, or virtualization functions instantiated on a platform (e.g., a cloud platform).

[0168] In its specific implementation, this application Figure 1 Each network element or device (such as nodes in distributed ledger 201, nodes in distributed ledger 202, network element 203, network element 204, network element 205, or network element 206, etc.) can adopt Figure 3 The shown composition structure, or including Figure 3 The components shown. Figure 3 The diagram shows a hardware structure of a communication device applicable to this application. The communication device 30 includes at least one processor 301 and at least one communication interface 304 for implementing the method provided in this application. The communication device 30 may also include a communication line 302 and a memory 303.

[0169] The processor 301 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0170] Communication line 302 may include a path for transmitting information between the aforementioned components, such as a bus.

[0171] Communication interface 304 is used for communication with other devices or communication networks. Communication interface 304 can be any transceiver-like device, such as an Ethernet interface, a radio access network (RAN) interface, a wireless local area network (WLAN) interface, a transceiver, pins, a bus, interface circuits, or transceiver circuits, etc.

[0172] The memory 303 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM), cache, or other type of dynamic storage device capable of storing information and instructions. It may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. The memory may exist independently and be coupled to the processor 301 via communication line 302. The memory 303 may also be integrated with the processor 301. The memory provided in this application is generally non-volatile.

[0173] The memory 303 stores computer execution instructions involved in the scheme provided in this application, and the processor 301 controls the execution of these instructions. The processor 301 executes the computer execution instructions stored in the memory 303 to implement the method provided in this application. Alternatively, in this application, the processor 301 may execute the processing-related functions of the method provided below, and the communication interface 304 may be responsible for communicating with other devices or communication networks. This application does not specifically limit the specific implementation of this method.

[0174] Optionally, the processor 301 and / or memory 303 may include an AI module. Figure 3 (Not shown in the image). The AI ​​module described above is used to implement AI-related functions. The AI ​​module can be implemented through software, hardware, or a combination of both. For example, the AI ​​module may include a RIC module. For example, the AI ​​module can be a near real-time RIC or a non-real-time RIC.

[0175] Optionally, the computer execution instructions in this application may also be referred to as application code, and this application does not specifically limit them.

[0176] The coupling in this application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, and is used for information exchange between devices, units, or modules.

[0177] As one embodiment, processor 301 may include one or more CPUs, for example Figure 3 CPU0 and CPU1 in the CPU.

[0178] As one embodiment, the communication device 30 may include multiple processors, such as Figure 3 Processors 301 and 307 are described herein. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0179] As one embodiment, the communication device 30 may further include an output device 305 and / or an input device 306. The output device 305 is coupled to the processor 301 and can display information in various ways. For example, the output device 305 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 306 is coupled to the processor 301 and can receive user input in various ways. For example, the input device 306 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0180] Understandable. Figure 3 The structural composition shown does not constitute a limitation on the communication device, except... Figure 3 In addition to the components shown, the communication device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0181] The method provided in this application will now be described with reference to the accompanying drawings. Each network element in the following embodiments may possess... Figure 3 The components shown are not described in detail.

[0182] It is understood that the nodes (such as the first node, second node, third node, or verification node, etc.) in the following embodiments of this application may perform some or all of the steps in this application. These steps are merely examples, and this application may also perform other steps or variations thereof. Furthermore, the steps may be performed in different orders as presented in this application, and it is not necessary to perform all the steps in this application.

[0183] It is understood that the methods described below in this application use nodes (such as first nodes, second nodes, third nodes, or verification nodes) as examples to illustrate the method, but this application does not limit the execution subject of the interaction. For example, any node in the method provided in the following embodiments of this application can also be a chip, chip system, or processor that supports the implementation of the method by the node, or it can be a logic node, logic module, or software that can implement all or part of the functions of the node.

[0184] It is understood that the method provided in this application can be applied to the above. Figure 1The communication system 20 is shown. For example, in the following embodiments of this application, the first distributed ledger can be distributed ledger 201 in the communication system 20; the second distributed ledger in the following embodiments of this application can be distributed ledger 202 in the communication system 20; the second node in the following embodiments of this application can be any node in distributed ledger 201 in the communication system 20 or network element 203; the third node in the following embodiments of this application can be any node in distributed ledger 202 in the communication system 20 or network element 204; and the first node in the following embodiments of this application can be any node in distributed ledger 202 in the communication system 20. The first node and the third node can be the same node in distributed ledger 202 or different nodes; there is no limitation.

[0185] like Figure 4 As shown, this application provides a method for migrating identity information, which may include the following steps:

[0186] S401: The third node obtains the second information.

[0187] In this application, the third node is any node in the second distributed ledger, or an IDM network element corresponding to the second distributed ledger, or a DSPR network element corresponding to the second distributed ledger. The second information includes information about at least one credential issuer maintained by the second distributed ledger. The credential issuer can issue credentials, certificates, or digital identities, etc. The aforementioned at least one credential issuer can include one or more of the following: operators, authoritative institutions, international organizations, or application providers. The information of the aforementioned at least one credential issuer is used by nodes in the second distributed ledger to determine whether to send / migrate the identity information of nodes in the second distributed ledger to other distributed ledgers, such as the first distributed ledger. The aforementioned at least one credential issuer can include credential issuers that have joined the second distributed ledger, or credential issuers that have not joined the second distributed ledger; therefore, the aforementioned at least one credential issuer can also be called a general issuer. Specifically, please refer to the preceding description of credential issuers.

[0188] One possible design is that the information of any credential issuer includes the issuer's identifier (issuerID) and the issuer's key information. The issuer's key information may include the issuer's public key.

[0189] In this application, the third node can obtain the second information locally, or from a node other than the third node in the second distributed ledger (such as the fourth node), or from a node outside the second distributed ledger (such as the fifth node). Optionally, the fifth node is a network element (NF) in the core network, such as a DLAF network element. The following uses the second distributed ledger as an example to illustrate how the third node obtains the second information.

[0190] One possible implementation is that the second information can be stored off-chain. For example, the second information could be stored locally on a third node but not on the chain, allowing the third node to retrieve it locally. Alternatively, the second information could be stored locally on a fourth node but not on the chain, allowing the third node to retrieve it from the fourth node. Yet another example is that the second information could be stored on a fifth node; the third node could request the second information from the fifth node, and upon receiving the request, the fifth node could send a response to the third node containing the second information.

[0191] Another possible implementation is that the second information can be stored on the blockchain. For example, the second information could be stored locally on a third node and uploaded to the blockchain, allowing the third node to retrieve the second information from its local storage. Alternatively, the second information could be stored locally on a fourth node and uploaded to the blockchain, allowing the third node to retrieve the second information from the fourth node.

[0192] Optionally, if the second information is stored on-chain, it can be loaded into the first block (also known as the genesis block) of the second distributed ledger after its startup. Subsequently, nodes in the second distributed ledger can look up the first block when they need the second information. Alternatively, the second distributed ledger can be a consortium blockchain (Hyperledger Fabric) with open-source code. The second distributed ledger can be divided into two parts: a world state and a blockchain. The world state is stored in the form of a database, and its data can be updated at any time. The blockchain is stored in a chain structure, and its data is immutable. The second information can be stored in either the world state or the blockchain.

[0193] For example, taking the storage of the second information in the world state as an example, the second information can be a data table on the second distributed ledger, and can be queried using key-value pairs. It can be understood that if the second information is stored in the form of a list, it can also be called a global issuer list. The following describes the storage method of the second information using the example of its storage on a third node. It should be understood that the third node can also be replaced by any node in the second distributed ledger other than the third node.

[0194] One possible design is that the second information can be stored separately from, or jointly with, the identity information of the nodes in the second distributed ledger. For a description of the identity information of the nodes in the second distributed ledger, please refer to the previous description of the identity information of any single node.

[0195] As an example, the third node maintains two tables: one table stores the identity information of the nodes in the second distributed ledger, and the other table stores secondary information. For example, such as... Figure 5A As shown, the identity information stored by the third node includes identity information 1 to identity information n, where n is a positive integer. Any one of identity information 1 to identity information n includes the digital identity identifier (scID-ID), the document for that digital identity, and attribute credentials. The second information includes information about credential issuer 1 to credential issuer m, where m is a positive integer, and m and n can be the same or different. Information about any one of credential issuers from credential issuer 1 to credential issuer m includes the issuer's identifier and key information. It should be understood that in this example, credential issuers 1 to credential issuer m may include the issuer of one or more of the identity information 1 to identity information n, or they may not include the issuers of identity information 1 to identity information n. In other words, the general issuer stored / maintained by the second distributed ledger may or may not be a node or client in the second distributed ledger.

[0196] As another example, the third node maintains a table that stores the identity information of nodes in the second distributed ledger. For each identity information, the table also includes a flag indicating whether the issuer of that identity information is a universal issuer. That is, the table can include both the identity information and secondary information of the nodes in the second distributed ledger. For example, such as... Figure 5B As shown, a new column can be added to the identity information stored in the third node to indicate whether the issuer of each identity information is a universal issuer. Specifically, the identity information stored in the third node includes identity information 1 to identity information n, and flag bits 1 to flag bits n. Flag bit 1 indicates whether the issuer of identity information 1 is a universal issuer, flag bit 2 indicates whether the issuer of identity information 2 is a universal issuer, and flag bit n indicates whether the issuer of identity information n is a universal issuer. It should be understood that in this example, the universal issuers saved / maintained by the second distributed ledger include the issuers of one or more of the identity information from identity information 1 to identity information n.

[0197] In this application, the second information can be pre-set or pre-stored on the corresponding nodes. For example, the second information can be configured on the corresponding nodes through the telecommunications network management plane. If the second information is stored on-chain, the telecommunications network management plane can send the second information to the nodes or clients in the second distributed ledger when configuring the second distributed ledger. The latter will then upload the second information to the chain after executing the consensus mechanism. Alternatively, the credential issuers maintained by the second distributed ledger are the credential issuers to be maintained as specified in the protocol, and the information of these credential issuers can also be configured on the corresponding nodes through the telecommunications network management plane.

[0198] Optionally, the second distributed ledger can update second information, such as dynamically supplementing or deleting credential issuers through the management plane, consensus mechanism, or smart contracts.

[0199] For example, during the use of the second distributed ledger, if an operator discovers that a particular issuer has issued a large number of credentials in the network, it can add those credentials to the second information. Alternatively, the operator can collaborate with a new institution or organization to add them to the second information. Or, if the digital identity of an issuer in the second information is updated, the operator can replace the original version with the updated version.

[0200] For example, a smart contract can be set up in the second distributed ledger to be responsible for updating the second information. Furthermore, the second distributed ledger can also set triggering conditions for updating the second information. For instance, if a node in the second distributed ledger determines that the number of received credentials from the same issuer exceeds a certain threshold, it can trigger the smart contract, and after passing through the consensus node, add the credential issuer to the second information.

[0201] S402: The third node obtains the first identity information.

[0202] In this application, the first identity information may include information about the first credential. The first credential is a credential of a first node, and the first node is a node in the second distributed ledger. The first credential is issued by a first issuer. The information of the first credential may include the first issuer's signature on the first credential (issuer signature).

[0203] Optionally, the information of the first credential may also include at least one of the following: the identifier of the first issuer, information about the domain to which the first credential belongs (such as a domain identifier), the identifier of the digital identity of the first node (scID-ID), the serial number (SN) of the first credential, the signature of the first issuer on the first credential, the hash value of the first credential, or the content of the first credential declaration. It is understood that this application may hash the entire first credential or a portion of the first credential (such as the subject of the first credential). The first identity information may also include at least one of the identifiers of the first distributed ledger or the digital identity of the first node.

[0204] In this application, the first node and the third node can be the same (e.g., the first node and the third node are the same node in the second distributed ledger) or different (e.g., the first node and the third node are different nodes in the second distributed ledger, or the first node is a node in the second distributed ledger and the third node is an IDM network element).

[0205] One possible implementation is that if the first node and the third node are the same, the third node obtains the first identity information from its local machine.

[0206] Another possible implementation is that if the first node and the third node are different, the third node can obtain the first identity information from the first node. For example, the first node can directly send the first identity information to the third node, or the first node can forward the first identity information to the third node through one or more nodes.

[0207] Another possible implementation involves the third node querying the core network for the first identity information if the first and third nodes are different. For example, the third node can send a first query message to a network element in the core network (such as an IDM or DSPR element). This first query message indicates the identifier of the second distributed ledger, the identifier of the first node's digital identity (also known as scID-ID), and the identifier of the first distributed ledger. Upon receiving the first query message, the network element in the core network can determine that the third node is querying the first node's credentials, and that the domain to which the credentials belong includes both the first and second distributed ledgers. Therefore, the network element in the core network can return a matching credential to the third node. For example, the network element in the core network can send a first query result to the third node. This first query result includes the sequence number of the first credential, which can be used to obtain information about the first credential. That is, the domain to which the first credential belongs includes both the first and second distributed ledgers, and after receiving the first query result, the third node can obtain the information about the first credential based on the first query result.

[0208] Optionally, if the first node determines that it needs to migrate the first credential, the first node sends the first identity information to the third node. It is understood that the migration of the first credential may be caused by the movement of the first node (such as the first node moving from the region corresponding to the second distributed ledger to the region corresponding to the first distributed ledger), or by the network side deciding to migrate the first credential, or by a change in the first node's needs (such as the first node originally being a user of operator A, and now changing to a user of operator B).

[0209] Understandably, this application does not limit the number of first credentials; that is, the first identity information may include information from at least one credential. The content of the information for each of the at least one credential is similar to the content of the information for the first credential. The issuers of the different credentials in the at least one credential may be the same or different. Optionally, the information of the at least one credential may be carried in the first identity information in the form of a list.

[0210] Understandably, this application does not restrict the execution order of S401 and S402. For example, S401 can be executed first, followed by S402, or S402 can be executed first, followed by S401, or both S401 and S402 can be executed simultaneously.

[0211] S403: The third node determines, based on the second information, to send the first identity information to the node in the first distributed ledger.

[0212] One possible implementation is that if the first issuer is a credential issuer maintained by at least one credential provider in the second distributed ledger, the third node determines to send the first identity information to nodes in the first distributed ledger. Alternatively, if the first issuer is a credential issuer maintained by at least one credential provider in the second distributed ledger, and the domain to which the first credential belongs includes the first distributed ledger, the third node determines to send the first identity information to nodes in the first distributed ledger. If the first issuer is not a credential issuer maintained by at least one credential provider in the second distributed ledger, or the domain to which the first credential belongs does not include the first distributed ledger, the third node determines not to send the first identity information to nodes in the first distributed ledger. This reduces the number of credentials to be migrated, improving efficiency.

[0213] Understandably, the third node could also skip the aforementioned judgment and instead directly send the first identity information to the nodes in the first distributed ledger, allowing the nodes in the first distributed ledger to determine whether to migrate the first credential. In this scenario, this application may omit S401.

[0214] Understandably, the purpose of the third node sending the first identity information is to migrate the first credential to the first distributed ledger, so S403 can also be replaced with "the third node determines to migrate the first credential to the first distributed ledger based on the second information".

[0215] Understandably, after S403, the third node sends the first identity information to the nodes in the first distributed ledger. The third node can send the first identity information directly to the nodes in the first distributed ledger, or it can forward the first identity information to the nodes in the first distributed ledger through one or more network elements.

[0216] For example, the third node sends first identity information to nodes in the first distributed ledger via the first SEPP and the second SEPP. Here, the first SEPP is the SEPP corresponding to the first distributed ledger, and the second SEPP is the SEPP corresponding to the second distributed ledger. For example, the first SEPP is... Figure 2B SEPP 207, the second SEPP is Figure 2B SEPP 208 in the middle.

[0217] Optionally, the third node can also generate information for the second transaction and send this information to nodes in the second distributed ledger. The second transaction is a transaction that migrates the first credential, also known as a credential migration transaction. The information in the second transaction may include the identifier of the first distributed ledger, the identifier of the first node's digital identity, and the information of the first credential.

[0218] Optionally, the third node can also send information about the first verification path to the nodes in the first distributed ledger. The first verification path is the verification path of the transaction that migrates the first credential (such as the second transaction mentioned above) in the second distributed ledger, so that the nodes in the first distributed ledger can verify whether the transaction that migrates the first credential (such as the second transaction) exists in the second distributed ledger.

[0219] Optionally, the information of the first verification path and the first identity information can be sent to the nodes in the first distributed ledger through the same message or different messages.

[0220] S404: The second node obtains the first identity information.

[0221] In this application, the second node is any node in the first distributed ledger, or the IDM network element corresponding to the first distributed ledger, or the DSPR network element corresponding to the first distributed ledger.

[0222] One possible implementation is that if the second node is a node in the first distributed ledger, the second node can obtain the first identity information from the third node. For example, the third node can directly send the first identity information to the second node. Alternatively, the third node can forward the first identity information to other nodes in the second distributed ledger, which can then send the first identity information to the second node. Alternatively, the third node can send the first identity information to the second node through the first SEPP and the second SEPP.

[0223] In another possible implementation, the third node can send the first query result to the second node, so that the second node can retrieve the first credential information from the first node based on the first query result. Specifically, the second node can send a first request to the first node. This first request is used to request the content of the first credential claim. The first request may include the identifier of the first node's digital identity and the serial number of the first credential. After receiving the first request, the first node sends a first response to the second node. This first response may include the content of the first credential claim.

[0224] Optionally, the first response may also include access policy information for the first credential. In this scenario, the second node can set the access policy for the first credential based on the access policy information, such as which nodes are allowed to query or obtain the first credential, and which nodes are not allowed to query or obtain the first credential.

[0225] Understandably, if the second node is an IDM network element or a DSPR network element, it obtains its first identity information from the nodes in the first distributed ledger. For example, after receiving the first identity information sent by the third node, a node in the first distributed ledger sends its first identity information to the second node.

[0226] S405: The second node obtains the first information.

[0227] In this application, the first information includes information about at least one credential issuer maintained by the first distributed ledger. The credential issuer can issue credentials, certificates, or digital identities, etc. The aforementioned at least one credential issuer can include one or more of the following: operators, authoritative institutions, international organizations, or application providers. The information of the aforementioned at least one credential issuer is used by nodes in the first distributed ledger to determine whether to migrate the first credential to the first distributed ledger. The aforementioned at least one credential issuer can include credential issuers that have joined the first distributed ledger, and can also include credential issuers that have not joined the first distributed ledger; therefore, the aforementioned at least one credential issuer can also be referred to as a general issuer. Specifically, please refer to the preceding description of credential issuers. It should be understood that the credential issuers maintained by the first distributed ledger and the credential issuers maintained by the second distributed ledger can be completely or partially the same.

[0228] One possible design is that the information of any credential issuer in S405 includes the issuer's identifier (issuer ID) and the issuer's key information. The issuer's key information may include the issuer's public key.

[0229] In this application, the second node can obtain the first information locally, or from a node other than itself in the first distributed ledger, or from a node outside the first distributed ledger, such as an NF network element in the core network. Specifically, the process is similar to that of the third node obtaining the second information, and can be referred to the corresponding description in S401.

[0230] One possible implementation is that the first piece of information can be stored either off-chain or on-chain. The storage method for the first piece of information is similar to that for the second piece of information, and can be found in the corresponding description in S401.

[0231] In this application, the first information can be pre-set or pre-stored on the corresponding node, such as a node in the first distributed ledger or a node outside the first distributed ledger. For example, the first information can be configured on the corresponding node through the telecommunications network management plane. If the first information is stored on-chain, the telecommunications network management plane can send the first information to the corresponding node when configuring the first distributed ledger. Alternatively, the credential issuer maintained by the first distributed ledger is specified in the protocol.

[0232] Optionally, the first distributed ledger can update the first information, such as dynamically adding or deleting credential issuers through the management plane, consensus mechanism, or smart contracts. For details, please refer to the introduction in S401 regarding the second distributed ledger updating the second information.

[0233] As can be seen from S401 and S405, in order to enable credential verification in different distributed ledgers, the credential issuer information can be stored in different distributed ledgers. However, storing all credential issuer information in all distributed ledgers would inevitably lead to redundancy. For example, some credentials (such as credentials describing a user's permissions in a certain distributed ledger) may only be used in one distributed ledger and do not need to be used in other distributed ledgers. Therefore, in this application, different distributed ledgers can store the corresponding credential issuer information as needed (such as institutions cooperating with the operator corresponding to the distributed ledger, or the application scenario of the distributed ledger). That is, the credential issuers stored / maintained by different distributed ledgers can be completely the same, partially the same, or completely different.

[0234] Understandably, this application does not restrict the execution order of S404 and S405. For example, S404 can be executed first, followed by S405, or S405 can be executed first, followed by S404, or both S404 and S405 can be executed simultaneously.

[0235] S406: The second node determines whether to migrate the first voucher to the first distributed ledger based on the first information.

[0236] One possible implementation is that if the first issuer is one of the credential issuers in S405, the second node determines to migrate the first credential to the first distributed ledger; or, if the first issuer is not one of the credential issuers in S405, the second node determines not to migrate the first credential to the first distributed ledger. In this way, the second node can migrate the necessary credentials to the first distributed ledger.

[0237] Optionally, the second node verifies the signature of the first credential. Upon successful verification, it determines to migrate the first credential to the first distributed ledger to improve network security. In other words, if the first issuer is at least one of the credential issuers in S405, and the signature of the first credential is successfully verified based on the first issuer's key information in the first information, the second node determines to migrate the first credential to the first distributed ledger.

[0238] Optionally, before S406, the second node can also determine whether a transaction for migrating the first credential exists in the second distributed ledger based on the information received from the first verification path. If a transaction for migrating the first credential exists in the second distributed ledger, the second node executes S406; if no transaction for migrating the first credential exists in the second distributed ledger, the second node does not execute S406.

[0239] Understandably, after the first credential is migrated to the first distributed ledger, the first node joins the first distributed ledger. Nodes in the first distributed ledger can verify the identity of the first node, enabling the first node's business to be executed within the network corresponding to the first distributed ledger, thereby improving the user experience.

[0240] Understandably, after migrating the first credential to the first distributed ledger, the first node can choose to exit the second distributed ledger or not; there are no restrictions. If the first node does not exit the second distributed ledger, nodes in the second distributed ledger can still verify the first node based on the first credential. In other words, the first credential can be used to verify the first node in both the second and first distributed ledgers, so the first issuer does not need to issue a credential again for the first node in the first distributed ledger. Therefore, the method provided in this application can also save credential resources.

[0241] Optionally, the second node can generate the information for the first transaction and send it to the nodes in the first distributed ledger. The first transaction is a transaction for migrating the first credential, also known as a credential migration transaction. The information in the first transaction includes the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the information of the first credential.

[0242] Optionally, if the second node determines to migrate the first credential to the first distributed ledger, the second node may send a first confirmation message to a node in the second distributed ledger, such as a third node. The first confirmation message confirms the migration of the first credential to the first distributed ledger. The first confirmation message may include the sequence number of the first credential and the identifier of the first distributed ledger. Therefore, upon receiving the first confirmation message, a node in the second distributed ledger can determine that the first credential should be migrated to the first distributed ledger.

[0243] Optionally, after receiving the first confirmation message, a node in the second distributed ledger can send a second confirmation message to the first node. The second confirmation message confirms the migration of the first voucher to the first distributed ledger. The second confirmation message may include the sequence number of the first voucher and the identifier of the first distributed ledger. Therefore, upon receiving the second confirmation message, the first node can determine that the first voucher needs to be migrated to the first distributed ledger.

[0244] Optionally, the first node can store the correspondence between the first voucher and the first distributed ledger, so that the first node can determine which vouchers can be used in the first distributed ledger.

[0245] Optionally, to improve network security, after the first credential is migrated to the first distributed ledger, the first distributed ledger or its corresponding core network can verify the first credential.

[0246] For example, the first node sends a second request to the verification node (such as a node in the first distributed ledger, an IDM network element, or a DSPR network element corresponding to the first distributed ledger). This second request is used to request verification of the first credential. The second request may include the signature of the first credential by the first issuer. Optionally, the second request may also include domain information to which the first credential belongs, such as a domain identifier. After receiving the second request, the verification node can obtain first information and verify the first credential based on the first information and the second request. For example, the verification node can query the key information of the first issuer in the first information based on the second request and verify the first credential based on that key information (such as verifying the signature of the first credential). Optionally, the verification node can also verify whether the domain information to which the first credential belongs includes the identifier of the first distributed ledger. Subsequently, the verification node can also send the verification result of the first credential to the first node.

[0247] based on Figure 4The method shown allows the first and second distributed ledgers to each maintain information on at least one credential issuer. A third node can determine whether to send first identity information to nodes in the first distributed ledger based on the credential issuer information maintained by the second distributed ledger. This first identity information includes information about the first credential. After obtaining the first identity information, the second node can determine whether to migrate the first credential to the first distributed ledger based on the credential issuer information maintained by the first distributed ledger. If the first credential is migrated to the first distributed ledger, nodes in the first distributed ledger can verify the first node based on the first credential, enabling the first node's business logic to execute, thereby improving the user experience.

[0248] Understandably, the actions of the first, second, or third node in the above steps can be determined by... Figure 3 The processor 301 in the communication device 30 shown calls the application code stored in the memory 303 to execute it, and this application does not impose any restrictions on this.

[0249] To better understand the method provided in this application, the following is combined with... Figure 1 The communication system 20 shown illustrates the method provided in this application. Specifically, please refer to the following... Figure 6 , Figure 8 and Figure 9 The method shown. It should be understood that in this application, Figure 4 The method shown, and Figure 6 , Figure 8 and Figure 9 The steps or technical features with the same function in the methods shown can be referenced and learned from each other.

[0250] like Figure 6 As shown, this application provides another method for migrating identity information. In this method, the distributed ledger 201 (and...) Figure 4 The first distributed ledger in the method shown corresponds to the storage / maintenance of the first information, and the distributed ledger 202 (and) Figure 4 The second distributed ledger in the method shown corresponds to maintaining / saving / maintaining second information. For an introduction to the first and second information, please refer to [reference needed]. Figure 4 The method described below. A node in distributed ledger 202 (e.g., node 2021) can determine whether to send the first identity information to a node in distributed ledger 201 (e.g., node 2011) based on the second information. A node in distributed ledger 201 (e.g., node 2011) can determine whether to migrate the first credential to distributed node 201 based on the first information. The first credential is from node 2022 (and...). Figure 4The method described above uses a credential corresponding to the first node. In this method, the hash of the first credential is stored in a distributed ledger (e.g., distributed ledger 202), and the plaintext of the first credential (e.g., the content included in the subject) is stored in node 2022. This process does not require the participation of core network elements, closely resembles the logic of a distributed ledger, and can reduce the risk of single-point attacks. The method described above for determining whether the first credential should be migrated can be called a decentralized method. This method may include the following steps:

[0251] S601: Node 2022 sends the first identity information to Node 2021. Correspondingly, Node 2021 receives the first identity information from Node 2022.

[0252] Node 2022 can be considered a DLE network element (DLE-client) with a client role, and is a user of distributed ledger 202. The first identity information may include the information of the first credential; for details, please refer to... Figure 4 The corresponding description in the method shown.

[0253] One possible implementation is that, under certain credential migration conditions, node 2022 sends the first identity information to node 2021. These credential migration conditions include one or more of the following: node 2022 moves from the region corresponding to distributed ledger 202 to the region corresponding to distributed ledger 201; the network side decides to migrate the first credential; or node 2022's needs change (e.g., node 2022 was originally a user of operator A, but now changes to a user of operator B).

[0254] Optionally, the first credential is issued by the operator corresponding to distributed ledger 202. For example, the first credential is the contract credential between node 2022 and the operator.

[0255] Optionally, if the domain to which the first credential belongs includes distributed ledger 201 (for example, the identifier of the domain to which the first credential belongs includes the identifier of distributed ledger 201, or includes the identifier of the organization of distributed ledger 201), node 2022 sends the first identity information to node 2021.

[0256] Optionally, if the distributed ledger 202 stores the hash of the first credential (including the Issuer field), the information of the first credential may include the sequence number of the first credential, the hash of the first credential, the identifier or public key of the first issuer, and the signature of the first issuer on the first credential. If the distributed ledger 202 stores the hash of the credential subject and the Issuer field of the first credential is in plaintext, the information of the first credential may include the sequence number of the first credential, the hash of the first credential, and the signature of the first issuer on the first credential.

[0257] S602: Node 2021 determines to send the first identity information to node 2011 based on the second information.

[0258] One possible implementation is that if the first credential is valid in distributed ledger 202, node 2021 determines to send the first identity information to node 2011 based on the second information. Here, "determine to send the first identity information to node 2011" can be understood as "determine to send all or part of the first identity information to node 2011". "Determine to send the first identity information to node 2011" can also be replaced with "determine to migrate the first credential".

[0259] For example, node 2021 can query the serial number and hash of the credential corresponding to the digital identity of node 2022 in distributed ledger 202. If the serial number of the queried credential includes the serial number of the first credential, and the hash of the queried credential includes the hash of the first credential, then it is determined that the first credential is valid in distributed ledger 202. Subsequently, node 2021 determines to send the first identity information to node 2011 based on the second information. For example, if the first issuer belongs to at least one credential issuer maintained by distributed ledger 202, node 2021 determines to send the first identity information to node 2011. As another example, if the first issuer belongs to at least one credential issuer maintained by distributed ledger 202, and the domain to which the first credential belongs includes distributed ledger 201, node 2021 determines to send the first identity information to node 2011.

[0260] by Figure 7Taking the first and second identity information as an example, the first identity information includes the scID-ID of node 2022, the information of credential 1, and the information of credential 2. Optionally, the first identity information may also include a digital identity document. The information of credential 1 indicates that the domain identifier of credential 1 includes DL201 (the identifier of distributed ledger 201) and DL202 (the identifier of distributed ledger 202), and that the issuer of credential 1 is OP2. The information of credential 2 indicates that the domain identifier of credential 2 includes DL202 (the identifier of distributed ledger 202) and OP1, and that the issuer of credential 2 is SP1. The second information includes the information of OP2 (such as the identifier of OP2 and the public key of OP2), and the information of SP2 (such as the identifier of SP2 and the public key of SP2). OP1 belongs to the organization of distributed ledger 201, and OP2 belongs to the organization of distributed ledger 202. For document 1, since the field identifier of document 1 includes the identifier of distributed ledger 201, and the second information includes the information of the issuer of document 1 (i.e., OP2), node 2021 determines to send the information of document 1 to node 2011. For document 2, although the field identifier of document 2 includes OP1, the second information does not include the information of the issuer of document 2 (i.e., SP1), so node 2021 determines not to send the information of document 2 to node 2011.

[0261] Understandably, the specific process of S602 is similar to that of S403 above, and you can refer to the corresponding description in S403.

[0262] S603: Node 2021 generates the information for the second transaction and sends it to the nodes in distributed ledger 202. Correspondingly, the nodes in distributed ledger 202 receive the information for the second transaction.

[0263] For example, using blockchain technology, after node 2021 determines that it wants to migrate the first credential, it can generate a blockchain transaction, such as the second transaction. The second transaction, also known as a credential migration transaction, can be sent by node 2021 to nodes in distributed ledger 202. After consensus is reached, the transaction will be recorded on distributed ledger 202. Further details about the second transaction can be found in [reference needed]. Figure 4 The corresponding description in the method shown.

[0264] S604: Node 2021 sends a migration request to Node 2011. Correspondingly, Node 2011 receives the migration request from Node 2021.

[0265] The migration request may include all or part of the first identity information. For example, the migration request may include information about credentials in the first identity information that can be migrated to the distributed ledger 201.

[0266] Optionally, the migration request may also include information about the first verification path, which is used by node 2011 to verify whether there is a transaction (such as the second transaction) in the distributed ledger 202 that migrates the first credential.

[0267] One possible implementation is that node 2021 can send migration requests directly to node 2011, or it can forward migration requests to node 2011 through one or more network elements.

[0268] For example, node 2021 sends a migration request to node 2011 through the second SEPP and the first SEPP. The first SEPP is the SEPP corresponding to distributed ledger 201, and the second SEPP is the SEPP corresponding to distributed ledger 202.

[0269] Optionally, if node 2021 does not send the migration request directly to the second SEPP, but instead sends the migration request to the second SEPP through one or more nodes in the distributed ledger 202, then node 2021 can generate the migration request based on the second transaction and add its own signature after the transaction, so that the node receiving the migration request can determine who sent the migration request.

[0270] Understandably, this application does not restrict the execution order of S603 and S604. For example, S603 can be executed first, followed by S604, or S604 can be executed first, followed by S603, or both S603 and S604 can be executed simultaneously.

[0271] S605: Node 2011 determines whether to migrate the first credential to distributed ledger 201 based on the first information.

[0272] For example, node 2011 can query whether the first information contains the first issuer. If the first information contains the first issuer, node 2011 determines to migrate the first credential to distributed ledger 201.

[0273] Optionally, node 2011 also verifies the signature of the first credential. For example, node 2011 uses the public key of the first issuer stored in the first information to verify the signature of the first credential, determines that the first credential was issued by the first issuer, and determines to migrate the first credential to distributed ledger 201.

[0274] Optionally, node 2011 also verifies that the first credential has been migrated by distributed ledger 202. If the migration request includes information about the first verification path, and if node 2011 is also a node or client of distributed ledger 202, then node 2011 can locally store the root hash of the block and use the first verification path to verify that the credential migration transaction exists on distributed ledger 202, thereby ensuring that the first credential has indeed been migrated by distributed ledger 202.

[0275] S606: Node 2011 generates the information for the first transaction and sends it to the nodes in distributed ledger 201. Correspondingly, the nodes in distributed ledger 201 receive the information for the first transaction.

[0276] For example, using blockchain technology, after node 2011 determines that it wants to migrate the first credential, it can generate a blockchain transaction, such as the first transaction. The first transaction is also called a credential migration transaction. Node 2011 can send the information of this transaction to the nodes in the distributed ledger 201. After consensus is reached, the transaction will be recorded on the distributed ledger 201. Further information about the first transaction can be found in [reference needed]. Figure 4 The corresponding description in the method shown.

[0277] S607: Node 2011 sends a migration response to Node 2021. Correspondingly, Node 2021 receives the migration response from Node 2011.

[0278] The migration response is used to confirm which credentials will be migrated to distributed ledger 201. For example, the migration response includes first confirmation information to confirm that the first credential will be migrated to distributed ledger 201. Another example is that the migration response includes the digital identity of node 2022, and the sequence number of the credential that can be migrated to distributed ledger 201 from the first identity information (such as the sequence number of the first credential).

[0279] Understandably, the credentials in the first identity information that can be migrated to the distributed ledger 201 can be all the credentials included in the first identity information, or only some of the credentials included in the first identity information.

[0280] S608: Node 2021 sends a second acknowledgment to Node 2022. Correspondingly, Node 2022 receives the second acknowledgment from Node 2021.

[0281] The second confirmation information may include the sequence number of the credential that can be migrated to the distributed ledger 201 from the first identity information and the identifier of the distributed ledger 201. Optionally, the second confirmation information may also include the digital identity identifier of node 2022.

[0282] S609: Node 2022 stores the correspondence between the first voucher and the distributed ledger 201.

[0283] It should be understood that S603 or S606 can also be executed after S607, S608 or S609.

[0284] Optionally, after the first credential is migrated to distributed ledger 201, nodes in distributed ledger 201 (such as node 2012) can verify the first credential. It should be understood that the node verifying the first credential can also be node 2011; there is no restriction. For example, Figure 6 The method shown may also include the following steps:

[0285] S610: Node 2022 sends an authentication request to Node 2012. Correspondingly, Node 2012 receives the authentication request from Node 2022.

[0286] The verification request includes the identifier of node 2022's digital identity and information about the first credential.

[0287] S611: Node 2012 verifies the first credential.

[0288] One possible implementation is that node 2012 can query the public key of the first issuer from the first information based on the information of the first credential, and verify the signature of the first credential using the queried public key. Node 2012 can also verify whether the distributed ledger 201 belongs to the field of the first credential. Node 2012 can also verify the content of the first credential, etc.

[0289] One possible implementation is that node 2012 queries the distributed ledger 201 based on the digital identity identifier of node 2022, obtains the security policy corresponding to the identifier, and verifies the public key of the first issuer according to the security policy.

[0290] S612: Node 2012 sends the verification result to Node 2022. Correspondingly, Node 2022 receives the verification result from Node 2012.

[0291] The verification result indicates whether the first credential has been successfully verified.

[0292] Figure 6 In the method shown, the nodes in distributed ledgers 201 and 202 both use a decentralized approach to determine whether the first credential should be migrated. In practical applications, the nodes in either distributed ledger 201 or 202 could also use a centralized approach to determine whether the first credential should be migrated. The centralized approach requires the participation of the operator's management plane nodes or core network elements, thus better aligning with the logic of telecommunications networks and improving communication security.

[0293] like Figure 8 As shown, this application provides another method for migrating identity information. In this method, the distributed ledger 201 (and...) Figure 4 The first distributed ledger in the method shown corresponds to the storage / maintenance of the first information, and the distributed ledger 202 (and) Figure 4The second distributed ledger in the method shown corresponds to maintaining / saving / maintaining second information. For an introduction to the first and second information, please refer to [reference needed]. Figure 4 The method described below. A node in distributed ledger 202 (e.g., node 2021) can determine whether to send the first identity information to a node in distributed ledger 201 (e.g., node 2011) based on the second information. Network element 203 can determine whether to migrate the first credential to distributed node 201 based on the first information. The first credential is from node 2022 (and...). Figure 4 The method described above corresponds to the first node (the credential). In this method, the hash of the first credential is stored in the distributed ledger (e.g., distributed ledger 202), and the plaintext of the first credential (e.g., the content included in the subject) is stored in node 2022. This method may include the following steps:

[0294] S801: Node 2022 sends the first identity information to Node 2021. Correspondingly, Node 2021 receives the first identity information from Node 2022.

[0295] S802: Node 2021 determines to send the first identity information to node 2011 based on the second information.

[0296] S803: Node 2021 generates the information for the second transaction and sends it to the nodes in distributed ledger 202. Correspondingly, the nodes in distributed ledger 202 receive the information for the second transaction.

[0297] S804: Node 2021 sends a migration request to Node 2011. Correspondingly, Node 2011 receives the migration request from Node 2021.

[0298] Understandably, the specific processes of S801 to S804 above are similar to those of S601 to S604 above, and can be referred to accordingly. Figure 6 The corresponding descriptions of the methods shown will not be repeated here.

[0299] S805: Node 2011 sends a migration request to network element 203. Correspondingly, the network element receives the migration request from node 2011.

[0300] Optionally, node 2011 may also send the identifier of distributed ledger 201 to network element 203.

[0301] S806: Network element 203 determines whether to migrate the first credential to distributed ledger 201 based on the first information.

[0302] Understandably, the way network element 203 determines whether to migrate the first credential is similar to the way node 2011 (or the second node) determines whether to migrate the first credential, so you can refer to the corresponding description in S406 or S605 above.

[0303] S807: Network element 203 sends an acknowledgment to node 2011. Node 2011 receives the acknowledgment from network element 203.

[0304] The confirmation result is used to confirm which vouchers will be migrated to distributed ledger 201. For example, the confirmation result includes the sequence number of the voucher in the first identity information that can be migrated to distributed ledger 201 (such as the sequence number of the first voucher). Optionally, the confirmation node also includes the identifier of distributed ledger 201.

[0305] S808: Node 2011 generates the information for the first transaction and sends it to the nodes in distributed ledger 201. Correspondingly, the nodes in distributed ledger 201 receive the information for the first transaction.

[0306] S809: Node 2011 sends a migration response to Node 2021. Correspondingly, Node 2021 receives the migration response from Node 2011.

[0307] S810: Node 2021 sends a second acknowledgment to Node 2022. Correspondingly, Node 2022 receives the second acknowledgment from Node 2021.

[0308] S811: Node 2022 stores the correspondence between the first voucher and the distributed ledger 201.

[0309] S812: Node 2022 sends an authentication request to Node 2012. Correspondingly, Node 2012 receives the authentication request from Node 2022.

[0310] S813: Node 2012 verifies the first credential.

[0311] S814: Node 2012 sends the verification result to Node 2022. Correspondingly, Node 2022 receives the verification result from Node 2012.

[0312] Understandably, the specific processes described in S808 to S814 are similar to those described in S606 to S612, and can be referred to accordingly. Figure 6 The corresponding descriptions of the methods shown will not be repeated here.

[0313] Understandable. Figure 8The method illustrated uses the centralized approach of nodes in distributed ledger 201 to determine whether the first credential should be migrated, and the decentralized approach of nodes in distributed ledger 202 to do the same. In practical applications, both nodes in distributed ledger 201 and distributed ledger 202 can use a centralized approach to determine whether the first credential should be migrated. For example, in S801, node 2022 does not send the first identity information to node 2021, but instead sends the first identity information to network element 204. After receiving the first identity information, network element 204 can determine whether to migrate the first credential based on the second information, or whether to send the first identity information to node 2011. Optionally, when making the above judgment, network element 204 can also combine the security policy of distributed ledger 202 (such as which credentials can be migrated and which cannot). If network element 204 determines the first credential to be migrated, it sends a migration request to node 2011, so that node 2011 can forward the migration request to network element 203. Alternatively, network element 204 can send migration requests to both node 2011 and network element 203. Network element 204 also sends the first identity information to node 2021, so that node 2021 can generate the information for the second transaction. The remaining steps can be found in [reference needed]. Figure 8 The corresponding description in the method shown.

[0314] Understandably, in specific applications, nodes in distributed ledger 202 can determine whether the first credential should be migrated in a centralized manner, while nodes in distributed ledger 201 can determine this in a decentralized manner. For example, in S801, node 2022 does not send the first identity information to node 2021, but instead sends it to network element 204. After receiving the first identity information, network element 204 can determine whether to migrate the first credential based on the second information, or whether to send the first identity information to node 2011. Optionally, network element 204 can also combine the security policy of distributed ledger 202 (such as which credentials can be migrated and which cannot) when making the above judgment. If network element 204 determines to migrate the first credential, it sends a migration request to node 2011, so that node 2011 can determine whether to migrate the first credential to distributed ledger 201 based on the first information. That is, network element 203 does not need to participate in determining whether to migrate the first credential. Network element 204 also sends the first identity information to node 2021 so that node 2021 can generate the information for the second transaction. The remaining steps can be found in [reference needed]. Figure 8 The corresponding description in the method shown.

[0315] Understandably, whether the nodes in distributed ledger 201 or distributed ledger 202 determine whether the first credential needs to be migrated in a centralized or decentralized manner can be pre-configured by the corresponding operator.

[0316] Understandable, Figure 6 The method shown and Figure 8 In the method shown, the hash of the first credential is stored in a distributed ledger (such as distributed ledger 202, and / or distributed ledger 201), while the plaintext of the first credential (such as the content included in the subject) is stored in the DLE-client. However, in practical applications, the DLE-client (such as a terminal) may be unable to store the credential due to limitations in computing power, storage capacity, or user experience. In such scenarios, core network elements can hold the credential on behalf of the client; for example, the core network element can store the plaintext or encrypted credential.

[0317] One possible implementation is that after the Issuer issues a credential to the DLE-client, the DLE-client uploads the plaintext of the credential to the core network (such as an IDM element) for storage. Optionally, the core network can set access control policies to ensure that the credential can only be accessed by the DLE-client itself, thereby protecting user privacy information.

[0318] Another possible implementation involves the Issuer issuing a credential to the DLE-client, after which the DLE-client uploads the encrypted credential (which can be encrypted using the DLE-client's public key) to the core network (such as an IDM element) for storage. The DLE-client can encrypt the claim field of the credential using its private key, but it does not encrypt fields such as the SN, issuer, and issuer signature; instead, it stores these fields in plaintext. Therefore, the DLE-client can only obtain the complete plaintext credential after decryption, thus protecting user privacy.

[0319] For scenarios where core network elements can hold credentials, the hash of the credential needs to be stored in the distributed ledger 201, and the plaintext or ciphertext of the credential also needs to be stored in network element 203. Optionally, to avoid transmitting credentials in plaintext, credential migration can be achieved using token information. Specifically, this can be done as follows: Figure 9 The method is as described.

[0320] like Figure 9 As shown, this application provides another method for migrating identity information. In this method, the distributed ledger 201 (and...) Figure 4 The first distributed ledger in the method shown corresponds to the storage / maintenance of the first information, and the distributed ledger 202 (and) Figure 4 The second distributed ledger in the method shown corresponds to maintaining and saving / maintaining second information. For an introduction to the first and second information, please refer to [reference needed]. Figure 4The corresponding description in the method shown is as follows: A node in distributed ledger 202 (such as node 2021) can obtain first identity information from network element 204, and determine whether to send the first identity information to a node in distributed ledger 201 (such as node 2011) based on second information. A node in distributed ledger 201 (such as node 2011) can determine whether to migrate the first credential to distributed node 201 based on the first information, and send the information of the first credential to network element 203.

[0321] The first credential is node 2022 (and... Figure 4 The first node in the method shown corresponds to the credential. This method may include the following steps:

[0322] S901: Node 2022 determines to migrate credentials to distributed ledger 201.

[0323] One possible implementation is that node 2022 determines that the credential migration conditions are met and migrates the credential to distributed ledger 201. The description of the credential migration conditions can be found in the corresponding section of S601.

[0324] S902: Node 2022 sends the first token information to Node 2021. Correspondingly, Node 2021 receives the first token information from Node 2022.

[0325] For example, node 2022 can generate and send the first token information as shown in Table 1. Here, scID-ID is the identifier of node 2022's digital identity, and node 2022's signature is the signature of the information in the first token information by node 2022 using its own private key.

[0326] Table 1

[0327]

[0328] Understandably, the purpose of setting the first token information is to obtain credentials belonging to domains including distributed ledger 201. The server providing the credentials is IDM, and the first token information is issued by node 2022. Therefore, the first token information contains the signature of node 2022. Furthermore, in scenarios where multiple DLE-clients in distributed ledger 202 need to join distributed ledger 201, the first token information can also be authorized and signed by network element 206, and a field can be added to the requested resource information to indicate which DLE-clients the credential to be migrated belongs to.

[0329] S903: Node 2021 sends the first query information to network element 204. Correspondingly, network element 204 receives the first query information from node 2021.

[0330] The first query information indicates the identifier of distributed ledger 202, the identifier of the digital identity of node 2022, and the identifier of distributed ledger 201. For example, the first query information includes first token information, or the first query information is the first token information.

[0331] Optionally, prior to S903, node 2021 determines whether node 2022 is a legitimate client of distributed ledger 202. If node 2022 is a legitimate client of distributed ledger 202, node 2021 sends the first query information to network element 204.

[0332] For example, node 2021 can query the digital identity identifier of node 2022 in distributed ledger 202. If the digital identity identifier of node 2022 is found, it can be determined that node 2022 is a legitimate client of distributed ledger 202. If it is not found, it can be determined that node 2022 is not a legitimate client of distributed ledger 202.

[0333] S904: Network element 204 verifies the first token information and obtains the migration certificate based on the first token information.

[0334] One possible implementation is that network element 204 can verify the signature in the first token information to determine that the first token information was generated by node 2022 and has not been tampered with. Network element 204 can find the credentials of node 2022 based on the identifier of node 2022's digital identity, and according to the resource application information indicated by the first token information, retrieve the credentials of node 2022 stored in distributed ledger 202, where the domain of the credentials includes the credentials of distributed ledger 201, and use these as the credentials to be migrated. For example, the credentials to be migrated include the first credential.

[0335] S905: Network element 204 sends the first query result to node 2021. Correspondingly, node 2021 receives the first query result from network element 204.

[0336] The first query result includes the serial number of the voucher to be migrated, such as the serial number of the first voucher. This first query result can be used to obtain information about the voucher to be migrated (such as the information about the first voucher).

[0337] Understandably, if network element 204 stores the plaintext of the credential, the plaintext of the credential can also be stored in distributed ledger 201. Therefore, the first query result can include the plaintext of the credential to be migrated. Alternatively, to avoid the risk of privacy leakage caused by directly transmitting the plaintext of the credential to be migrated over the network, the first query result can include second token information, or the second query result can be second token information. The second token information can include indication information of the credential to be migrated, etc. The indication information of the credential to be migrated is used to indicate the credential to be migrated. For example, the second token information can be as shown in Table 2. Optionally, the second token information is used when node 2022 first connects to distributed ledger 202.

[0338] Table 2

[0339]

[0340] Understandably, if the network element 204 stores the encrypted credential, the first query result will include the encrypted credential to be migrated, as well as the identifier of the credential issuer.

[0341] Optionally, if it is necessary to keep the access strategies for migration credentials in network element 203 and network element 204 consistent (such as which credentials can be accessed, and whether the accessible credentials are plaintext or ciphertext), then the first query result can carry the access strategy for the credentials of node 2022 in network element 204.

[0342] S906: Node 2021 generates the information for the second transaction and sends it to the nodes in distributed ledger 202. Correspondingly, the nodes in distributed ledger 202 receive the information for the second transaction.

[0343] Understandably, the specific process of S906 is similar to that of S603, and you can refer to the corresponding description in S603.

[0344] S907: Node 2021 determines the nodes that can be connected in the distributed ledger 201, such as node 2011, based on the indication of the first token information.

[0345] For example, node 2021 can determine that the credential needs to be migrated to distributed ledger 201 based on the indication of the first token information that "the domain to which the credential belongs includes distributed ledger 201", and further determine the node to be connected to distributed ledger 201, such as node 2011.

[0346] S908: Node 2021 sends a migration request to Node 2011. Correspondingly, Node 2011 receives the migration request from Node 2021.

[0347] S909: Node 2011 determines whether to migrate the first voucher to the distributed ledger 201 based on the first information.

[0348] Understandably, the specific processes in S908 to S909 are similar to those in S604 to S605, and can be referred to accordingly. Figure 6 The method described is shown below. The difference is that the migration request includes one or more pieces of information from the first query result.

[0349] S910: Node 2011 sends the digital identity identifier and migration credential information of Node 2022 to network element 203. Correspondingly, network element 203 receives the digital identity identifier and migration credential information of Node 2022 from node 2011.

[0350] The information of the credential to be migrated may include the credential's serial number, hash, and the identifier of the credential issuer.

[0351] S911: Network element 203 will save the digital identity identifier of node 2022 and the information of the credential to be migrated.

[0352] Optionally, network element 203 sends a notification message to node 2011 to notify whether the digital identity identifier and the information of the credential to be migrated of node 2022 have been successfully saved.

[0353] S912: Node 2011 generates the information for the first transaction and sends it to the nodes in distributed ledger 201. Correspondingly, the nodes in distributed ledger 201 receive the information for the first transaction.

[0354] S913: Node 2011 sends a migration response to Node 2021. Correspondingly, Node 2021 receives the migration response from Node 2011.

[0355] S914: Node 2021 sends a second acknowledgment to Node 2022. Correspondingly, Node 2022 receives the second acknowledgment from Node 2021.

[0356] S915: Node 2022 stores the correspondence between the first voucher and the distributed ledger 201.

[0357] Understandably, the specific processes described in S912 to S915 are similar to those in S606 to S609, and can be referred to accordingly. Figure 6 The corresponding description in the method shown.

[0358] It is understandable that S906 or S912 can be executed after S913 without restriction.

[0359] Optionally, if the first query result includes the second token information, or the second query result is the second token information, then node 2022 can register / verify credentials with network element 203 when it first requests access to distributed ledger 201. The following explanation uses the verification of the first credential as an example. For example, Figure 9 The method shown may also include the following steps:

[0360] S916: Node 2022 sends an access request to Node 2011. Correspondingly, Node 2011 receives the access request from Node 2022.

[0361] The access request may include the identifier of the digital identity of node 2022.

[0362] S917: Node 2011 verifies the digital identity of node 2022 and stores it on the distributed ledger 201.

[0363] Optionally, node 2011 can obtain a document of node 2022's digital identity and verify node 2022 using the public key in the document.

[0364] S918: Node 2011 sends a registration request to network element 203. Correspondingly, network element 203 receives the registration request from node 2011.

[0365] The registration request is used to request verification / registration of the first credential. The registration request may include the identifier of the digital identity of node 2022.

[0366] S919: Network element 203 obtains the credential information corresponding to the digital identity identifier of node 2022.

[0367] One possible implementation is that network element 203 obtains the credential information corresponding to the digital identity of node 2022 from its local storage. If the credential information includes second token information, then network element 203 can obtain the first credential from node 2022. For example, Figure 9 The method shown may also include the following steps:

[0368] S920: Network element 203 sends a first request to node 2022. Correspondingly, node 2022 receives the first request from network element 203.

[0369] The first request is used to request the first credential or the content of the first credential declaration. For example, the first request includes the identifier of the digital identity of node 2022 and the serial number of the first credential. Another example is that the first request includes second token information. Optionally, the first request may also include the public key of network element 203.

[0370] S921: Node 2022 sends a first response to network element 203. Correspondingly, network element 203 receives the first response from node 2022.

[0371] The first response includes the content of the first credential statement.

[0372] Optionally, node 2022 verifies the signature in the second token information based on the public key of network element 204, obtains the content of the first credential declaration based on the second token information, encrypts the content of the first credential declaration using the public key of network element 203, and carries the encrypted information in the first response.

[0373] Optionally, the first response may also include access policy information for the first credential.

[0374] After receiving the first response, Network Element 203 can use its private key to decrypt and obtain the content of the first credential declaration, which is then stored in correspondence with the digital identity identifier of Node 2022. Network Element 203 can also set the access policy for the first credential based on its access policy information.

[0375] Optionally, network element 203 sends a registration response to node 2011 to indicate whether the first credential registration was successful. After receiving the registration response, node 2011 sends an access response to node 2022.

[0376] Understandably, the actions of node 2022, node 2021, network element 204, node 2011, or network element 203 in the above steps can be performed by... Figure 3 The processor 301 in the communication device 30 shown calls the application code stored in the memory 303 to execute it, and this application does not impose any restrictions on this.

[0377] The various embodiments mentioned above in this application can be combined without contradiction, and no limitation is imposed.

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

[0379] This application can divide the second node, third node, first node, or verification node into functional modules based on the above method examples. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It is understood that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0380] For example, when dividing the functional modules using an integrated approach. Figure 10 A schematic diagram of a communication device 100 is shown. The communication device 100 includes a processing module 1001 and an interface module 1002. The processing module 1001, also referred to as a processing unit, is used to perform operations other than transmission and reception operations, and may be, for example, a processing circuit or a processor. The interface module 1002, also referred to as an interface unit, is used to perform transmission and reception operations, and may be, for example, an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0381] In some embodiments, the communication device 100 may further include a storage module. Figure 10 (Not shown in the image) is used to store program instructions and data.

[0382] For example, the communication device 100 is used to implement the functions of the second node. The communication device 100 is, for example, a... Figure 4 The second node described in the illustrated embodiment.

[0383] The processing module 1001 is used to acquire the first information. For example, the processing module 1001 can be used to execute S404.

[0384] The processing module 1001 is also used to obtain the first identity information. For example, the processing module 1001 can be used to execute S405.

[0385] The processing module 1001 is further configured to determine, based on the first information, whether to migrate the first voucher to the first distributed ledger. For example, the processing module 1001 may be configured to execute S406.

[0386] When used to implement the functions of the second node, other functions that the communication device 100 can perform can be found in [reference needed]. Figure 4 The relevant descriptions of the embodiments shown will not be elaborated upon further.

[0387] Alternatively, by way of example, communication device 100 is used to implement the functions of a third node. Communication device 100 is, for example, a... Figure 4 The third node described in the illustrated embodiment.

[0388] The processing module 1001 is used to acquire the second information. For example, the processing module 1001 can be used to execute S401.

[0389] The processing module 1001 is also used to obtain the first identity information. For example, the processing module 1001 can be used to execute S402.

[0390] The processing module 1001 is further configured to determine, based on the second information, to send the first identity information to the node in the first distributed ledger. For example, the processing module 1001 can be used to execute S403.

[0391] When used to implement the functions of a third node, other functions that the communication device 100 can perform can be found in [reference needed]. Figure 4 The relevant descriptions of the embodiments shown will not be elaborated upon further.

[0392] Alternatively, by way of example, the communication device 100 is used to implement the functions of the first node. The communication device 100 is, for example, a... Figure 4 The first node described in the illustrated embodiment.

[0393] The interface module 1002 is used to send the first identity information to the third node in the second distributed ledger.

[0394] Interface module 1002 is also used to receive second confirmation information from the third node.

[0395] Processing module 1001 is used to store the correspondence between the first voucher and the first distributed ledger.

[0396] When used to implement the functions of the first node, other functions that the communication device 100 can perform can be found in [reference needed]. Figure 4 The relevant descriptions of the embodiments shown will not be elaborated upon further.

[0397] Alternatively, by way of example, the communication device 100 is used to implement the functionality of the verification node. The communication device 100 is, for example, a... Figure 4 The verification node described in the illustrated embodiment.

[0398] The interface module 1002 is used to receive the second request.

[0399] Processing module 1001 is used to obtain the first information.

[0400] The processing module 1001 also verifies the first credential based on the first information and the second request.

[0401] For information on other functions that the communication device 100 can perform when used to implement the functions of a verification node, please refer to [reference needed]. Figure 4 The relevant descriptions of the embodiments shown will not be elaborated upon further.

[0402] In a simplified embodiment, those skilled in the art will recognize that the communication device 100 can employ... Figure 3 The form shown. For example, Figure 3 The processor 301 can call computer execution instructions stored in the memory 303 to cause the communication device 100 to execute the method described in the above method embodiment.

[0403] For example, Figure 10 The functions / implementation process of the processing module 1001 and interface module 1002 can be achieved through... Figure 3 The processor 301 in the memory calls computer execution instructions stored in the memory 303 to implement the function. Alternatively, Figure 10 The function / implementation process of the processing module 1001 can be achieved through... Figure 3 The processor 301 in the memory calls computer execution instructions stored in the memory 303 to implement this. Figure 10 The function / implementation process of interface module 1002 can be accessed through... Figure 3 It is implemented using the communication interface 304.

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

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

[0406] Optionally, this application also provides a chip system, including: at least one processor and an interface, wherein the at least one processor is coupled to a memory via the interface, and when the at least one processor executes a computer program or instructions in the memory, the method in any of the above method embodiments is executed. In one possible implementation, the chip system further includes a memory. Optionally, the chip system may be composed of chips or may include chips and other discrete devices; this application does not specifically limit this.

[0407] Optionally, this application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be implemented by a computer program instructing related hardware. This program can be stored in the aforementioned computer-readable storage medium. When executed, the program can include the processes described in the above method embodiments. The computer-readable storage medium can be an internal storage unit of the communication device in any of the foregoing embodiments, such as the hard disk or memory of the communication device. The aforementioned computer-readable storage medium can also be an external storage device of the communication device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the communication device. Further, the aforementioned computer-readable storage medium can include both internal storage units and external storage devices of the communication device. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the communication device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0408] Optionally, this application also provides a computer program product. All or part of the processes in the above method embodiments can be executed by a computer program instructing related hardware. This program can be stored in the above computer program product, and when executed, it can include the processes described in the above method embodiments.

[0409] Optionally, this application also provides computer instructions. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware (such as a computer, processor, second node, third node, first node, or verification node, etc.). The program can be stored in the aforementioned computer-readable storage medium or the aforementioned computer program product.

[0410] Optionally, this application also provides a communication system, including: the second node and the third node in the above embodiments.

[0411] Optionally, the communication system described above may further include at least one of the first node or the verification node in the above embodiments.

[0412] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0413] It is understood that the term "connection" in this application can refer to a direct connection or an indirect connection; furthermore, it can refer to an electrical connection or a communication connection. For example, the connection of two electrical components A and B can refer to a direct connection between A and B, or an indirect connection between A and B through other electrical components or connection media, enabling the transmission of electrical signals between A and B; similarly, the connection of two devices A and B can refer to a direct connection between A and B, or an indirect connection between A and B through other communication devices or communication media, enabling communication between A and B.

[0414] It is understood that the message names between various network elements or the names of various parameters in the messages in the above embodiments of this application are just examples, and other names may be used in the specific implementation. This application does not make any specific limitations on this.

[0415] It is understood that in this application, " / " can indicate that the objects before and after it are in an "or" relationship. For example, A / B can mean A or B. "And / or" can be used to describe three relationships between the related objects. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. Furthermore, expressions like "at least one of A, B, and C" or "at least one of A, B, or C" are generally used to indicate any of the following: A exists alone; B exists alone; C exists alone; A and B exist simultaneously; A and C exist simultaneously; B and C exist simultaneously; A, B, and C exist simultaneously. The above examples using three elements (A, B, and C) illustrate the optional entries for this item. When the expression contains more elements, its meaning can be obtained according to the aforementioned rules.

[0416] To facilitate the description of the technical solutions of this application, the terms "first" and "second" may be used to distinguish technical features with the same or similar functions. The terms "first" and "second" do not limit the number or execution order, nor do they imply that they are necessarily different. In this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" should not be construed as being more preferred or advantageous than other embodiments or design schemes. The use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0417] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It is understood that in the various embodiments of this application, the sequence number of each process does not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application.

[0418] It is understood that in this application, "when," "under the circumstances," "if," and "if" all refer to the corresponding processing that will be carried out under certain objective circumstances, and are not time-limited, nor do they require that there must be a judgment action when implemented, nor do they imply any other limitations.

[0419] In this application, "simultaneously" can be understood as at the same point in time, within a period of time, or within the same cycle.

[0420] It is understood that some optional features in this application can be implemented independently in certain scenarios without relying on other features, such as the current solution upon which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus provided in this application can also implement these features or functions, which will not be elaborated here.

[0421] It is understood that the same step or step with the same function or technical feature in this application can be referenced and learned from each other in different embodiments.

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

[0423] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0424] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0425] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for migrating identity information, characterized in that, The method includes: Obtain first information, which includes information about at least one credential issuer maintained by the first distributed ledger; Obtain first identity information, which includes information about a first credential, wherein the first credential is the credential of the first node in the second distributed ledger; Based on the first information, determine whether to migrate the first voucher to the first distributed ledger.

2. The method according to claim 1, characterized in that, The first credential is issued by the first issuer, and the step of determining whether to migrate the first credential to the first distributed ledger based on the first information includes: If the first issuer is one of the at least one credential issuers, determine to migrate the first credential to the first distributed ledger; or... If the first issuer is not one of the at least one credential issuers, it is determined that the first credential will not be migrated to the first distributed ledger.

3. The method according to claim 2, characterized in that, The information of any one of the at least one credential issuers includes the identifier of the credential issuer and the key information of the credential issuer, and the information of the first credential includes the signature of the first issuer on the first credential. The step of determining to migrate the first credential to the first distributed ledger if the first issuer belongs to the at least one credential issuer includes: If the first issuer belongs to the at least one credential issuer, and the signature of the first credential is successfully verified based on the key information of the first issuer in the first information, it is determined that the first credential will be migrated to the first distributed ledger.

4. The method according to claim 3, characterized in that, The information of the first credential also includes at least one of the following: the identifier of the first issuer, the serial number of the first credential, the hash value of the first credential, or the content of the first credential declaration.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: If it is determined that the first credential will be migrated to the first distributed ledger, a first confirmation message is sent, which confirms that the first credential will be migrated to the first distributed ledger.

6. The method according to any one of claims 1-5, characterized in that, The method is applied to the second node in the first distributed ledger, and the first identity information is received by the second node after being forwarded by the first security edge protection agent and the second security edge protection agent; Wherein, the first security edge protection agent is the security edge protection agent corresponding to the first distributed ledger, and the second security edge protection agent is the security edge protection agent corresponding to the second distributed ledger.

7. The method according to any one of claims 1-6, characterized in that, The issuer of the first credential belongs to at least one credential issuer maintained by the second distributed ledger, and the domain to which the first credential belongs includes the first distributed ledger.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Receive information about the first verification path, where the first verification path is the verification path for the transaction that migrates the first credential in the second distributed ledger; Based on the information from the first verification path, it is determined that the transaction exists in the second distributed ledger.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: The information for generating the first transaction is a transaction for migrating the first credential. The information for the first transaction includes the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the information of the first credential. Send the information for the first transaction.

10. A method for migrating identity information, characterized in that, The method includes: Obtain second information, which includes information about at least one credential issuer maintained by the second distributed ledger; Obtain first identity information, which includes information about a first credential, where the first credential is the credential of a first node, and the first node is a node in the second distributed ledger; Based on the second information, it is determined to send the first identity information to the node in the first distributed ledger.

11. The method according to claim 10, characterized in that, The first credential is issued by the first issuer, and the step of determining to send the first identity information to nodes in the first distributed ledger based on the second information includes: If the first issuer belongs to the at least one credential issuer, and the domain to which the first credential belongs includes the first distributed ledger, determine to send the first identity information to the nodes in the first distributed ledger.

12. The method according to claim 10 or 11, characterized in that, The information of the first credential includes at least one of the following: the identifier of the issuer of the first credential, the serial number of the first credential, the hash value of the first credential, or the content of the first credential declaration.

13. The method according to any one of claims 10-12, characterized in that, The acquisition of the first identity information includes: Send a first query message, which indicates the identifier of the second distributed ledger, the identifier of the digital identity of the first node, and the identifier of the first distributed ledger; Receive a first query result, which includes the serial number of the first credential, and use the first query result to obtain information about the first credential.

14. The method according to any one of claims 10-13, characterized in that, The method further includes: The first identity information is sent to the nodes in the first distributed ledger through the first and second secure edge protection proxies. Wherein, the first security edge protection agent is the security edge protection agent corresponding to the first distributed ledger, and the second security edge protection agent is the security edge protection agent corresponding to the second distributed ledger.

15. The method according to claim 14, characterized in that, The method further includes: Receive a first confirmation message from a node in the first distributed ledger, the first confirmation message being used to confirm the migration of the first credential to the first distributed ledger.

16. The method according to any one of claims 10-15, characterized in that, The method further includes: Send information about a first verification path to the nodes in the first distributed ledger. The first verification path is the verification path for the transaction of migrating the first credential in the second distributed ledger.

17. The method according to any one of claims 10-16, characterized in that, The method further includes: The information for generating a second transaction is a transaction for migrating the first credential. The information for the second transaction includes the identifier of the first distributed ledger, the identifier of the digital identity of the first node, and the information of the first credential. Send the information for the second transaction.

18. A communication device, characterized in that, It includes units or modules for performing the method as described in any one of claims 1 to 9, or includes units or modules for performing the method as described in any one of claims 10 to 17.

19. A communication device, characterized in that, include: A processor coupled to a memory for storing a program or instructions which, when executed by the processor, cause the apparatus to perform the method as claimed in any one of claims 1 to 9, or the method as claimed in any one of claims 10 to 17.

20. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 9, or the method as described in any one of claims 10 to 17.

21. A computer program product, said computer program product comprising computer program code, characterized in that, When the computer program code is run on a computer, it causes the computer to implement the method of any one of claims 1 to 9, or the method of any one of claims 10 to 17.

Images