Credential application method and apparatus

Abstract

The present application relates to the technical field of communications, and in particular to a credential application method and apparatus, aiming to enrich application scenarios of a credential and prevent abuse of the credential. The method comprises: sending a first credential to a verifier, wherein the first credential comprises at least one of first information, second information, or third information, the first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, and the second subject is different from the first subject; and receiving a verification result from the verifier, wherein the verification result is determined on the basis of the first credential.

Description

A method and apparatus for applying vouchers

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410793192.X, filed on June 18, 2024, entitled "A Method and Apparatus for Applying Certificates", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of communication technology, and in particular to a method and apparatus for applying credentials. Background Technology

[0004] Public key infrastructure (PKI) is an infrastructure that provides security services using asymmetric cryptographic algorithms. The main function of PKI is to bind a user's identity and key pair by issuing credentials (also known as certificates) for the user's public key and related user identity information. PKI can provide users with convenient ways to apply for, cancel, obtain, and query the status of credentials, and use credentials and related services (such as credential issuance and blacklist issuance) to achieve identity authentication of various network function (NF) entities in the communication system.

[0005] Currently, users need to maintain a large amount of identity information in communication technology (CT), internet technology (IT), and daily business operations. Identity management is independent across various trust systems. In the next generation of digital identity systems, user identities need to be verifiable across industries and domains; therefore, preventing the misuse of credentials is a problem that needs to be addressed. Summary of the Invention

[0006] This application provides a method and apparatus for applying vouchers, aiming to enrich the application scenarios of vouchers and prevent the abuse of vouchers.

[0007] In a first aspect, embodiments of this application provide a credential application method, which can be executed by a first communication device. The method includes: sending a first credential to a verifier, the first credential including at least one of first information, second information, or third information; the first information indicating at least one service corresponding to the first credential; the second information indicating at least one trusted domain corresponding to the first credential; and the third information indicating a second subject related to a first subject of the first credential, the second subject being different from the first subject; and receiving a verification result from the verifier, wherein the verification result is determined based on the first credential. Optionally, the at least one service includes at least one of the following: operator network service, credential authorization service, or over-the-top (OTT) service, etc.

[0008] In the above-described credential application method, the first communication device and the authenticator can be two different devices (or apparatuses) in a communication network. For example, the first communication device and the authenticator can be two terminal devices conducting a call (e.g., terminal device A and terminal device B); or, the first communication device and the authenticator can also be two devices conducting OTT services (e.g., games, social networks, instant messaging, shopping, reading, music, or travel). It is understood that the first communication device and the authenticator can also be components within the device (e.g., processors, chips, or chip systems) or apparatuses compatible with the device.

[0009] The above methods can expand the application scenarios of credentials, extending them from cryptographic applications such as digital signatures and data encryption to business scenarios such as operator network services, credential authorization services, or OTT services. This supports cross-industry and cross-domain authentication of credentials. At the same time, by limiting the use scenarios of credentials through at least one of the first, second, and third information, the abuse of credentials can be prevented.

[0010] In one possible design, before sending the first credential to the authenticator, the method further includes: sending or receiving a service request. The service request includes at least one of the following: a connection request corresponding to a service, a service request corresponding to a service, an access request corresponding to a service, etc.

[0011] The above design enables both parties in a business connection to verify credentials during the connection process, which helps improve the security of the business connection.

[0012] In one possible design, the first credential includes first information. If at least one service corresponding to the first credential does not match the service corresponding to the service request, the verification result indicates that the verification failed; or, if at least one service corresponding to the first credential matches the service corresponding to the service request, the verification result indicates that the verification passed.

[0013] The above design allows for the limitation of the business scope applicable to the first voucher, thus preventing the abuse of vouchers.

[0014] In one possible design, the first credential includes third information: if the second entity does not have the authority to execute the business corresponding to the business request, the verification result indicates that the verification failed; or, if the second entity has the authority to execute the business corresponding to the business request, the verification result indicates that the verification passed.

[0015] Through the above design, the usage scenarios of the first credential can be restricted based on the permissions of the second subject associated with the first subject of the first credential, thereby preventing the abuse of the credential.

[0016] In one possible design, the first credential includes second information. If at least one trusted domain corresponding to the first credential does not match the trusted domain required by the verifier, the verification result indicates that the verification failed; or, if at least one trusted domain corresponding to the first credential matches the trusted domain required by the verifier, the verification result allows the verification to pass.

[0017] The above design can limit the trusted domain (such as geographical region) to which the first credential applies, thus preventing the abuse of credentials.

[0018] In one possible design, the first credential includes third information: if the second credential of the second subject does not have the authority to issue the first credential, the verification result indicates that the verification failed; or, if the second credential of the second subject has the authority to issue the first credential, the verification result indicates that the verification passed.

[0019] The above design supports permissions based on a second credential from a second subject, further verifying the first credential and helping to prevent the abuse of credentials.

[0020] In one possible design, the first credential includes at least one attribute information, the first information indicating at least one service corresponding to the first credential, including: the first information indicating the service corresponding to each of the at least one attribute information.

[0021] The above design can support the attribute information of the first subject carried in the first certificate, and considering that the first certificate may include multiple attribute information, it can indicate the business corresponding to each attribute information.

[0022] In one possible design, the first information also indicates at least one validity period corresponding to at least one attribute information.

[0023] The above design, considering that the first certificate may include multiple attribute information, can specify the validity period corresponding to each attribute information, which helps to prevent the attribute information from being used outside its corresponding validity period.

[0024] In one possible design, the second entity includes at least one of the following: an entity with guardianship authority over the first entity, an entity with management authority over the first entity, an entity with control authority over the first entity, an entity with all authority over the first entity, or an entity that issues the first credential.

[0025] In one possible design, the method further includes: receiving a first credential from the issuer, the first credential being determined based on at least one of at least one service corresponding to the first subject, at least one trusted domain corresponding to the first subject, a second subject associated with the first subject, or at least one attribute information corresponding to the first subject.

[0026] Through the above design, it is possible to support the issuing party to generate a first credential based on the information of the first subject (such as contract information, signing information, etc.). The first subject's contract information may record at least one of the following: at least one business corresponding to the first subject (such as games, social networks, instant messaging), at least one trusted domain (such as country A), a second subject related to the first subject (such as subject B with management authority over the first subject), or at least one attribute information corresponding to the first subject (such as the industry or professional title of the first subject).

[0027] In one possible design, the method further includes: sending a credential request to the issuer, the credential request indicating at least one of the following: at least one service expected by the first subject, at least one trusted domain expected by the first subject, a second entity related to the first subject, signature information of the second entity, or at least one attribute information of the first subject.

[0028] The above design allows the issuing party to generate a first certificate for the first entity based on the certificate application corresponding to the first entity.

[0029] In one possible design, before receiving the verification result from the verifier, the method further includes: sending a third credential of the issuer of the first credential to the verifier; wherein, if the verification based on the third credential indicates that the issuer does not have the authority to issue the first credential, the verification result indicates that the verification failed; or, if the verification based on the third credential indicates that the issuer has the authority to issue the first credential, the verification result indicates that the verification passed.

[0030] The above design allows the third document issued by the first document to be sent to the verifier, enabling the verifier to verify the document chain of the first document (such as the first document + the third document), thereby improving the reliability of the verification.

[0031] Secondly, embodiments of this application provide a credential application method, which can be executed by a verifier. The method includes: receiving a first credential from a first communication device, the first credential including at least one of first information, second information, or third information, wherein the first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, the second subject being different from the first subject; and sending a verification result to the first communication device, wherein the verification result is determined based on the first credential.

[0032] It should be noted that the verification party may take the form of: verification equipment, terminal equipment with verification function, network equipment, components (processors, chips, or chip systems, etc.), logic modules or software in the verification equipment, terminal equipment or network equipment, and devices that can be used in conjunction with the verification equipment, terminal equipment or network equipment, etc.

[0033] In one possible design, before receiving the first credential from the first communication device, the method further includes receiving or sending a service request.

[0034] In one possible design, the first credential includes first information. If at least one service corresponding to the first credential does not match the service corresponding to the service request, the verification result indicates that the verification failed; or, if at least one service corresponding to the first credential matches the service corresponding to the service request, the verification result indicates that the verification passed.

[0035] In one possible design, the first credential includes third information: if the second entity does not have the authority to execute the business corresponding to the business request, the verification result indicates that the verification failed; or, if the second entity has the authority to execute the business corresponding to the business request, the verification result indicates that the verification passed.

[0036] In one possible design, the first credential includes second information. If at least one trusted domain corresponding to the first credential does not match the trusted domain required by the verifier, the verification result indicates that the verification failed; or, if at least one trusted domain corresponding to the first credential matches the trusted domain required by the verifier, the verification result allows the verification to pass.

[0037] In one possible design, the first credential includes third information: if the second credential of the second subject does not have the authority to issue the first credential, the verification result indicates that the verification failed; or, if the second credential of the second subject has the authority to issue the first credential, the verification result indicates that the verification passed.

[0038] In one possible design, the first credential includes at least one attribute information, the first information indicating at least one service corresponding to the first credential, including: the first information indicating the service corresponding to each of the at least one attribute information.

[0039] In one possible design, the first information also indicates at least one validity period corresponding to at least one attribute information.

[0040] In one possible design, the second entity includes at least one of the following: an entity with guardianship authority over the first entity, an entity with management authority over the first entity, an entity with control authority over the first entity, an entity with all authority over the first entity, or an entity that issues the first credential.

[0041] In one possible design, before sending the verification result to the first communication device, the method further includes: obtaining a third credential of the issuer of the first credential; wherein, if the third credential verifies that the issuer does not have the authority to issue the first credential, the verification result indicates that the verification failed; or, if the third credential verifies that the issuer has the authority to issue the first credential, the verification result indicates that the verification passed.

[0042] In one possible design, obtaining the third credential from the issuer of the first credential includes: receiving the third credential from the issuer of the first credential via the first communication device.

[0043] In one possible design, before sending the verification result to the first communication device, the method further includes: verifying whether the first credential or a summary of the first credential is published on the distributed ledger, wherein if the first credential or a summary of the first credential is not published on the distributed ledger, the verification result indicates that the verification failed.

[0044] Thirdly, embodiments of this application provide a credential application method, which can be executed by the issuer. The method includes: generating a first credential, the first credential including at least one of first information, second information, or third information, wherein the first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, the second subject being different from the first subject; and sending the first credential to a first communication device.

[0045] It should be noted that the issuing party may take the form of: issuing equipment, terminal equipment or network equipment with issuing function, components (processors, chips, or chip systems, etc.), logic modules or software in the issuing equipment, terminal equipment or network equipment, and devices that can be used in conjunction with the issuing equipment, terminal equipment or network equipment, etc.

[0046] In one possible design, generating a first credential includes: determining the first credential based on at least one of the following: at least one business corresponding to a first subject, at least one trusted domain corresponding to the first subject, a second subject related to the first subject, or at least one attribute information corresponding to the first subject.

[0047] In one possible design, before generating the first credential, the method further includes: receiving a credential request from a first communication device, the credential request indicating at least one of the following: at least one service expected to correspond to a first subject, at least one trusted domain expected to correspond to a first subject, a second entity expected to be associated with the first subject, signature information of the second entity, or at least one attribute information corresponding to the first subject.

[0048] In one possible design, the method also includes: publishing a first document or a summary of the first document to the distributed ledger.

[0049] Fourthly, embodiments of this application provide a communication device that has the function of implementing the methods described in the first, second, or third aspects above. The function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, such as an interface unit and a processing unit.

[0050] In one possible design, the device can be a chip or an integrated circuit.

[0051] In one possible design, the device includes a memory and a processor, the memory for storing instructions executed by the processor, and when the instructions are executed by the processor, the device can perform the first, second, or third aspect of the method.

[0052] Fifthly, embodiments of this application provide a communication device including an interface circuit and a processor, wherein the processor and the interface circuit are coupled to each other. The interface circuit is used for inputting and / or outputting signals, and the processor uses logic circuits or executing instructions to implement the methods described in the first, second, or third aspects above. It is understood that the interface circuit can be a transceiver, a transceiver device, or an input / output interface.

[0053] Optionally, the communication device may also include a memory for storing instructions executed by the processor, or storing input data required by the processor to execute instructions, or storing data generated after the processor executes instructions. The memory may be a physically independent unit, or it may be coupled to the processor, or the processor may include the memory (i.e., the processor and the memory are integrated together).

[0054] In one possible implementation, the communication device is a chip.

[0055] Sixthly, embodiments of this application provide a communication system, which includes a first communication device and a verification party. The first communication device is used to implement the method described in the first aspect; the verification party is used to implement the method described in the second aspect.

[0056] In one possible implementation, the communication system also includes an issuer that implements the method described in the third aspect above.

[0057] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed by a processor, can implement the methods described in the first, second, or third aspects.

[0058] Eighthly, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, can implement the methods described in the first, second, or third aspects above.

[0059] Ninthly, embodiments of this application also provide a chip system including a processor, the processor being coupled to a memory, the memory being used to store programs or instructions, and when the program or instructions are executed by the processor, the methods of the first, second, or third aspects described above can be implemented.

[0060] The technical effects achievable by aspects two through nine above are similar to those achievable by aspect one above, and will not be repeated here. Attached Figure Description

[0061] Figure 1 is a schematic diagram of the architecture of the communication network provided in an embodiment of this application;

[0062] Figure 2 is a schematic diagram of infrastructure-based trust circulation provided in an embodiment of this application;

[0063] Figure 3 is a schematic diagram of attribute information introduction provided in an embodiment of this application;

[0064] Figures 4, 6, and 7 are schematic diagrams of the credential application method provided in the embodiments of this application;

[0065] Figure 5 is a schematic diagram of the certificate application process provided in an embodiment of this application;

[0066] Figures 8 and 9 are schematic diagrams of the structure of the communication device provided in the embodiments of this application. Detailed Implementation

[0067] This application provides a method and apparatus for applying credentials. The method and apparatus are based on the same inventive concept. Since the principles by which the method and apparatus solve the problem are similar, their implementations can be mutually referenced, and repeated details will not be elaborated further.

[0068] Figure 1 illustrates a possible, non-limiting, communication network diagram. As shown in Figure 1, the communication network 10 includes a radio access network (RAN) 100 and a core network (CN) 200. RAN 100 includes at least one RAN node (as shown in Figure 1, 110a and 110b, collectively referred to as RAN node 110) and at least one terminal device (as shown in Figure 1, 120a-120j, collectively referred to as terminal device 120). RAN 100 may also include other RAN nodes, such as wireless relay devices and / or wireless backhaul devices (not shown in Figure 1). Terminal device 120 is wirelessly connected to RAN node 110. RAN node 110 is wirelessly or wired connected to core network 200. The core network devices in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.

[0069] RAN 100 can be a cellular network related to the 3rd Generation Partnership Project (3GPP), such as a 4G, 5G mobile communication network, or a future-oriented communication network. RAN 100 can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) network. RAN 100 can also be a communication network that integrates two or more of the above systems.

[0070] It is understood that Figure 1 only shows one possible communication network that can be applied to the embodiments of this application, and other devices may be included in the communication network in other possible scenarios.

[0071] RAN node 110, sometimes also referred to as access network equipment, RAN entity, access node, network equipment, etc., constitutes part of the communication network and is used to help terminal devices achieve wireless access. Multiple RAN nodes 110 in the communication network 10 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal device 120 are relative. For example, network element 120i in Figure 1 can be a helicopter or drone, which can be configured as a mobile base station. For terminal devices 120j accessing RAN 100 through network element 120i, network element 120i is a base station; but for base station 110a, network element 120i is a terminal device. RAN node 110 and terminal device 120 are sometimes both referred to as communication devices. For example, network elements 110a and 110b in Figure 1 can be understood as communication devices with base station functions, and network elements 120a-120j can be understood as communication devices with terminal device functions.

[0072] In one possible scenario, a RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future mobile communication network, or an access node in a WiFi network. A RAN node can be a macro base station (as shown in Figure 1, 110a), a micro base station or indoor station (as shown in Figure 1, 110b), a relay node or donor node, or a radio controller in a CRAN scenario. Optionally, a RAN node can also be a server, wearable device, vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The RAN node in this application can also be a logical node, logical module, or software capable of implementing all or part of the RAN node functions.

[0073] In another possible scenario, multiple RAN nodes collaborate to assist terminal devices in achieving wireless access, with different RAN nodes each implementing a portion of the base station's functions. For example, RAN nodes can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

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

[0075] Terminal devices, also known as terminals, user equipment (UE), mobile stations, mobile terminals, etc., are devices used to provide voice or data connectivity to users, and can also be Internet of Things (IoT) devices. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities. Terminal devices can be: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, smart point of sale (POS) machines, customer-premises equipment (CPE), light user equipment (UE), reduced capability user equipment (REDCAP UE), wireless terminals in industrial control, smart home devices (such as refrigerators, televisions, air conditioners, electricity meters, etc.), smart robots, robotic arms, workshop equipment, wireless terminals in autonomous driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, and flying equipment (such as smart robots, hot air balloons, drones, airplanes), etc. The terminal device can also be a vehicle device, such as a complete vehicle device, an in-vehicle module, an in-vehicle chip, an on-board unit (OBU), or a telematics box (T-BOX). The terminal device can also be other devices with terminal functions; for example, it can be a device that performs terminal functions in D2D communication. The embodiments of this application do not limit the device form of the terminal device.

[0076] A Network Function (CN) can include multiple Network Function (NF) entities, such as Unified Data Management (UDM), Unified Data Repository (UDR), Network Exposure Function (NEF), Application Function (AF), Policy Control Function (PCF), Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Network Data Analytics Function (NWDAF), Network Slice Selection Function (NSSF), Authentication Server Function (AUSF), Network Slice Specific Authentication and Authorization Function (NSSAAF), and Network Repository Function (NRF), etc.

[0077] In addition, the aforementioned communication network may also include entities with credential issuance capabilities, such as trusted institutions like Certificate Authorities (CAs) and Attribute Authorities (AAs), or even third parties or users. The CA or AA can be located within the core network (i.e., a core network function) or outside the core network.

[0078] To facilitate understanding by those skilled in the art, some terms used in this application are explained below.

[0079] 1) Public Key Infrastructure (PKI).

[0080] PKI is an infrastructure that provides security services by utilizing asymmetric cryptography theory and techniques. The main function of PKI is to issue credentials (also known as certificates) to users' public keys and related user identity information, thus binding the credential holder's identity to the associated key pair (i.e., public and private keys). This provides users with convenient ways to apply for, invalidate, obtain, and query credential status, and utilizes credentials and various related services (such as credential issuance, blacklist publication, and timestamp services) to authenticate the identities of entities in communication.

[0081] In a PKI system, a Certificate Authority (CA) issues credentials and binds them to the PKI user's identity information and public key. A PKI relying party pre-stores self-signed credentials (i.e., the root credentials of the CA) of its trusted root CA to verify the credential chain of the PKI user it communicates with, thereby reliably obtaining the user's public key for various security services.

[0082] 2) X.509 credential (also known as X.509 certificate).

[0083] In current public key-based authentication systems, credentials typically follow the X.509 credential format, which is defined as follows, including a base field and an extension field:

[0084] The basic fields may include: version, serial number, signature, issuer, validity period, subject, subject public key, unique identifiers, signature algorithm, and signature value.

[0085] Extended fields may include: authority key identifier, subject key identifier, key usage, certificate policies, certificate mappings, subject alternative name (also known as subject alt name), issuer alternative name (also known as issuer alt name), subject directory attributes, basic constraints, name constraints, policy constraints, extended key usage, certificate revocation list (CRL) distribution points, inhibit any policy, and freshest CRL, etc.

[0086] The key usage field in an X.509 credential defines the scope of use for the current credential. For example, the Internet Engineering Task Force (IETF) standard specifies that the key usage field can have the following uses, including: Transport Layer Security (TLS) server authentication, TLS client authentication, code signing, email signing, timestamp signing, Online Certificate Status Protocol (OCSP) signing, and other cryptographic uses.

[0087] In specific instances where X.509 credentials are used in communication networks, the definition of the key usage field is usually only related to cryptographic applications. For example, in the credential template of a base station, the key usage field of the base station credential is specified to include digital signature, key encipherment, data encipherment, and key agreement. 3GPP specifies that the key usage field of the core network NF includes digital signature for TLS clients and servers.

[0088] Therefore, it can be concluded that, currently, whether from the standard specification X.509 or from the actual use in communication networks (base stations, NFs, etc.), the limitation of the key usage field of public key certificates is still limited to cryptographic-related uses, without any extension to the application layer or scenario level.

[0089] 3) Decentralized identity.

[0090] With the development of digital technology, decentralized identity trust frameworks have gradually attracted industry attention. Decentralized identity trust frameworks are based on asymmetric public and private keys. Users generate their own identity information locally and then authenticate this information with a service provider / organization to obtain verifiable credentials. Because the verification process typically does not require the issuer's real-time involvement, the issuer can publish its own verification tools (e.g., the issuer's public key credentials), allowing any third party to verify the credential.

[0091] The main features of a decentralized identity trust framework are as follows: First, compared with existing centralized identity management methods, neither the issuer nor the verifier needs to centrally store user identity information (e.g., each user's username and password). Instead, identity information and verifiable credentials are stored locally by the user, thus avoiding the risks of sensitive data leakage and single points of failure. Second, based on a publicly trusted database, the issuer, which involves multiple parties, only needs to publish a verification tool. The publication and management of this verification tool are independent, and the tool is publicly available, achieving decoupling between the issuer and the verifier and enabling cross-domain, multi-party identity verification. More importantly, users truly achieve self-management of their own identity information, selectively creating different identity information and verifiable credentials as needed. This decouples the user's identity (ID) from the issuer and allows them to present their verifiable credentials to any service provider to achieve cross-domain, multi-party service access, truly realizing digital identity sovereignty.

[0092] Next-generation digital identity combines distributed ledger (DL) technology with decentralized identity technology. Utilizing DL technology, it builds cross-domain trust mechanisms, enabling trusted alliances among various issuing parties. Each issuing party issues verifiable credentials to users, which can be verified using the issuing party's public key. Furthermore, since the issuing party's public key information (i.e., the issuing party's credentials) has been published to the distributed ledger, the user's verifiable credentials can also be verified based on the information in the distributed ledger. This allows for cross-domain trust and interoperability. The distributed ledger can be implemented through blockchain, directed acyclic graphs, holographic chains, and other similar methods.

[0093] Referring to Figure 2, the social authority (SA), card vendors (such as embedded universal integrated circuit card (eUICC) manufacturers (EUM)), operators (OP), over-the-air card writing servers (such as subscription manager data preparation (SM-DP+)), and third-party organizations (3) rdTerminal equipment manufacturers (such as device manufacturers, DEMs) can serve as the infrastructure for digital identity blockchains. In the next generation of digital identity, blockchain can enable the trust flow of digital identity between various infrastructures, and the verifier can verify the credentials of users under different trust systems (such as credentials issued by different basic devices).

[0094] Currently, users need to maintain a large amount of identity information in CT, IT, and daily business operations. Identity management is independent across different trust systems. For example, in the CT field, each operator's identity system is independent. Users (cards) need to be strongly bound to the operator: each telecom operator independently manages its own user identity system. Therefore, users can only choose to access a specific operator, making it impossible to achieve a unified card across multiple operators or flexibly choose an operator based on factors such as signal strength, tariffs, and location. When users need to access multiple operators, multiple SIM card slots are required.

[0095] In the next-generation digital identity system, user identities need to be verifiable across industries and domains. Credentials may correspond to multiple industries and domains, thus requiring users to hold verifiable credentials for verifying user attributes. As shown in Figure 3, in daily life, the phone calls of delivery drivers need to demonstrate their legitimate identity attributes (e.g., an employed delivery driver for XX courier company) on the receiving end. However, existing attributes rely on feedback markers, lacking authority and real-time accuracy. Therefore, users need to hold employee attribute credentials issued by official institutions such as the courier company, which must be reflected and verified within the communication network. In conclusion, in a digital identity system, identity-related credentials need to include not only public key credentials but also attribute credentials.

[0096] Furthermore, in a digital identity system, because credential information (whether public key credentials or attribute credentials) is related to "people," there are a wider range of use cases, necessitating the specification of the credential's scope of use. For example, limiting the use of attribute credentials corresponding to an identity: income verification credentials can only be used for home loans, courier credentials can only be used for voice services, and work credentials can only be used for visa applications, etc.

[0097] 4) Sending / receiving information. In this application, "sending information" can be understood as one device sending information to another device, or it can also be understood as one logic module within a device sending information to another logic module. For example, "device A sending information" can be understood as device A sending information to another device (device B), or it can be understood as logic module 1 in device A sending information to logic module 2 in device A.

[0098] In this application, "receiving information" can be understood as one device receiving information from another device, or it can also be understood as a logical module within a device receiving information from another logical module. For example, "device A receives information" can be understood as device A receiving information from another device (such as device B), or it can be understood as logical module 1 in device A receiving information from logical module 2 in device A.

[0099] In this application, the phrase "sending information to... (e.g., device B)" or the related illustrations in the accompanying drawings can be understood as the destination of the information being device B. This can include sending information directly or indirectly to device B. Similarly, the phrase "receiving information from... (e.g., device A)," "receiving information from... (e.g., device A)," or "receiving information sent by (e.g., device A)," or the related illustrations in the accompanying drawings, can be understood as the source of the information being device A. This can include receiving information directly or indirectly from device A. Information may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be interpreted similarly, and will not be elaborated further here.

[0100] As can be seen from the above, in the next generation of digital identity system, the identity of users needs to be verifiable across industries and fields. Therefore, how to prevent the abuse of credentials is a problem that needs to be considered.

[0101] Based on this, embodiments of this application provide a method and apparatus for applying vouchers, aiming to enrich the application scenarios of vouchers and prevent the abuse of vouchers. The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0102] Additionally, it should be understood that the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects, and are not used to limit the size, content, order, timing, priority, or importance of the multiple objects. For example, "first certificate" and "second certificate" do not indicate a difference in priority or importance between the two certificates.

[0103] In this application embodiment, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns," that is, "one or more." "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0104] Figure 4 is a schematic diagram of one of the credential application methods provided in the embodiments of this application. The method includes:

[0105] S401: The first communication device sends a first credential to the authenticator, and the authenticator receives the first credential accordingly.

[0106] The first credential includes at least one of first information, second information, or third information. The first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to the first subject of the first credential, wherein the second subject is different from the first subject.

[0107] Understandably, a credential can also be called a certificate, digital certificate, digital credential, etc. For example, the first credential can also be called the first certificate, the first digital certificate, or the first digital credential. The first subject of the first credential can refer to the party (or holder) of the first credential, and the second subject related to the first subject of the first credential can refer to a subject associated with the first subject (or the first credential). For example, the second subject can be the issuing authority of the first credential, which can be an organization responsible for authenticating and issuing credentials, such as a CA; or the first subject can be a minor, and the second subject can be the minor's guardian, etc.

[0108] The first communication device and the verifier can be two different devices (or apparatuses) in a communication network. The first communication device can be a terminal device, network device, NF entity, or server; a component (e.g., processor, chip, or chip system) within the terminal device, network device, NF entity, or server; a logic module or software that implements some or all of the functions of the terminal device, network device, NF entity, or server; or an apparatus used in conjunction with the terminal device, network device, NF entity, or server. The verifier can also be a terminal device, network device, NF entity, or server; a component (e.g., processor, chip, or chip system) within the terminal device, network device, NF entity, or server; a logic module or software that implements some or all of the functions of the terminal device, network device, NF entity, or server; or an apparatus used in conjunction with the terminal device, network device, NF entity, or server.

[0109] For example, the first communication device and the authenticator can be two terminal devices conducting a call (such as terminal device A and terminal device B). Terminal device B can act as the authenticator to verify the credentials (i.e., the first credential) of terminal device A. As another example, the first communication device and the authenticator can also be two devices conducting OTT services (such as games, social networks, instant messaging, shopping, reading, music, travel, or device-to-device (D2D) communication). Taking music as an OTT service as an example, the first communication device can be a terminal device with a music application (APP) installed, and the authenticator can be the server corresponding to the music APP. The server corresponding to the music APP can act as the authenticator to verify the credentials (i.e., the first credential) of the terminal device with the music APP installed. Alternatively, the first communication device can be the server corresponding to the music APP, and the authenticator can be the terminal device with the music APP installed. The terminal device with the music APP can also act as the authenticator to verify the credentials (i.e., the first credential) of the server corresponding to the music APP.

[0110] In this embodiment of the application, the first credential can be an identity credential (such as a public key credential or a symmetric key credential) and / or an attribute credential, wherein the identity credential includes key information (such as a public key or a symmetric key), and the attribute credential can include one or more attribute information.

[0111] Taking identity credentials as a public key credential as an example, Table 1 provides an example of the content of a public key credential. A public key credential may include: version, serial number, signature, issuer, validity period, subject, subject public key, and certificate extensions fields. Among them, the certificate extension fields may include: authority key-identifier, subject alternative name, subject-key identifier, key usage, and CRL distribution points. The information carried by the above fields or the description of the information carried are shown in Table 1.

[0112] Table 1

[0113] It should be noted that Table 1 is only an example of public key certificate content. In actual applications, public key certificates may include more or fewer fields than those in the example in Table 1, or may include different fields than those in the example in Table 1; the configuration of whether each field is mandatory or optional may differ from that in the example in Table 1.

[0114] Taking identity credentials as an example of attribute credentials, Table 2 provides an example of attribute credential content. Attribute credentials may include version, serial number, signature, issuer, validity period, subject, attribute number, and n subject attributes and attribute values ​​corresponding to the attribute number. They may also include attribute algorithm, attribute hash, proof, attribute extensions, etc. The attribute extension fields may include permission key identifier, subject alias, CRL distribution point, etc. The information carried by the above fields or the description of the information carried are shown in Table 2.

[0115] Table 2

[0116] It should be noted that Table 2 is only an example of attribute credential content. In actual applications, attribute credential may include more or fewer fields than the example in Table 2, or may include different fields than the example in Table 2; whether each field is required or optional may be configured differently from the example in Table 2.

[0117] The first, second, or third information can be carried through one or more fields in the first credential.

[0118] In one possible implementation, the initial information can be carried through the usage field (such as a key usage field or an attribute usage field) in the first credential. The initial information carried through the usage field can define the business (or scenario) corresponding to the first credential.

[0119] As an example: For public key credentials, the first information can be carried through the key usage field of the public key credential. The first information carried by the key usage field can not only indicate the cryptographic use of the public key credential, such as authentication, signing, encryption, etc. of clients / servers at the TLS, Internet Protocol (IP) layer, and application layer; it can also be used to limit the business (or scenario) of the public key credential application. The business of the public key credential application can include at least one of the following: operator network services, credential authorization services, or OTT services.

[0120] The first piece of information, when restricting operator network services, can be used to specify access to the operator's network. For example, it can restrict access to the networks of {mobile network operator (MNO)1, MNO3, and MNO7}.

[0121] When restricting OTT services, the first piece of information can be used to specify OTT service access verification. For example, it can restrict the use of this public key credential to third parties (3). rd Access verification for at least one of the following services: APP, games, social networks, instant messaging, shopping, reading, music, travel, or D2D communication.

[0122] When restricting credential permissions, the first piece of information can be used to indicate whether the issuance and revocation of sub-credentials are supported. For example, it can restrict the issuance or revocation of sub-credentials based on this credential.

[0123] Table 3 provides an example of the key usage field format for a public key credential, which can be used to specify the corresponding service for different service types. For example, for communication networks, the first information carried by the key usage field can indicate that the public key credential can access the MNO1 and MNO2 networks; for OTT, the first information carried by the key usage field can indicate that the public key credential can be used for access verification on social networks; for credential permissions, the first information carried by the key usage field can indicate that the public key credential can be used for credential issuance.

[0124] Table 3

[0125] As another example: For attribute credentials, the first information can be carried through the attribute usage field of the attribute credential. The attribute usage field can be used to limit the service (or scenario) to which the attribute credential is applied. The service to which the attribute credential is applied can include at least one of the following: operator network service, credential permission service (also known as authorization type service), or OTT service.

[0126] The first piece of information, when restricting operator network services, can be used to specify access to the operator's network. For example, it can restrict access to the networks of {MNO1, MNO3, MNO7} using this attribute credential.

[0127] When restricting OTT services, the first piece of information can be used to specify OTT service access verification. For example, it can restrict the use of this attribute credential to third parties (3). rd Access verification for at least one of the following services: APP, games, social networks, instant messaging, shopping, reading, music, travel, or D2D communication.

[0128] When restricting access permissions based on credentials (also known as authorization type services), the first information can be used to indicate access authorization based on attribute information.

[0129] Since an attribute credential can include at least one attribute, it can specify the business corresponding to (or applied to) each attribute. For example, the attribute information can include objective attribute information (such as whether real-name authentication has been completed, whether the applicant is over 18 years old, and the applicant's current location), social attribute information (such as industry, professional title, education, qualifications, etc.), and lifestyle attribute information (such as tickets, public transport cards, access control, etc.).

[0130] Table 4 provides an example of the format for the "attribute usage" field in attribute credentials. This allows for the restriction of the service type applied to different attribute information, and the specific service corresponding to each attribute. For example, for attribute number 1 (i.e., the attribute information corresponding to attribute number 1), the service type can be restricted to communication networks, suitable for accessing MNO1 and MNO2 networks; for attribute number 2 (i.e., the attribute information corresponding to attribute number 2), the service type can be restricted to OTT, suitable for accessing social networks; and for attribute number 3 (i.e., the attribute information corresponding to attribute number 3), the service type can be restricted to credential authorization, suitable for credential issuance.

[0131] Table 4

[0132] In some implementations, considering that the validity periods of different attribute information in the attribute certificate may be different, the first information may also indicate at least one validity period corresponding to at least one attribute information of the attribute certificate. Optionally, the first information indicates the validity period corresponding to each attribute information in at least one attribute information. For example: referring to Table 4, the first information may indicate that the validity period of attribute number 1 (i.e., the attribute information corresponding to attribute number 1) is 2026.3.3 (i.e., March 3, 2026), the validity period of attribute number 2 (i.e., the attribute information corresponding to attribute number 2) is 2024.7.1 (i.e., July 1, 2024), and the validity period of attribute number 3 (i.e., the attribute information corresponding to attribute number 3) is 2029.6.3 (i.e., June 3, 2029).

[0133] Optionally, the first information indicates the validity period corresponding to a portion of the attribute information in at least one attribute information. For some attribute information (such as professional title or academic qualification), there is no validity period or no limit on the validity period. Therefore, in some implementations, there may be cases where some or all attribute information in the attribute certificate has no validity period. In the case where the attribute information has no validity period, it can be determined that the attribute information is not subject to the limitation of validity period or is permanently valid.

[0134] In one possible implementation, a domain ID field can be set in the first credential (for example, by adding a domain ID field to the credentials shown in Table 1 and / or Table 2). The second information can be carried through the domain ID field in the first credential, which can limit the trusted domain scope of the first credential.

[0135] As an example: the trusted domain corresponding to the first credential indicated by the second information can be indicated by region, by distributed ledger (e.g., blockchain), or by business. For example, trusted domains can be divided by region into trusted domains such as the European Union and Asia Pacific; by distributed ledger into trusted domains such as Distributed Ledger A and Distributed Ledger B; and by business into trusted domains such as telecommunications domain, non-telecommunications domain, and global domain.

[0136] In one possible implementation, a related ID field can be set in the first document (for example, adding a related ID field to the documents shown in Table 1 and / or Table 2). Third information can be carried through the related ID field in the first document, which can limit the actual controller / related ID of the document.

[0137] The third information indicates that the second entity related to the first entity of the first certificate can be an entity with a stake in the first entity. For example, the second entity can be an entity with guardianship authority over the first entity, an entity with management authority over the first entity, an entity with control authority over the first entity, an entity with all authority over the first entity, or the entity that issued the first certificate, etc.

[0138] As an example: if the current holder of the first credential (i.e. the first subject) is a minor, the third information can instruct his / her guardian (i.e. the second subject); if the current holder of the first credential (i.e. the first subject) is a metaverse digital human, the third information can instruct his / her entity controller (i.e. the second subject).

[0139] Taking the first credential as the public key credential, which includes the aforementioned key usage, domain ID, and related ID fields, as an example, Table 5 provides an example of the content of a public key credential. Compared to the public key credential in Table 1, the public key credential in Table 5 adds the domain ID and related ID fields. The domain ID field can carry second information indicating at least one trusted domain corresponding to the first credential; the related ID field can carry third information indicating a second entity related to the first entity of the first credential. Furthermore, the key usage field in Table 5 has been expanded to also carry first information indicating at least one service corresponding to the public key credential.

[0140] Table 5

[0141] It should be noted that Table 5 is only an example of public key certificate content. In practical applications, public key certificates may include more or fewer fields than those in the example in Table 5, or may include different fields than those in the example in Table 5; whether each field is required or optional may be configured differently from those in the example in Table 5.

[0142] Taking the first credential as an attribute credential, which includes the aforementioned attribute usage, domain ID, and related ID fields, Table 6 provides an example of attribute credential content. The attribute credential shown in Table 6 adds the domain ID and related ID fields compared to the attribute credential shown in Table 2. The domain ID field can carry second information indicating at least one trusted domain corresponding to the first credential; the related ID field can carry third information indicating a second subject related to the first subject of the first credential. Furthermore, the attribute usage field in Table 6 is expanded to also carry first information indicating at least one service corresponding to the attribute credential.

[0143] Table 6

[0144] It should be noted that Table 6 is only an example of attribute credential content. In actual applications, attribute credential may include more or fewer fields than the example in Table 6, or may include different fields than the example in Table 6; whether each field is required or optional may be configured differently from the example in Table 6.

[0145] In one possible implementation, the first document may also include an indication of the type of the issuer and an indication of the type of the first subject of the first document.

[0146] For example, taking the first credential as a public key credential or attribute credential, referring to Table 5 or Table 6 above, for the issuer field, the issuer of a traditional credential is usually a CA (Certificate Authority). However, in digital identity, the issuer, as a CA, can be a traditional trusted institution, a third party, or even a user. Similarly, for the subject field, the subject type of a traditional credential might be a domain name or an individual, while the subject type in digital identity can be a digital person, a virtual person, etc. Therefore, type indications can be included in the issuer and subject fields. Additionally, the issuer field can also include: the issuer's information on a distributed ledger (such as a blockchain) (e.g., an address on the distributed ledger), and the subject field can also include: the credential's subject information on a distributed ledger (such as a blockchain), used by the verifier to verify the credential.

[0147] In addition, if the first credential is published on the distributed ledger, it may also include extended fields such as: distributed ledger record (DLR) / simple chain token (SCT), credential status service (CSS). The DLR / SCT fields can carry the distributed ledger record information of the first credential, such as the distributed ledger identifier, block identifier, transaction identifier, or verification path corresponding to the first credential. This distributed ledger record information can be used to verify the first credential on the distributed ledger. The CSS field can carry the address or identifier of the smart contract for credential query. This smart contract can be used to query whether the credential (such as the first credential) is published on the distributed ledger.

[0148] For example, taking the first credential as a public key credential or attribute credential, as shown in Table 5 or Table 6 above, the public key credential or attribute credential may include a DLR field carrying distributed ledger record information and a CSS field carrying the address or identifier of the smart contract for credential query.

[0149] S402: The verification party sends the verification result to the first communication device, and the verification party receives the verification result accordingly.

[0150] The verification result is determined based on the first credential.

[0151] In the embodiments of this application, the first communication device may send the first credential to the verification party before establishing a service connection with the verification party, and the verification party may verify the first credential; the first communication device may also send the first credential to the verification party during the service connection process, and the verification party may verify the first credential; of course, the first communication device may also send the first credential to the verification party after establishing a service connection with the verification party (for example, after establishing a service connection but before executing a business process), and the verification party may verify the first credential. This application does not limit this.

[0152] As an example: the first communication device can send the first credential to the authenticator after sending a service request to establish a service connection with the authenticator; alternatively, it can send the first credential to the authenticator after receiving a service request (e.g., a service request from the authenticator) requesting the first communication device to establish a service connection with the authenticator. The service request can be a connection request, a service request, or an access request, etc., such as a TLS connection request, a primary authentication request, an OTT access request, etc.

[0153] After receiving the first credential, the verifier can determine the verification result based on the first credential. In one possible implementation, the first credential includes first information. If at least one service corresponding to the first credential does not match the current service of the first communication device (e.g., the service corresponding to the service request), the verification result indicates that the verification failed. If at least one service corresponding to the first credential matches the current service of the first communication device, the verification result indicates that the verification passed. In other words, if at least one service corresponding to the first credential matches the current service of the first communication device, the first information in the first credential (or the at least one service corresponding to the first credential indicated by the first information) is verified successfully.

[0154] As an example: the first information indicates that at least one service corresponding to the first credential includes MNO1, MNO2, social network, and music; the current service of the first communication device is social network; at least one service corresponding to the first credential includes social network; at least one service corresponding to the first credential matches social network; the verification result allows the verification to pass, or in other words, the first information in the first credential is verified to pass.

[0155] In one possible implementation, the first credential includes third information. If the second entity does not have the authority to execute the current service of the first communication device (such as the service corresponding to the service request), the verification result indicates that the verification failed. If the second entity has the authority to execute the current service of the first communication device, the verification result indicates that the verification passed. In other words, if the second entity has the authority to execute the current service of the first communication device, the third information in the first credential is verified.

[0156] As an example: The second entity related to the first entity of the first credential indicated by the third information is terminal device A, the current service of the first communication device is MNO1, the operator network subscribed by terminal device A is MNO3 and MNO7, excluding MNO1, terminal device A should not have the permission to execute MNO1, and the verification result indicates that the verification failed.

[0157] In some implementations, the verifier can also obtain a second credential from the second entity and verify whether the second credential has the authority to issue the first credential. If the second credential of the second entity does not have the authority to issue the first credential, the verification result indicates that the verification failed; if the second credential of the second entity has the authority to issue the first credential, the verification result indicates that the verification passed.

[0158] In one possible implementation, the first credential includes second information. If at least one trusted domain corresponding to the first credential does not match the trusted domain required by the verifier, the verification result indicates that the verification failed. If at least one trusted domain corresponding to the first credential matches the trusted domain required by the verifier, the verification result indicates that the verification passed. In other words, if at least one trusted domain corresponding to the first credential matches the trusted domain required by the verifier, the verification of the second information in the first credential passes.

[0159] The trusted domain required by the verifier can be a trusted domain associated with the service, or a trusted domain specified by the verifier. For example: if the first communication device's current service is MNO1, and MNO1 only provides services within region A, then MNO1 is associated with region A, and the trusted domain required by the verifier can be region A; or if the first communication device's current service is gaming, and the verifier specifies that the gaming service occurs in the telecommunications domain, then the trusted domain required by the verifier is the telecommunications domain.

[0160] As an example: the first credential indicated by the second information includes at least one trusted domain, which includes region A, region B and region D. The trusted domain required by the verifier is region B. The first credential includes at least one trusted domain, which matches the trusted domain required by the verifier. The verification result allows the verification to pass.

[0161] In addition, the verifier can also verify other information in the first document (such as signature, validity, attribute content, etc.). For example, the verifier can verify the issuer's signature in the first document based on the third document of the issuer of the first document (i.e., the root document that issued the first document); verify whether the first document is valid (i.e., whether it has been revoked) based on the CRL of the third document of the issuer of the first document; and verify whether the first document includes the corresponding attribute information according to the verifier's attribute information requirements, etc.

[0162] Understandably, if at least one piece of information on the first credential fails verification, the verifier may send a verification result indicating that the verification failed to the first communication device; if at least one piece of information on the first credential passes verification, the verifier may send a verification result indicating that the verification passed to the first communication device.

[0163] The issuer of the first credential can be an authoritative social institution, card vendor, operator, over-the-air (OTA) card writing server, third-party institution, terminal equipment manufacturer, etc. The possible forms of the issuer include: terminal equipment, network equipment, NF entity or server; components within the terminal equipment, network equipment, NF entity or server (e.g., processor, chip, or chip system); logical modules or software that implement some or all of the functions of the terminal equipment, network equipment, NF entity or server; or devices used in conjunction with the terminal equipment, network equipment, NF entity or server. The issuer can issue the first credential based on at least one of the following: at least one service corresponding to the first subject, at least one trusted domain corresponding to the first subject, a second subject related to the first subject, or at least one attribute information corresponding to the first subject.

[0164] In one possible implementation, the issuing party can generate the first credential by obtaining the information required for the credential based on the information of the first subject (such as signing information, contract information, etc.). The information required for the credential may include at least one of the following: ID, public key, at least one corresponding business, at least one corresponding trusted domain, validity period, etc.

[0165] It should be noted that the first communication device may be the same as or different from the first subject of the first credential. For example: the first communication device and the first subject may be the same, such as the same terminal device, base station, etc.; the first communication device and the first subject may also be different, such as the first communication device being device A and the first subject being a digital human implemented based on device A, or the first communication device being device A and the first subject being an accessory device of device A, etc.

[0166] Taking the same entity and communication device as a terminal device, and the issuing party as a CA as an example, the CA can obtain the information required for the certificate, such as at least one service (e.g., MNO1, MNO2), at least one trusted domain (e.g., China), and the entity identifier of the terminal device, based on the terminal device's subscription information on the operator's side. The CA can then issue a first certificate to the terminal device. The first certificate may include first information and second information, wherein the first information indicates at least one service (e.g., MNO1, MNO2) corresponding to the first certificate, and the second information indicates at least one trusted domain (e.g., China) corresponding to the first certificate.

[0167] In another possible implementation, the first communication device may send a credential request (or credential request request) to the issuing party, and the issuing party may issue a first credential for the first subject based on the credential request from the first communication device. The credential request from the first communication device may indicate at least one of the following: at least one service that the first subject expects to correspond to, at least one trusted domain that the first subject expects to correspond to, a second entity that the first subject expects to be associated with, the signature information of the second entity, or at least one attribute information corresponding to the first subject.

[0168] In some implementations, after receiving a credential application from a first communication device, the issuing party can verify the required information for the credential indicated in the application based on the information of the first entity (such as contract information), and send signable credential information to the first communication device. This signable credential information may include at least one of the following: a signable business, a signable trusted domain, or a signable entity related to the holder of the first credential. After the first communication device determines the requested credential, it generates the first credential based on the signable credential information.

[0169] As an example: Taking the same entity and communication device as a terminal device, the terminal device sends a credential application indicating that the services corresponding to the first credential include MNO1, MNO2, and MNO3. The issuing party, based on the terminal device's subscription information, knows that the terminal device has only subscribed to MNO1 and MNO2. The issuing party can send a first message to the terminal device, indicating that the services that the subscriber can sign include MNO1 and MNO2. If the terminal device determines the credential to be applied for, it can send a second message to the issuing party indicating that the credential has been applied for. After receiving the second message, the issuing party can generate a first credential, which may include first information indicating that at least one service corresponding to the first credential is MNO1 or MNO2.

[0170] This example only shows that the credential application indicates the business that the first credential is expected to correspond to. It is understood that the credential application can also indicate other information (such as at least one trusted domain that the first communication device is expected to correspond to, etc.), and the first credential generated by the issuer can also include other information.

[0171] Taking a terminal device and an CA / AA as examples, where the first communication device and the first subject are the same, and the issuer is a CA / AA, Figure 5 illustrates a possible credential application process provided by an embodiment of this application. This process may include:

[0172] S501: The terminal device sends a credential request to the CA / AA, and the CA / AA receives the credential request accordingly.

[0173] The credential application may include at least one of the following: at least one service that the terminal device expects to correspond to, at least one trusted domain that the terminal device expects to correspond to, a second entity that the terminal device expects to be related to, or at least one attribute information that the terminal device corresponds to.

[0174] Additionally, if the credential application includes information about a second entity that the terminal device is expected to be associated with, it may also include the signature information of that second entity to prove that the terminal device is associated with the second entity.

[0175] In some implementations, the fields required for the credential can be pre-configured in the terminal device. The terminal device can then send the information corresponding to each field required for the credential to the CA / AA. For example, for the usage field, the credential request sent to the CA / AA may include information about at least one service that the terminal device expects to correspond to; for the domain ID field, the credential request sent to the CA / AA may include information about at least one trusted domain that the terminal device expects to correspond to.

[0176] In some implementations, the terminal device can send a credential request to the CA / AA based on a credential template. The credential template includes the fields required for the credential, and the terminal device can send the information corresponding to each field required for the credential to the CA / AA based on the credential template.

[0177] The credential template can be pre-configured in the terminal device, or it can be obtained by the terminal device from the CA / AA. Alternatively, the CA / AA can publish the credential template to a distributed ledger (such as a blockchain), from which the terminal device can obtain the credential template.

[0178] In one possible implementation, different certificate types can have different certificate templates. For example, public key certificate templates and attribute certificate templates can be different. Certificates of the same type issued by different CAs / AAs can also correspond to different certificate templates. For example, CA1 corresponds to public key certificate template A and CA2 corresponds to public key certificate template B.

[0179] S502: CA / AA sends a first message to the terminal device, and the terminal device receives the first message accordingly.

[0180] After receiving a credential request from a terminal device, the CA / AA can verify the information indicated in the credential request based on the terminal device's information (such as contract information), and send a first information indicating that the credential information can be signed (or issued). This could include indicating at least one service that can be signed, at least one trusted domain that can be signed according to the second information, or a subject related to the first subject of the first credential that can be signed, etc.

[0181] S503: The terminal device sends a second message to the CA / AA, and the CA / AA receives the second message accordingly. The second message indicates that the application certificate should be confirmed.

[0182] S504: CA / AA sends the first credential to the terminal device, and the terminal device receives the first credential accordingly.

[0183] It should be noted that steps S502 and S503 above are optional steps. The CA / AA can also directly generate the first credential based on the credential application of the terminal device; or determine the signable credential information based on the credential application of the terminal device, and generate the first credential based on the signable credential information.

[0184] In some implementations, CA / AA can also publish the first credential or its digest (such as a hash value) to a distributed ledger (such as a blockchain) to assist the verifier in verifying the first credential, such as verifying whether the first credential is on the distributed ledger.

[0185] The following description, taking the first communication device and the first main body as the same terminal device, will be based on the specific embodiments in Figures 6 and 7 to illustrate the embodiments in Figure 4.

[0186] Figure 6 is a second schematic diagram of a credential application method provided in an embodiment of this application. The method includes:

[0187] S601: The terminal device and the verification party establish a business connection.

[0188] For example, a service connection can be initiated by a terminal device. For instance, the terminal device can send a service request to the authenticator to request the establishment of a service connection. The service request can be a TLS connection request, a primary authentication request, an OTT access request, etc.

[0189] Of course, the business connection can also be initiated by the authenticator. For example, the authenticator can send a business request to the terminal device to request the establishment of a business connection with the terminal device.

[0190] S602: The terminal device sends the first credential to the authenticator, and the authenticator receives the first credential accordingly.

[0191] The first credential includes at least one of first information, second information, or third information. The first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to the first subject of the first credential, wherein the second subject is different from the first subject.

[0192] S603: The verification direction sends the verification result to the terminal device, and the terminal device receives the verification result accordingly.

[0193] The implementation of steps S602 and S603 can refer to the implementation of steps S401 and S402, and the repeated parts will not be described again.

[0194] In some implementations, the verifier can also utilize the distributed ledger for auxiliary verification. For example, it can verify whether the first document (or its summary) is published on the distributed ledger (DL). If not, the verification result indicates a failure. Additionally, the verifier can obtain the third document (i.e., the root document that issued the first document) from the distributed ledger and verify the issuer's signature in the first document based on this third document. If the signature verification fails, the verification result can indicate a failure. Furthermore, the verifier can obtain the CRL corresponding to the third document of the first document's issuer from the distributed ledger to obtain the validity information of the first document (i.e., whether the first document has been revoked). If the first document has been revoked, the verification result can indicate a failure.

[0195] Figure 7 is a third schematic diagram of the credential application method provided in this application embodiment, the method including:

[0196] S701: The terminal device and the verification party establish a business connection.

[0197] For example, a service connection can be initiated by a terminal device. For instance, the terminal device can send a service request to the authenticator to request the establishment of a service connection. The service request can be a TLS connection request, a master authentication request, an OTT access request, etc.

[0198] Of course, the business connection can also be initiated by the authenticator. For example, the authenticator can send a business request to the terminal device to request the establishment of a business connection with the terminal device.

[0199] S702: The terminal device sends a credential chain to the verifier, and the verifier receives the credential chain accordingly.

[0200] The credential chain may include a first credential and a third credential of the issuer of the first credential (e.g., the root credential that issued the first credential). The first credential may include at least one of first information, second information, or third information, wherein the first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, the second subject being different from the first subject.

[0201] S703: The verification direction sends the verification result to the terminal device, and the terminal device receives the verification result accordingly.

[0202] Unlike Figure 6, in step S702 of Figure 7, the terminal device can send a credential chain including the first credential to the verifier. The verifier can also verify the first credential based on other credentials in the credential chain. For example, it can verify the issuer's signature in the first credential based on the issuer's third credential. If the signature verification fails, the verification result can indicate that the verification failed. It can also verify whether the issuer's third credential has the authority to issue the first credential. If it does not, the verification result can indicate that the verification failed.

[0203] In some implementations, the verifier can also use the distributed ledger for auxiliary verification. For example, it can verify whether the first document (or its summary) has been published on the distributed ledger. If it hasn't, the verification result indicates that the verification failed. Additionally, the verifier can obtain the CRL corresponding to the third document issued by the first document from the distributed ledger, and retrieve the validity information of the first document (i.e., whether the first document has been revoked). If the first document has been revoked, the verification result can indicate that the verification failed.

[0204] By sending a chain of credentials, including the first credential, to the verifier, the verifier can verify multiple credentials on the chain containing the first credential, further verifying the authenticity and validity of the first credential, which helps improve the accuracy of the verification of the first credential.

[0205] The communication device provided in the embodiments of this application is described below. Please refer to FIG8, which is a structural schematic diagram of the communication device in the embodiments of this application. The communication device may include units or modules corresponding to all or part of the steps in the above method embodiments, and may be used to execute the steps executed by the first communication device, the verifier, or the issuer in the above embodiments. Please refer to the relevant descriptions in the above method embodiments for details.

[0206] As shown in Figure 8, the communication device 800 includes a processing unit 810 and an interface unit 820. The processing unit 810 can be a processor or a processing circuit, and the interface unit 820 can be a transceiver unit or an input / output interface. The communication device 800 can be used to implement the steps performed by the first communication device, the authenticator, or the issuer in the above embodiments.

[0207] When the communication device 800 is used to implement the steps performed by the first communication device in the above embodiments:

[0208] Interface unit 820 is used to send a first credential to the authenticator. The first credential includes at least one of first information, second information, or third information. The first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to the first subject of the first credential. The second subject is different from the first subject. Interface unit 820 is also used to receive a verification result from the authenticator, wherein the verification result is determined based on the first credential.

[0209] When the communication device 800 is used to implement the steps performed by the verifier in the above embodiments:

[0210] Interface unit 820 is configured to receive a first credential from a first communication device. The first credential includes at least one of first information, second information, or third information. The first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, wherein the second subject is different from the first subject. Processing unit 810 is configured to determine a verification result based on the first credential. Interface unit 820 is also configured to send the verification result to the first communication device.

[0211] When the communication device 800 is used to implement the steps performed by the issuing party in the above embodiments:

[0212] Processing unit 810 is used to generate a first credential, the first credential including at least one of first information, second information, or third information, the first information indicating at least one service corresponding to the first credential, the second information indicating at least one trusted domain corresponding to the first credential, and the third information indicating a second subject related to the first subject of the first credential, the second subject being different from the first subject; interface unit 820 is used to send the first credential to a first communication device.

[0213] For other implementation methods, please refer to the relevant descriptions of the first communication device, the verifier, or the issuer in the foregoing embodiments, which will not be repeated here.

[0214] As shown in Figure 9, this application also provides a communication device 900, including a processor 910 and potentially a communication interface 920. The processor 910 and the communication interface 920 are coupled to each other. It is understood that the communication interface 920 can be a transceiver, input / output interface, input interface, output interface, interface circuit, etc. Optionally, the communication device 900 may further include a memory 930 for storing instructions executed by the processor 910, or storing input data required by the processor 910 to execute instructions, or storing data generated after the processor 910 executes instructions. The memory 930 can be a physically independent unit, or it can be coupled to the processor 910, or the processor 910 may include the memory 930.

[0215] When the communication device 900 is used to implement the steps performed by the first communication device, the verifier, or the issuer in the above embodiments, the processor 910 can be used to implement the function of the processing unit 810, and the communication interface 920 can be used to implement the function of the interface unit 820.

[0216] In this application embodiment, the processor (e.g., processor 910) can be one or more central processing units (CPUs). If the processor is a CPU, it can be a single-core CPU or a multi-core CPU. The processor can also be one or a combination of several of the following: CPU, general-purpose processor, application-specific integrated circuit (ASIC), digital signal processor (DSP), microprocessor unit (MPU), microcontroller unit (MCU), graphics processing unit (GPU), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, artificial intelligence processor (AI processor), or neural processing unit (NPU). The processor can implement or execute the methods, steps, and logic block diagrams disclosed in this application embodiment. The steps of the methods disclosed in this application embodiment can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0217] In this embodiment, the memory (e.g., memory 930) may include, but is not limited to, cache, read-only memory (ROM), random access memory (RAM), synchronous dynamic random access memory (SDRAM), hard disk drive (HDD) or solid-state drive (SSD), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), etc. Memory is any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but is not limited thereto. The memory in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing computer programs or instructions, and / or data.

[0218] It is understood that the method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device or a terminal device. Alternatively, the processor and storage medium can exist as discrete components in the network device or terminal device.

[0219] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one network device, terminal, computer, server, or data center to another network device, terminal, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

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

[0221] In the embodiments of this application, the term "exemplary" is used to indicate that it is an example, illustration, or description. Any embodiment or design that is described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the term "exemplary" is intended to present the concept in a specific manner.

[0222] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A method for applying vouchers, characterized in that, include: Send a first credential to the verification party. The first credential includes at least one of first information, second information, or third information. The first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, wherein the second subject is different from the first subject. Receive a verification result from the verifier, wherein the verification result is determined based on the first credential.

2. The method as described in claim 1, characterized in that, Before sending the first credential to the verifier, the method further includes: Send or receive service requests.

3. The method as described in claim 2, characterized in that, The first credential includes the first information. If at least one service corresponding to the first credential does not match the service corresponding to the service request, the verification result indicates that the verification failed.

4. The method as described in claim 2 or 3, characterized in that, The first credential includes the third information. If the second entity does not have the authority to execute the business corresponding to the business request, the verification result indicates that the verification failed.

5. The method according to any one of claims 1-4, characterized in that, The first credential includes the second information. If at least one trusted domain corresponding to the first credential does not match the trusted domain required by the verifier, the verification result indicates that the verification failed.

6. The method according to any one of claims 1-5, characterized in that, The first credential includes the third information. If the second credential of the second subject does not have the authority to issue the first credential, the verification result indicates that the verification failed.

7. The method according to any one of claims 1-6, characterized in that, The first credential includes at least one attribute, which indicates at least one service corresponding to the first credential, including: The first information indicates the service corresponding to each of the at least one attribute information.

8. The method as described in claim 7, characterized in that, The first information also indicates at least one validity period corresponding to the at least one attribute information.

9. The method according to any one of claims 1-8, characterized in that, The second subject includes at least one of the following: The entity having guardianship authority over the first entity, the entity having management authority over the first entity, the entity having control authority over the first entity, the entity having all authority over the first entity, or the entity that issued the first certificate.

10. The method according to any one of claims 1-9, characterized in that, The method further includes: The first credential is received from the issuer and is determined based on at least one of the following: at least one service corresponding to the first subject, at least one trusted domain corresponding to the first subject, a second subject related to the first subject, or at least one attribute information corresponding to the first subject.

11. The method as described in claim 10, characterized in that, The method further includes: Send a credential request to the issuing party, the credential request indicating at least one of the following: at least one service that the first subject expects to correspond to, at least one trusted domain that the first subject expects to correspond to, a second entity that the first subject expects to be related to, the signature information of the second entity, or at least one attribute information that the first subject expects to correspond to.

12. The method according to any one of claims 1-11, characterized in that, Before receiving the verification result from the verifier, the method further includes: Send the third credential of the issuer of the first credential to the verifier; If the issuing party is found to lack the authority to issue the first credential based on the third credential, the verification result indicates that the verification failed.

13. The method according to any one of claims 1-12, characterized in that, The at least one service includes at least one of the following: Operator network services, credential-based access control services, or over-the-top OTT services.

14. A method for applying vouchers, characterized in that, include: Receive a first credential from a first communication device, the first credential including at least one of first information, second information, or third information, the first information indicating at least one service corresponding to the first credential, the second information indicating at least one trusted domain corresponding to the first credential, and the third information indicating a second subject related to a first subject of the first credential, the second subject being different from the first subject; Send a verification result to the first communication device, wherein the verification result is determined based on the first credential.

15. The method as described in claim 14, characterized in that, Before receiving the first credential from the first communication device, the method further includes: Receive or send service requests.

16. The method as described in claim 15, characterized in that, The first credential includes the first information. If at least one service corresponding to the first credential does not match the service corresponding to the service request, the verification result indicates that the verification failed.

17. The method as described in claim 15 or 16, characterized in that, The first credential includes the third information. If the second entity does not have the authority to execute the business corresponding to the business request, the verification result indicates that the verification failed.

18. The method according to any one of claims 14-17, characterized in that, The first credential includes the second information. If at least one trusted domain corresponding to the first credential does not match the trusted domain required by the verifier, the verification result indicates that the verification failed.

19. The method according to any one of claims 14-18, characterized in that, The first credential includes the third information. If the second credential of the second subject does not have the authority to issue the first credential, the verification result indicates that the verification failed.

20. The method according to any one of claims 14-19, characterized in that, The first credential includes at least one attribute, which indicates at least one service corresponding to the first credential, including: The first information indicates the service corresponding to each of the at least one attribute information.

21. The method as described in claim 20, characterized in that, The first information also indicates at least one validity period corresponding to the at least one attribute information.

22. The method according to any one of claims 14-21, characterized in that, The second subject includes at least one of the following: The entity having guardianship authority over the first entity, the entity having management authority over the first entity, the entity having control authority over the first entity, the entity having all authority over the first entity, or the entity that issued the first certificate.

23. The method according to any one of claims 14-22, characterized in that, Before sending the verification result to the first communication device, the method further includes: Obtain the third document from the issuer of the first document; If the issuing party is found to lack the authority to issue the first credential based on the third credential, the verification result indicates that the verification failed.

24. The method as described in claim 23, characterized in that, Obtaining the third document from the issuer of the first document includes: Receive a third credential from the issuer of the first credential of the first communication device.

25. The method according to any one of claims 14-24, characterized in that, Before sending the verification result to the first communication device, the method further includes: Verify whether the first document or its summary is published on the distributed ledger, wherein if the first document or its summary is not published on the distributed ledger, the verification result indicates that the verification fails.

26. A method for applying vouchers, characterized in that, include: Generate a first credential, the first credential including at least one of first information, second information, or third information, wherein the first information indicates at least one service corresponding to the first credential, the second information indicates at least one trusted domain corresponding to the first credential, and the third information indicates a second subject related to a first subject of the first credential, the second subject being different from the first subject; Send the first credential to the first communication device.

27. The method as described in claim 26, characterized in that, The generation of the first credential includes: The first credential is determined based on at least one of the following: at least one business corresponding to the first entity, at least one trusted domain corresponding to the first entity, a second entity related to the first entity, or at least one attribute information corresponding to the first entity.

28. The method as described in claim 26 or 27, characterized in that, Before generating the first credential, the method further includes: The system receives a credential request from the first communication device, the credential request indicating at least one of the following: at least one service that the first subject expects to correspond to, at least one trusted domain that the first subject expects to correspond to, a second entity that the first subject expects to be associated with, signature information of the second entity, or at least one attribute information that the first subject corresponds to.

29. The method according to any one of claims 26-28, characterized in that, The method further includes: Publish the first voucher or a summary of the first voucher to the distributed ledger.

30. A communication device, characterized in that, It includes a module or unit for performing the method as described in any one of claims 1-13; or, it includes a module or unit for performing the method as described in any one of claims 14-25; or, it includes a module or unit for performing the method as described in any one of claims 26-29.

31. A communication device, characterized in that, The device includes a processor and an interface circuit, the interface circuit being used to input and / or output signals, and the processor being used, via logic circuitry or execution instructions, to implement the method as described in any one of claims 1-13; or, to implement the method as described in any one of claims 14-25; or, to implement the method as described in any one of claims 26-29.

32. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, cause the method of any one of claims 1-13 to be implemented; or cause the method of any one of claims 14-25 to be implemented; or cause the method of any one of claims 26-29 to be implemented.

33. A chip system, characterized in that, The chip system includes a processor for coupling with a memory for storing computer programs or instructions that, when executed by the processor, implement the method as described in any one of claims 1-13; or, implement the method as described in any one of claims 14-25; or, implement the method as described in any one of claims 26-29.

34. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions that, when executed by a processor, cause the method as described in any one of claims 1-13 to be implemented; or cause the method as described in any one of claims 14-25 to be implemented; or cause the method as described in any one of claims 26-29 to be implemented.

35. A communication system, characterized in that, The method includes a first communication device and a verifier, wherein the first communication device is configured to perform the method as described in any one of claims 1-13; and the verifier is configured to perform the method as described in any one of claims 14-25.

36. The communication system as described in claim 35, characterized in that, It also includes an issuer, which is used to perform the method as described in any one of claims 26-29.

Images