Resource calling method and device and storage medium

Abstract

The invention provides a resource calling method and device and a storage medium, relates to the technical field of communication, and is used for solving the conflict problem between user agreement information. The method comprises the steps of determining target user agreement information in at least one piece of user agreement information in response to a calling request of an application program interface (API) calling entity; the calling request is used for requesting to call an API to access a target resource; the target user agreement information is used for determining whether the API calling entity is allowed to access the target resource by calling the API.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technologies, and in particular to a resource calling method, device, and storage medium. Background Art

[0002] In the digital service architecture, user consent information management is decentralized across multiple systems, including multiple independent consent management modules such as unified data management (UDM), common API framework (CAPIF), and various business systems. When an application programming interface (API) invoker requests access to network resources, there are substantial conflicts between the user consent information provided by different systems and multiple user consent information provided by the same system, making it difficult to accurately determine the user consent information that will ultimately be adopted. Therefore, how to effectively resolve the consent conflict problem and ensure that the resource owner's authorization is consistent with the user's consent to data processing when calling the API has become a core technical problem that needs to be solved urgently. Summary of the Invention

[0003] The present disclosure provides a resource calling method, device, and storage medium for resolving conflicts between user consent information. The technical solutions provided by the present disclosure are as follows:

[0004] In one aspect, a resource calling method is provided, applied to a first entity, the method comprising:

[0005] In response to a call request from an application programming interface (API) calling entity, target user consent information is determined in at least one user consent information; the call request is used to request the API to access a target resource; the target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API.

[0006] In another aspect, a communication device is provided, applied to a first entity, the device comprising:

[0007] A processing module is used to determine target user consent information in at least one user consent information in response to a call request from an application programming interface (API) calling entity; the call request is used to request the calling API to access a target resource; the target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API.

[0008] On the other hand, a communication device is provided, comprising: a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program instructions executable by the processor; and the resource calling method of any of the above embodiments is implemented when the processor executes the computer program instructions.

[0009] On the other hand, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed on a computer (such as a communication device), the resource calling method of any of the above embodiments is implemented.

[0010] On the other hand, a computer program product is provided, which includes computer program instructions, and when the computer program instructions are executed, the resource calling method of any one of the above embodiments is implemented.

[0011] The technical solution provided by the embodiment of the present disclosure determines the target user consent information in at least one user consent information in response to a call request from an application program interface (API) calling entity. The call request is used to request the API call to access the target resource. The target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API. This avoids the problem of difficulty in accurately determining the user consent information that is ultimately adopted when there are multiple user consent information. It effectively resolves the conflict between user consent information and ensures that the resource owner's authorization is consistent with the user's data processing consent when the API is called. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 A schematic diagram of a general API framework provided in an embodiment of the present disclosure;

[0013] Figure 2 A flowchart of a resource calling method provided in an embodiment of the present disclosure;

[0014] Figure 3 An interactive flow chart of a resource calling method provided in an embodiment of the present disclosure;

[0015] Figure 4 An interactive flow chart of another resource calling method provided by an embodiment of the present disclosure;

[0016] Figure 5 An interactive flow chart of another resource calling method provided in an embodiment of the present disclosure;

[0017] Figure 6 An interactive flow chart of another resource calling method provided in an embodiment of the present disclosure;

[0018] Figure 7 An interactive flow chart of another resource calling method provided in an embodiment of the present disclosure;

[0019] Figure 8 A schematic structural diagram of a communication device provided in an embodiment of the present disclosure;

[0020] Figure 9 A schematic structural diagram of another communication device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] The following will be combined with the accompanying drawings in the embodiments of the present disclosure to clearly and completely describe the technical solutions in the embodiments of the present disclosure. Obviously, the embodiments described are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of the present disclosure.

[0022] In the description of the present disclosure, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" means one or more, and "a plurality" means two or more. Words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not limit them to be necessarily different.

[0023] It should be noted that in this disclosure, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this disclosure as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0024] In digital service architectures, user consent information management is decentralized across multiple systems, including independent consent management modules such as the UDM, the CAPIF framework, and various business systems. When an API caller requests access to network resources, substantial conflicts may arise between user consent information provided by different systems, or between multiple consent information provided by the same system. This makes it difficult to accurately determine which consent information will ultimately be used. Therefore, effectively resolving conflicts between user consent information and ensuring consistency between the resource owner's authorization and the user's consent for data processing during API calls has become a core technical challenge that needs to be addressed.

[0025] In view of this, the present disclosure provides a resource calling method, which includes: in response to a call request from an application program interface (API) calling entity, determining target user consent information in at least one user consent information. The call request is used to request the API to access the target resource. The target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API. This avoids the problem of difficulty in accurately determining the user consent information ultimately adopted when there are multiple user consent information. It effectively resolves the conflict between user consent information and ensures that the resource owner's authorization is consistent with the user's data processing consent when the API is called.

[0026] The resource calling method provided by the embodiment of the present disclosure can be applied to systems of various communication formats. For example, the control signal sending and detection methods provided by the embodiment of the present disclosure can be applied to systems including but not limited to new air interface systems, long term evolution (LTE) systems, various versions based on LTE evolution, fifth generation (5G) communication systems, wireless local area networks (Wi-Fi) systems, third generation partnership projects (3GPP) related communication systems, ambient internet of things (AmbientIoT) systems or systems integrating multiple systems. In addition, the control signal sending and detection methods provided by the embodiment of the present disclosure can also be applied to future-oriented communication systems (such as 6G and 7G communication systems), etc., and the embodiment of the present disclosure is not limited to this.

[0027] In some embodiments, the terminal can be a device with wireless transceiver function. The terminal can be a passive device, an ambient IoT device, a mobile phone, a tablet computer, a computer with wireless transceiver function, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, etc. The embodiments of the present disclosure do not limit the application scenarios. The terminal can sometimes also be called a tag, a user, a UE, an access terminal, a UE unit, a UE station, a mobile station, a mobile station, a remote station, a remote terminal, a mobile device, a UE terminal, a wireless communication device, a UE agent or a UE device, etc., and the embodiments of the present disclosure do not limit this.

[0028] like Figure 1 As shown, Figure 1 This disclosure provides a schematic diagram of a universal API framework. This network structure can be applied to 5G communication systems, and obviously can also be applied to communication systems of other standards without limitation. The following is a brief introduction to the various components of the universal API framework CAPIF:

[0029] API invoker: Also known as the API caller, it is generally a third-party application that has signed a service agreement with the public land mobile network (PLMN) operator. The API invoker can be a device in the PLMN network, such as the application function (AF), access and mobility management function (AMF), session management function (SMF), etc.; it can also be user equipment (UE). It is mainly used to provide the API caller identity and other information required for API caller authentication, support authentication; support mutual authentication with CAPIF; obtain authorization before accessing the service API; discover service API information; and call the service API.

[0030] CAPIF core function (CCF): mainly used to authenticate API callers based on the identity and other information required for API caller authentication; support mutual authentication with API callers; provide authorization for API callers before accessing service APIs; publish, store and support discovery of service API information; control service API access according to policies configured by PLMN operators; store logs of service API calls and provide service API call logs to authorized entities; bill based on service API call logs; monitor service API calls; add new API callers and exit API callers; store policy configuration related to CAPIF and service APIs; support access logs for auditing (for example, detecting abuse); support the use of another CAPIF core function to publish and discover service API information in CAPIF docking.

[0031] API Exposing Function (AEF): The AEF is the provider of the service API and serves as the service communication portal between the service API and the API caller. In 3GPP networks, the AEF can be a NEF. It is primarily used to authenticate API callers based on the identity and other information required for API caller authentication provided by the CAPIF core function; verify the authorization provided by the CAPIF core function; and log service API calls made by the CAPIF core function.

[0032] API publishing function (APF) is used to provide API publishing functions so that API calling entities can discover APIs.

[0033] The API management function (AMF) is used to provide management of APIs, such as auditing API call logs provided by the CCF, monitoring events reported by the CCF, configuring access and billing policies for the API, detecting the status of the API, and registering API call entities.

[0034] CAPIF API refers to the API provided by CCF, which can be discovered and called by API calling entities. It mainly includes some common types of APIs, including registration type APIs, security authentication and authorization type APIs, API discovery type APIs, etc.

[0035] Service APIs are APIs opened by AEF, also known as APIs on AEF, that can be discovered and called by API-calling entities. These APIs primarily include service-specific APIs that allow API-calling entities to access operator resources and services, such as Quality of Service (QoS) control APIs, broadcast APIs, and Internet of Things (IoT) APIs.

[0036] It should be pointed out that the nouns and steps involved in the various embodiments of the present disclosure can be borrowed and referenced from each other, and the same or descriptions will not be repeated. The execution order of the steps in the various embodiments can be interchanged without limitation.

[0037] It should be noted that Figure 1 This is just an illustrative framework diagram. Figure 1 The number of devices included in the Figure 1 In addition to the devices shown, the system may also include other devices. The system may also be connected to other systems, such as a third-party management system, which is not limited by the present disclosure.

[0038] The application scenarios of the embodiments of the present disclosure are not limited. The system architecture and business scenarios described in the embodiments of the present disclosure are intended to more clearly illustrate the technical solutions of the embodiments of the present disclosure and do not constitute a limitation on the technical solutions provided by the embodiments of the present disclosure. Persons skilled in the art will appreciate that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present disclosure are equally applicable to similar technical problems.

[0039] like Figure 2 As shown, an embodiment of the present disclosure provides a resource calling method, which is applied to a first entity and includes the following steps:

[0040] S101: In response to a call request from an application programming interface (API) calling entity, determine target user consent information in at least one user consent information.

[0041] A call request is used to request an API call to access a target resource.

[0042] The target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API.

[0043] In some embodiments, the user consent information includes a user consent result. The user consent result indicates whether the API calling entity is allowed to access the target resource by calling the API. For example, "granted" indicates consent, and "notgranted" indicates disapproval. For another example, "1" indicates consent, and "0" indicates disapproval.

[0044] In some embodiments, the target user consent information is the user consent information with the highest priority among the at least one user consent information.

[0045] In some embodiments, the priority of the user consent information is related to the update frequency of the user consent information and / or the timestamp corresponding to the user consent information.

[0046] The timestamp corresponding to the user consent information may be the time when the user consent information is obtained.

[0047] In some embodiments, the priority of user consent information is positively correlated with the frequency of its update. User consent information with a higher update frequency is prioritized to ensure the timeliness of user consent information and reduce misjudgments of resource permissions due to delayed user consent information.

[0048] In some embodiments, dynamic user consent information has a higher priority than semi-static user consent information; dynamic user consent information has a higher priority than static user consent information; and semi-static user consent information has a higher priority than static user consent information. It is understood that dynamic user consent information is updated more frequently than semi-static user consent information, and semi-static user consent information is updated more frequently than static user consent information. Therefore, dynamic user consent information has the highest timeliness, while static user consent information has the lowest timeliness.

[0049] In some embodiments, the priority of user consent information is negatively correlated with the absolute value of the difference between the timestamp corresponding to the user consent information and the current time. This prioritizes user consent information closer to the current time, ensuring that the user consent information is the most recent and improving the accuracy of the API call entity permissions determined using the user consent information.

[0050] In some embodiments, the first entity includes the CCF and the AEF. That is, the entity used to determine the user consent information includes the CCF and the AEF.

[0051] In some embodiments, the source of the at least one user consent information is a second entity, and the second entity includes at least one of the following:

[0052] AEF;

[0053] CCF;

[0054] Mobile network operator (MNO);

[0055] Third-party management system;

[0056] Resource owner function (ROF).

[0057] The AEF may pre-store user consent information or obtain and store user consent information from the MNO. The API provider domain (e.g., AEF and NEF) may obtain relevant user consent information obtained by the MNO from the UE and store it in the UDM / UDR.

[0058] The CCF may store the user consent information in advance, or may obtain and store the user consent information from the ROF.

[0059] The MNO may collect and store user consent information.

[0060] The third-party management system is a management system that can be used to collect and store user consent information.

[0061] It is understood that the source from which the first entity obtains the user consent information is connected to the first entity. For example, the first entity can obtain the user consent information provided by a third-party management system, and the third-party management system can then achieve mutual authentication with the first entity and establish a connection relationship.

[0062] In some embodiments, the first entity is a CCF, and the CCF is responsible for determining the target user consent information in the at least one user consent information.

[0063] In some embodiments, the CCF directly receives the call request sent by the API calling entity; or receives the call request of the API calling entity forwarded by the AEF.

[0064] In some embodiments, the CCF sends a first request message to a second entity, the first request message being used to request user consent information. The CCF receives a first response message from the second entity, the first response message including the user consent information provided by the second entity. The second entity includes all sources of user consent information other than the CCF.

[0065] In some embodiments, the CCF sends target user consent information to the AEF.

[0066] In some embodiments, the CCF receives indication information sent by the AEF for indicating whether the API calling entity is allowed to access the target resource by calling the API, and sends response information of the call request to the API calling entity, where the response information of the call request includes the indication information.

[0067] In some embodiments, the CCF sends response information of the call request to the API calling entity through the AEF, and the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0068] In some embodiments, the response information of the call request includes target user consent information.

[0069] For example, Figure 3 Provide an interactive flow chart of a resource calling method, wherein: Figure 3 The target user consent information is determined by CCF. Figure 3 As shown, the following steps are included:

[0070] S201. The AEF pre-stores user consent information provided by the MNO, such as static / semi-static user consent information provided by the MNO.

[0071] S202: The API calling entity sends a call request to the CCF. The call request is used to request to call the API to access the target resource.

[0072] S203: The CCF sends a first request message to the AEF. The first request message is used to request user consent information.

[0073] S204. The CCF receives a first response message sent by the AEF. The first response message includes user consent information provided by the AEF. In some embodiments, the user consent information provided by the AEF includes user consent information provided by the MNO and pre-stored by the AEF and user consent information pre-configured by the AEF.

[0074] S205: The CCF sends a first request message to the third-party management system. The first request message is used to request user consent information. The third-party management system has been mutually authenticated with the AEF.

[0075] S206: The CCF receives a first response message sent by the third-party management system. If the third-party management system has user consent information related to the call request, the first response message includes the user consent information provided by the third-party management system.

[0076] S207: The CCF sends a first request message to the ROF. The first request message is used to request user consent information.

[0077] S208. The CCF receives the first response information sent by the ROF. The first response information includes the user consent information provided by the ROF.

[0078] S209. User consent information conflict resolution: CCF determines the target user consent information. The CCF determines the target user consent information from at least one user consent information. In some embodiments, the at least one user consent information includes user consent information provided by a third-party management system, user consent information provided by the AEF, and user consent information obtained by the CCF from the ROF. The CCF may select the target user consent information with the highest priority from the at least one user consent information. The priority determination of the specific user consent information (e.g., based on update frequency or timestamp) is described in the above embodiments or examples and will not be repeated here.

[0079] S210. The CCF sends the target user's consent information to the AEF.

[0080] S211 . AEF processes the call request: The AEF determines whether to allow the API calling entity to access the target resource by calling the API based on the target user's consent information.

[0081] S212: The AEF sends a response message of the call request to the API call entity. The response message of the call request includes indication information for indicating whether the API call entity is allowed to access the target resource by calling the API.

[0082] Figure 3 For other related contents, please refer to the description in the above embodiments or examples and will not be repeated here. Figure 3 The execution order of the steps in the figure can be interchanged, or some steps can be omitted, which is determined based on the actual application scenario and is not limited. The same applies to the subsequent figures, and they will not be described in detail later.

[0083] It is understood that when the first entity obtains user consent information from a user consent information source other than the first entity, it may only obtain user consent information that is not stored by the first entity itself, and does not need to repeatedly obtain user consent information from existing sources in the first entity; or, for user consent information from existing sources in the first entity, the first entity may update the user consent information from these sources based on a preset frequency. The preset frequency may be determined based on the update frequency of the user consent information from these sources.

[0084] For example, Figure 4 Provide an interactive flow chart of a resource calling method, wherein: Figure 4 The target user consent information is determined by CCF. Figure 4 As shown, the following steps are included:

[0085] S301. The AEF pre-stores user consent information provided by the MNO, such as static / semi-static user consent information provided by the MNO.

[0086] S302: The API calling entity sends a call request to the AEF. The call request is used to request to call the API to access the target resource.

[0087] S303: AEF forwards the call request to CCF.

[0088] S304: The CCF sends a first request message to the AEF. The first request message is used to request user consent information.

[0089] S305. The CCF receives a first response message sent by the AEF. The first response message includes user consent information provided by the AEF. In some embodiments, the user consent information provided by the AEF includes user consent information provided by the MNO and pre-stored by the AEF and user consent information pre-configured by the AEF.

[0090] S306: The CCF sends a first request message to the third-party management system. The first request message is used to request user consent information. The third-party management system has been mutually authenticated with the AEF.

[0091] S307: The CCF receives a first response message sent by the third-party management system. If the third-party management system has user consent information related to the call request, the first response message includes the user consent information provided by the third-party management system.

[0092] S308: The CCF sends a first request message to the ROF. The first request message is used to request user consent information.

[0093] S309. The CCF receives the first response information sent by the ROF. The first response information includes the user consent information provided by the ROF.

[0094] S310. User consent information conflict resolution: CCF determines the target user consent information. The CCF determines the target user consent information from at least one user consent information. In some embodiments, the at least one user consent information includes user consent information provided by a third-party management system, user consent information obtained from the ROF and provided by the CCF, and user consent information provided by the AEF. The AEF may select the target user consent information with the highest priority from the at least one user consent information. The priority determination of specific user consent information (e.g., based on update frequency or timestamp) refers to the above-mentioned embodiments or examples and will not be repeated here.

[0095] S311. CCF sends target user consent information to AEF.

[0096] S312. AEF processes the call request: The AEF determines whether to allow the API calling entity to access the target resource by calling the API based on the target user's consent information.

[0097] S313. The AEF sends indication information to the CCF, indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0098] S314. The CCF sends response information of the call request to the API call entity. The response information of the call request includes instruction information.

[0099] In some embodiments, the first entity is an AEF, and the AEF is responsible for determining the target user consent information in the at least one user consent information.

[0100] In some embodiments, the AEF directly receives the call request sent by the API calling entity; or receives the call request of the API calling entity forwarded by the CCF.

[0101] In some embodiments, the AEF sends a second request message to the second entity, the second request message being used to request user consent information. The AEF receives a second response message from the second entity, the second response message including the user consent information provided by the second entity; the second entity includes all sources of user consent information other than the AEF.

[0102] In some embodiments, the AEF sends response information of the call request to the API calling entity, where the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0103] In some embodiments, the AEF sends a conflict resolution notification message to the CCF, where the conflict resolution notification message is used to indicate the source of the selected target user consent information.

[0104] For example, Figure 5 Provides an interactive flow chart of a resource calling method. Figure 5 The target user consent information is determined by AEF. Figure 5 As shown, the following steps are included:

[0105] S401. The AEF pre-stores user consent information provided by the MNO, such as static / semi-static user consent information provided by the MNO.

[0106] S402: The API calling entity sends a call request to the CCF. The call request is used to request to call the API to access the target resource.

[0107] S403. Obtain user consent information provided by the ROF. In some embodiments, the CCF sends a first request message to the ROF. The first request message is used to request obtaining user consent information. The CCF receives a first response message sent by the ROF, which includes the user consent information provided by the ROF network element.

[0108] S404. The CCF forwards the call request and the user consent information related to the call request obtained from the ROF to the AEF.

[0109] S405: The AEF sends a first request message to the third-party management system. The first request message is used to request user consent information. The third-party management system has already authenticated the AEF.

[0110] S406: The AEF receives a first response message sent by the third-party management system. If the third-party management system has user consent information related to the call request, the first response message includes the user consent information provided by the third-party management system.

[0111] S407. User consent information conflict resolution: The AEF determines the target user consent information. The AEF determines the target user consent information from the at least one user consent information. In some embodiments, the at least one user consent information includes user consent information provided by a third-party management system, user consent information obtained from the ROF and provided by the CCF, and user consent information provided by the AEF. The AEF may select the target user consent information with the highest priority from the at least one user consent information. The specific priority determination of the user consent information (e.g., based on update frequency or timestamp) is described in the above embodiments or examples and will not be further elaborated here.

[0112] S408. AEF processes the call request: The AEF determines whether to allow the API calling entity to access the target resource by calling the API based on the target user's consent information.

[0113] S409. The AEF sends response information of the call request to the API calling entity. The response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0114] Figure 5 The method may also include steps other than the above steps. For example, the AEF sends a conflict resolution notification message to the CCF, where the conflict resolution notification message indicates the source of the selected target user consent information. Another example is the step where the AEF requests the MNO to obtain the user consent information related to the call request.

[0115] In some embodiments, S409 may be replaced by the AEF sending, to the CCF, indication information indicating whether the API calling entity is allowed to access the target resource by calling the API. The CCF sends, to the API calling entity, response information for the call request, including indication information indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0116] For example, Figure 6Provides an interactive flow chart of a resource calling method. Figure 6 The target user consent information is determined by AEF. Figure 6 As shown, the following steps are included:

[0117] S501. The AEF pre-stores user consent information provided by the MNO, such as static / semi-static user consent information provided by the MNO.

[0118] S502: The API calling entity sends a call request to the AEF. The call request is used to request to call the API to access the target resource.

[0119] S503: The AEF forwards the call request to the CCF.

[0120] S504. The CCF obtains user consent information provided by the ROF. In some embodiments, a first request message is sent to the ROF. The first request message is used to request user consent information. The CCF receives a first response message sent by the ROF, which includes the user consent information provided by the ROF network element.

[0121] S505. The CCF sends the user consent information related to the call request obtained from the ROF to the AEF.

[0122] S506: The AEF sends a first request message to the third-party management system. The first request message is used to request user consent information. The third-party management system has already authenticated the AEF.

[0123] S507: The AEF receives a first response message sent by the third-party management system. If the third-party management system has user consent information related to the call request, the first response message includes the user consent information provided by the third-party management system.

[0124] S508. User consent information conflict resolution: The AEF determines the target user consent information. The AEF determines the target user consent information from the at least one user consent information. In some embodiments, the at least one user consent information includes user consent information provided by a third-party management system, user consent information provided by the CCF, and user consent information provided by the MNO and pre-stored by the AEF. The AEF may select the highest priority information from the at least one user consent information as the target user consent information. The specific priority determination of the user consent information (e.g., based on update frequency or timestamp) is described in the above embodiments or examples and will not be further elaborated here.

[0125] S509 , AEF processes the call request: The AEF determines whether to allow the API calling entity to access the target resource by calling the API based on the target user's consent information.

[0126] S510. The AEF sends indication information to the CCF for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0127] S511. The CCF sends response information of the call request to the API calling entity. The response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0128] Figure 6 Steps other than the above steps may also be included. For example, the AEF sends a conflict resolution notification message to the CCF. The conflict resolution notification message is used to indicate the source of the selected target user consent information. The conflict resolution notification message may be sent together with the indication information in step S510 or separately, and this disclosure is not limited thereto. Another example is the step of the AEF requesting the MNO to obtain user consent information related to the call request.

[0129] In some embodiments, the second entity includes only one item and is pre-set or determined through negotiation. In this way, if there are multiple entities providing user consent information, a single entity can be designated in advance to ensure that there is only one source of user consent information when deciding whether to allow the API calling entity to access the target resource by calling the API.

[0130] In some embodiments, the second entity is one of the following:

[0131] AEF;

[0132] CCF;

[0133] MNO;

[0134] Third-party management system;

[0135] ROF.

[0136] In some embodiments, the second entity includes only one item and is determined by negotiation between the CCF and the AEF.

[0137] In some embodiments, the first entity is a CCF, which receives an API call request. The CCF sends a third request message to an AEF, where the third request message is used to request the source of the user consent information currently available to the AEF. The CCF receives a third response message from the AEF, where the third response message includes the source of the user consent information currently available to the AEF.

[0138] The source of the user consent information that the AEF can currently receive includes the second entity.

[0139] In some embodiments, the second entity is determined by negotiation between the AEF and the CCF to be the ROF. The CCF sends a permission negotiation request to the AEF. The permission negotiation request is sent by the CCF based on the source of user consent information currently available to the AEF. The permission negotiation request is used to request that the AEF only use the user consent information obtained by the CCF from the ROF. The CCF receives a permission negotiation response from the AEF. The permission negotiation response is used to indicate whether the AEF agrees to only use the user consent information obtained by the CCF from the ROF.

[0140] In some embodiments, the first entity is an AEF, which sends an API call request to a CCF. The AEF receives a third request message from the CCF, where the third request message is used to request the source of the user consent information currently available to the AEF. The AEF sends a third response message to the CCF, where the third response message includes the source of the user consent information currently available to the AEF.

[0141] The source of the user consent information that the AEF can currently receive includes the second entity.

[0142] In some embodiments, the second entity is determined by negotiation between the AEF and the CCF to be the ROF. The AEF receives a permission negotiation request from the CCF. The permission negotiation request is sent by the CCF based on the source of user consent information currently available to the AEF. The permission negotiation request is used to request that the AEF only use the user consent information obtained by the CCF from the ROF. The AEF sends a permission negotiation response to the CCF, indicating whether the AEF agrees to only use the user consent information obtained by the CCF from the ROF.

[0143] In some embodiments, the AEF obtains user consent information related to the call request obtained by the CCF from the ROF, including at least one of the following:

[0144] a) The AEF sends a first request message to the CCF, and the AEF receives a first response message from the CCF. The first response message includes the user consent information obtained from the ROF.

[0145] b) After AEF sends an API call request to CCF, AEF receives the user consent information obtained by CCF from ROF.

[0146] c) AEF receives the user consent information obtained by CCF from ROF at the same time as receiving the call request of the API call entity forwarded by CCF.

[0147] For example, Figure 7 Provide an interactive flow chart of a resource calling method, wherein: Figure 7 The second entity is determined by negotiation between AEF and CCF as ROF. Figure 7 As shown, the following steps are included:

[0148] S601. The AEF pre-stores user consent information provided by the MNO, such as static / semi-static user consent information provided by the MNO.

[0149] S602: The CCF sends a third request message (license management system inquiry request message) to the AEF. The third request message is used to request the sources of user consent information that the AEF can currently receive. In other words, the third request message is used to request which license management systems the AEF currently has connections with, that is, which license management systems the AEF is currently managed by. All connected license management systems can serve as sources that can provide the AEF with the requested user consent information.

[0150] S603. The CCF receives a third response message (license management system query response message) sent by the AEF. The third response message includes the sources of user consent information currently available to the AEF. The sources of user consent information currently available to the AEF include the ROF. For example, the sources of user consent information currently available to the AEF include a third-party management system, the MNO, and the ROF.

[0151] S604: The AEF receives a permission negotiation request from the CCF. The permission negotiation request is used to request the AEF to adopt the user consent information obtained by the CCF from the ROF. That is, when the AEF obtains multiple user consent information, it only follows the consent information obtained by the CCF from the ROF.

[0152] S605: The AEF sends a permission negotiation response to the CCF. The permission negotiation response is used to determine whether the AEF agrees to use only the user consent information obtained by the CCF from the ROF.

[0153] Figure 7 The method may also include steps other than the above steps. For example, the CCF sends the user consent information obtained from the ROF to the AEF. For another example, before S602, the CCF receives the API call request.

[0154] In some embodiments, the second entity includes only one item and is pre-set by the AEF.

[0155] In some embodiments, the AEF receives a permission query request sent by the CCF, the permission query request being sent by the CCF based on a source of user consent information currently available to the AEF, the permission query request being used to query the second entity, and the AEF sends a permission query response to the CCF, the permission query response including the second entity.

[0156] In some embodiments, before the AEF receives the permission query request sent by the CCF, the process further includes: the AEF receiving a third request message sent by the CCF, the third request message being used to request a source of user consent information currently available to the AEF. The AEF sends a third response message to the CCF, the third response message including a source of user consent information currently available to the AEF. The source of user consent information currently available to the AEF includes the second entity.

[0157] In some embodiments, before the AEF receives the third request information sent by the CCF, the process further includes: the CCF receives the call request.

[0158] In some embodiments, the second entity is a ROF, and the AEF obtains at least one user consent information provided by a ROF network element from the CCF.

[0159] In some embodiments, the second entity is a third-party management system. The AEF obtains at least one user consent information from the third-party management system; or the AEF obtains at least one user consent information provided by the third-party management system from the CCF.

[0160] In some embodiments, the second entity is an MNO, and the AEF obtains at least one user consent information from the MNO.

[0161] It should be understood that when the second entity included in the permission query response is different, the signaling interaction process corresponding to the AEF and CCF is different. The details are as follows:

[0162] (1) The source of at least one user consent information is the CCF. The AEF receives at least one user consent information obtained by the CCF from the ROF network element. The target user consent information determined by the AEF is based on the user consent information provided by the CCF.

[0163] (2) At least one source of user consent information is the MNO. The CCF will not adopt the resource owner-aware northbound API access (RNAA) architecture and will not enable the acquisition of relevant user consent information from the ROF. The target user consent information determined by the AEF is based on the user consent information provided by the MNO. In other words, when the AEF determines whether to allow the API call entity resource access rights, it is based on the user consent information provided by the MNO.

[0164] (3) If at least one source of user consent information is a third-party management system, then CCF will not adopt the RNAA architecture and will not start obtaining relevant user consent information from ROF. There are two possible ways for AEF to obtain user consent information:

[0165] a) AEF interacts directly with the third-party management system: AEF sends a first request message to the third-party management system, and the third-party management system sends a first response message to AEF. The first response message carries the user consent information provided by the third-party management system.

[0166] b) The CCF directly interacts with the third-party management system and sends the user consent information obtained from the third-party management system to the AEF. The CCF sends a first request message to the third-party management system, and the third-party management system sends a first response message to the CCF. The first response message carries the user consent information provided by the third-party management system.

[0167] If the third-party management system is a management mechanism recognized by the CCF and AEF and is considered to be introduced specifically to resolve user consent information conflicts, the AEF can ignore user consent information provided by other sources (such as RNAAs and MNOs) and only interact with the third-party management system to obtain at least one user consent information used to determine the target user consent information. Both the CCF and the AEF have completed mutual authentication with the third-party management system. In other words, the source (second entity) of the at least one user consent information used by the AEF to determine the target user consent information is the third-party management system.

[0168] In some embodiments, the second entity is a third-party management system, and the AEF obtains at least one user consent information from the third-party management system; or, the AEF receives at least one user consent information obtained by the CCF from the third-party management system.

[0169] In some embodiments, the AEF sends a first request message to the third-party management system, and the third-party management system sends a first response message to the AEF. The first response message carries user consent information related to the call request in the third-party management system.

[0170] In some embodiments, the CCF sends a first request message to the third-party management system, and the third-party management system sends a first response message to the CCF. The first response message carries user consent information related to the call request in the third-party management system. The CCF sends the user consent information related to the call request in the third-party management system to the AEF.

[0171] The AEF obtaining the at least one user consent information provided by the third-party management system has nothing to do with whether the AEF has received the user consent information provided by the MNO and the user consent information provided by the CCF.

[0172] If the AEF always trusts the user consent information provided by the MNO more, then the AEF may ignore the user consent information provided by other sources. That is, the AEF determines that the source (second entity) of at least one user consent information of the target user consent information is the MNO.

[0173] In some embodiments, the second entity is an MNO, and the AEF receives a fourth request message sent by the CCF, where the fourth request message is used to request the source of user consent information that the AEF can currently receive and the source (second entity) of at least one user consent information used by the AEF to determine the target user consent information. The AEF sends a fourth response message to the CCF, where the fourth response message includes the source of user consent information that the AEF can currently receive (such as a third-party management system, MNO, etc.) and the source (second entity) of at least one user consent information determined by the AEF to be the MNO.

[0174] The source of user consent information currently received by the AEF includes at least one source of user consent information. That is, the source of user consent information currently received by the AEF includes at least one source of user consent information used by the AEF to determine target user consent information (that is, including the MNO).

[0175] In some embodiments, after receiving the fourth response information, the CCF will not adopt the RNAA architecture, that is, will not obtain user consent information from the ROF.

[0176] In some embodiments, after receiving the call request from the API calling entity, the AEF determines the target user consent information according to the user consent information provided by the MNO, and determines whether to authorize the API calling entity to access relevant resources based on the target user consent information.

[0177] Based on this, in response to a call request from an application programming interface (API) calling entity, the target user consent information is determined from at least one piece of user consent information. The call request is used to request access to the target resource by calling the API. The target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API. This avoids the problem of difficulty in accurately determining the final user consent information when multiple user consent information is provided. It effectively resolves conflicts between user consent information and ensures that the resource owner's authorization and the user's data processing consent are consistent when the API is called.

[0178] The above mainly introduces the scheme of the embodiment of the present disclosure from the perspective of method. A communication device is also shown below for executing the resource calling method in any of the above embodiments and possible implementations thereof. It can be understood that, in order to implement the resource calling method, the communication device includes hardware structures and / or software modules corresponding to the execution of each function; those skilled in the art should easily realize that, in combination with the algorithm steps of each example described in the embodiment of the present disclosure, the present disclosure can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the target application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each target application, but such implementation should not be considered to exceed the scope of the present disclosure.

[0179] The embodiments of the present disclosure can divide the functional modules of the communication device according to the above-mentioned method embodiments. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one functional module. The above-mentioned integrated modules can be implemented in the form of hardware or software. It should be noted that the division of modules in the embodiments of the present disclosure is schematic and is only a logical functional division. In actual implementation, there may be other division methods. The following is an example of dividing each functional module corresponding to each function.

[0180] Figure 8 The communication device 80 provided by the embodiment of the present disclosure is applied to a first entity. The communication device 80 includes: a processing module 81 and a communication module 82.

[0181] Processing module 81 is used to determine target user consent information in at least one user consent information in response to a call request from an application programming interface (API) calling entity; the call request is used to request the API to access a target resource; the target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API.

[0182] In some embodiments, the target user consent information is the user consent information with the highest priority among the at least one user consent information.

[0183] In some embodiments, the priority of the user consent information is related to at least one of an update frequency of the user consent information and a timestamp corresponding to the user consent information.

[0184] In some embodiments, the priority of the user consent information and the update frequency of the user consent information are positively correlated.

[0185] In some embodiments, dynamic user consent information takes precedence over semi-static user consent information;

[0186] Dynamic user consent information takes precedence over static user consent information;

[0187] Semi-static user consent information has a higher priority than static user consent information.

[0188] In some embodiments, the priority of the user consent information and the absolute value of the difference between the timestamp corresponding to the user consent information and the current time are negatively correlated.

[0189] In some embodiments, the first entity includes a common API framework CAPIF core function CCF or an API open function AEF.

[0190] In some embodiments, the source of the at least one user consent information is a second entity, and the second entity includes at least one of the following:

[0191] AEF;

[0192] CCF;

[0193] Mobile Network Operator (MNO);

[0194] Third-party management system;

[0195] Resource Owner Function ROF.

[0196] In some embodiments, the first entity is a CCF, and the communication module 82 is configured to directly receive a call request sent by an API calling entity; or, to receive a call request from an API calling entity forwarded by an AEF.

[0197] In some embodiments, the first entity is a CCF, and the communication module 82 is specifically configured to:

[0198] Sending a first request message to the second entity, where the first request message is used to request obtaining user consent information;

[0199] Receive first response information sent by the second entity, where the first response information includes user consent information provided by the second entity; the second entity includes all sources of user consent information except the CCF.

[0200] In some embodiments, the first entity is a CCF, and the communication module 82 is configured to send target user consent information to the AEF.

[0201] In some embodiments, the first entity is a CCF, and the communication module 82 is configured to:

[0202] Receive instruction information sent by the AEF for indicating whether the API calling entity is allowed to access the target resource by calling the API;

[0203] Sending a response message of the call request to the API calling entity, wherein the response message of the call request includes instruction information.

[0204] In some embodiments, the first entity is a CCF, and the communication module 82 is configured to:

[0205] The AEF sends response information of the call request to the API calling entity, where the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0206] In some embodiments, the first entity is an AEF, and the communication module 82 is configured to:

[0207] Directly receive the call request sent by the API calling entity; or receive the call request of the API calling entity forwarded by the CCF.

[0208] In some embodiments, the first entity is an AEF, and the communication module 82 is configured to:

[0209] Sending a second request message to the second entity, where the second request message is used to request obtaining user consent information;

[0210] Receive second response information sent by the second entity, where the second response information includes user consent information provided by the second entity; the second entity includes the source of all user consent information except the AEF.

[0211] In some embodiments, the first entity is an AEF, and the communication module 82 is configured to:

[0212] Sending response information of the call request to the API calling entity, where the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

[0213] In some embodiments, the first entity is an AEF, and the communication module 82 is configured to:

[0214] A conflict resolution notification message is sent to the CCF, where the conflict resolution notification message is used to indicate the source of the selected target user consent information.

[0215] In some embodiments, the second entity includes only one item and is determined by pre-setting or negotiation.

[0216] In some embodiments, the first entity is a CCF, and the communication module 82 is configured to:

[0217] Receive API call requests;

[0218] Sending a third request message to the AEF, where the third request message is used to request a source of user consent information that the AEF can currently receive;

[0219] receiving a third response message sent by the AEF, where the third response message includes a source of the user consent information that the AEF can currently receive;

[0220] The source of the user consent information that the AEF can currently receive includes the second entity.

[0221] In some embodiments, the first entity is a CCF, the second entity is an AEF and is determined to be a ROF through negotiation with the CCF, and the communication module 82 is configured to:

[0222] Send a license negotiation request to the AEF. The license negotiation request is sent by the CCF based on the source of the user consent information that the AEF can currently receive. The license negotiation request is used to request the AEF to only use the user consent information obtained by the CCF from the ROF.

[0223] The CCF receives the permission negotiation response sent by the AEF, where the permission negotiation response is used to indicate whether the AEF agrees to use only the user consent information obtained by the CCF from the ROF.

[0224] In some embodiments, the first entity is an AEF, and the communication module 82 is configured to:

[0225] Send an API call request to CCF;

[0226] receiving a third request message sent by the CCF, where the third request message is used to request the source of the user consent information that the AEF can currently receive;

[0227] Sending a third response message to the CCF, where the third response message includes a source of the user consent information that the AEF can currently receive;

[0228] The source of the user consent information that the AEF can currently receive includes the second entity.

[0229] In some embodiments, the first entity is an AEF, the second entity is a ROF determined by negotiation between the AEF and the CCF, and the communication module 82 is configured to:

[0230] Receive a license negotiation request from the CCF. The license negotiation request is sent by the CCF based on the source of the user consent information that the AEF can currently receive. The license negotiation request is used to request the AEF to only use the user consent information obtained by the CCF from the ROF;

[0231] The AEF sends a permission negotiation response to the CCF, where the permission negotiation response is used to indicate whether the AEF agrees to use only the user consent information obtained by the CCF from the ROF.

[0232] In some embodiments, the first entity is an AEF, the second entity is pre-set by the AEF, and the communication module 82 is configured to:

[0233] receiving a permission query request sent by the CCF, where the permission query request is sent by the CCF based on a source of user consent information that the AEF can currently receive, and the permission query request is used to query the second entity;

[0234] The AEF sends an authorization query response to the CCF, where the authorization query response includes the second entity.

[0235] In some embodiments, the first entity is an AEF, the second entity is a ROF, and the communication module 82 is configured to:

[0236] Obtain at least one user consent information provided by the ROF network element from the CCF.

[0237] In some embodiments, the first entity is an AEF, the second entity is a third-party management system, and the communication module 82 is configured to:

[0238] Obtain at least one user consent information from a third-party management system; or,

[0239] Obtain at least one piece of user consent information provided by the third-party management system from the CCF.

[0240] In some embodiments, the first entity is an AEF, the second entity is an MNO, and the communication module 82 is configured to obtain at least one user consent information from the MNO.

[0241] For a more detailed description of the processing module 81 and the communication module 82, as well as a more detailed description of the technical features therein and a description of the beneficial effects, etc., please refer to the corresponding method embodiment section above and will not be repeated here.

[0242] It should be noted that Figure 8 The modules in the system can also be called units, for example, the communication module can be called a communication unit. Figure 8 In the illustrated embodiment, the names of the modules may not be the names shown in the figure. For example, the communication module may also be called a sending module or a receiving module.

[0243] Figure 8If the various units or modules in the embodiment are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present disclosure is essentially or the part that contributes to the relevant technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present disclosure. The storage medium for storing computer software products includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk and other media that can store program code.

[0244] In the case of implementing the functions of the above-mentioned integrated modules in the form of hardware, the embodiment of the present disclosure also provides a possible structure of a communication device, which is used to execute the resource calling method provided by the embodiment of the present disclosure. Figure 9 As shown, the communication device 900 includes: a communication interface 903, a processor 902 and a bus 904. Optionally, the communication device may further include a memory 901.

[0245] Processor 902 may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments of this disclosure. Processor 902 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the embodiments of this disclosure. Processor 902 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0246] The communication interface 903 is used to connect to other devices via a communication network, such as Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0247] The memory 901 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0248] As a possible implementation, the memory 901 can exist independently of the processor 902. The memory 901 can be connected to the processor 902 via a bus 904 and used to store instructions or program codes. When the processor 902 calls and executes the instructions or program codes stored in the memory 901, the resource calling method provided in the embodiment of the present disclosure can be implemented.

[0249] In another possible implementation, the memory 901 may also be integrated with the processor 902 .

[0250] The bus 904 may be an extended industry standard architecture (EISA) bus, etc. The bus 904 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0251] Some embodiments of the present disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium), which stores computer program instructions. When the computer program instructions are executed on a computer, the computer executes the resource calling method described in any of the above embodiments.

[0252] In an exemplary embodiment, the computer may be the aforementioned communication device, and the present disclosure does not limit the specific form of the computer.

[0253] In some examples, the computer-readable storage media described above may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs), etc.), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROM), cards, sticks, or key drives, etc.). The various computer-readable storage media described in this disclosure may represent one or more devices and / or other machine-readable storage media for storing information. The term "machine-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing, and / or carrying instructions and / or data.

[0254] An embodiment of the present disclosure provides a computer program product comprising instructions. When the computer program product is run on a computer, the computer is enabled to execute the resource calling method described in any one of the above embodiments.

[0255] The above is only a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or replacements within the technical scope disclosed in the present disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A resource calling method, characterized in that: Applied to a first entity, the method comprises: In response to a call request from an application programming interface (API) calling entity, target user consent information is determined in at least one user consent information; the call request is used to request the API to be called to access a target resource; the target user consent information is used to determine whether the API calling entity is allowed to access the target resource by calling the API.

2. The method according to claim 1, characterized in that The target user consent information is the user consent information with the highest priority among the at least one user consent information.

3. The method according to claim 2, characterized in that The priority of the user consent information is related to at least one of an update frequency of the user consent information and a timestamp corresponding to the user consent information.

4. The method according to claim 2, characterized in that There is a positive correlation between the priority of the user consent information and the update frequency of the user consent information.

5. The method according to claim 4, characterized in that Dynamic user consent information takes precedence over semi-static user consent information; Dynamic user consent information takes precedence over static user consent information; Semi-static user consent information has a higher priority than static user consent information.

6. The method according to claim 2, characterized in that The priority of the user consent information and the absolute value of the difference between the timestamp corresponding to the user consent information and the current time are negatively correlated.

7. The method according to claim 1, characterized in that The first entity includes the common API framework CAPIF core function CCF or API open function AEF.

8. The method according to claim 7, characterized in that The source of the at least one user consent information is a second entity, and the second entity includes at least one of the following: AEF; CCF; Mobile Network Operator (MNO); Third-party management system; Resource Owner Function ROF.

9. The method according to claim 7, characterized in that The first entity is the CCF, and the method further includes: directly receiving the call request sent by the API calling entity; or, receiving the call request of the API calling entity forwarded by an AEF.

10. The method according to claim 8, characterized in that The first entity is the CCF, and the method further includes: Sending a first request message to the second entity, where the first request message is used to request obtaining user consent information; Receive first response information sent by the second entity, where the first response information includes user consent information provided by the second entity; the second entity includes sources of all user consent information except the CCF.

11. The method according to claim 7, characterized in that The first entity is the CCF, and the method further includes: Send the target user consent information to AEF.

12. The method according to claim 11, characterized in that The method further comprises: receiving indication information sent by the AEF for indicating whether the API calling entity is allowed to access the target resource by calling the API; Sending response information of the call request to the API calling entity, where the response information of the call request includes the indication information.

13. The method according to claim 11, characterized in that The first entity is the CCF, and the method further includes: The CCF sends response information of the call request to the API calling entity through the AEF, where the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

14. The method according to claim 7, wherein: The first entity is the AEF, and the method further includes: Directly receive the call request sent by the API call entity; or, receive the call request of the API call entity forwarded by the CCF.

15. The method according to claim 8, characterized in that The first entity is the AEF, and the method further includes: Sending a second request message to the second entity, where the second request message is used to request obtaining user consent information; Receive second response information sent by the second entity, where the second response information includes user consent information provided by the second entity; the second entity includes the source of all user consent information except the AEF.

16. The method according to claim 7, characterized in that The first entity is the AEF, and the method further includes: Sending response information of the call request to the API calling entity, wherein the response information of the call request includes indication information for indicating whether the API calling entity is allowed to access the target resource by calling the API.

17. The method according to claim 7, characterized in that The first entity is the AEF, and the method further includes: A conflict resolution notification message is sent to the CCF, where the conflict resolution notification message is used to indicate the source of the selected target user consent information.

18. The method according to claim 8, characterized in that The second entity includes only one item and is determined by presetting or negotiation.

19. The method according to claim 18, characterized in that The first entity is the CCF, and the method further includes: The CCF receives the API call request; The CCF sends a third request message to the AEF, where the third request message is used to request a source of user consent information that the AEF can currently receive; The CCF receives third response information sent by the AEF, where the third response information includes a source of user consent information that the AEF can currently receive; The source of the user consent information that the AEF can currently receive includes the second entity.

20. The method according to claim 19, characterized in that The second entity is determined by negotiation between the AEF and the CCF to be the ROF, and the method further includes: The CCF sends a license negotiation request to the AEF, where the license negotiation request is sent by the CCF based on a source of user consent information that the AEF can currently receive, and the license negotiation request is used to request the AEF to only use the user consent information obtained by the CCF from the ROF; The CCF receives a permission negotiation response sent by the AEF, where the permission negotiation response is used to indicate whether the AEF agrees to only use the user consent information obtained by the CCF from the ROF.

21. The method according to claim 18, wherein The first entity is the AEF, and the method further includes: The AEF sends the API call request to the CCF; The AEF receives a third request message sent by the CCF, where the third request message is used to request a source of user consent information that the AEF can currently receive; The AEF sends third response information to the CCF, where the third response information includes a source of user consent information that the AEF can currently receive; The source of the user consent information that the AEF can currently receive includes the second entity.

22. The method according to claim 21, characterized in that The second entity is determined by negotiation between the AEF and the CCF to be the ROF, and the method further includes: The AEF receives a permission negotiation request sent by the CCF, where the permission negotiation request is sent by the CCF based on a source of user consent information currently receivable by the AEF, and the permission negotiation request is used to request the AEF to adopt only the user consent information obtained by the CCF from the ROF; The AEF sends a permission negotiation response to the CCF, where the permission negotiation response is used to indicate whether the AEF agrees to only use the user consent information obtained by the CCF from the ROF.

23. The method according to claim 21, characterized in that The second entity is pre-set by the AEF, and the method further includes: The AEF receives a permission query request sent by the CCF, where the permission query request is sent by the CCF based on a source of user consent information currently receivable by the AEF, and is used to query the second entity; The AEF sends a permission query response to the CCF, where the permission query response includes the second entity.

24. The method according to claim 23, wherein The second entity is the ROF, and the method further includes: The AEF obtains the at least one user consent information provided by the ROF network element from the CCF.

25. The method according to claim 23, characterized in that The second entity is the third-party management system, and the method further includes: The AEF obtains the at least one user consent information from the third-party management system; or, The AEF obtains the at least one user consent information provided by the third-party management system from the CCF.

26. The method according to claim 23, wherein The second entity is the MNO, and the method further includes: The AEF obtains the at least one user consent information from the MNO.

27. A communication device, characterized in that: include: memory and processor; Memory and processor coupling; The memory is used to store instructions executable by the processor; When the processor executes the instructions, the method according to any one of claims 1 to 26 is performed.

28. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a communication device, the communication device is caused to perform the method according to any one of claims 1 to 26.

29. A computer program product, characterized in that When the computer program product is executed, the method according to any one of claims 1 to 26 is implemented.

Images