Information processing method, device, communication system, and storage medium

Abstract

Embodiments of the present disclosure provide an information processing method, a device, a communication system, and a storage medium. The information processing method is executed by a first device, and comprises: receiving a first message sent by a second device, wherein the first message is used for requesting the first device to send a second token to the second device on the basis of a first token, or the first message is used for requesting the second token; and sending, to the second device, a first response determined on the basis of the first message.

Description

Information processing methods, equipment, communication systems and storage media Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to an information processing method, device, communication system and storage medium. Background Technology

[0002] In the field of communication technology, the Common API Framework (CAPIF) system has been introduced; the CAPIF system can be used to authorize API invokers to access communication systems.

[0003] Summary of the Invention

[0004] The embodiments disclosed herein aim to address the inability to securely access the service information of another AEF through the authorization information of the API caller provided by the API Exposing Function (AEF) of the Application Programming Interface Framework Core Function (CCF).

[0005] According to a first aspect of the present disclosure, an information processing method is proposed, executed by a first device, comprising: receiving a first message sent by a second device; wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and sending a first response determined based on the first message to the second device.

[0006] According to a second aspect of the present disclosure, an information processing method is proposed, executed by a second device, comprising: sending a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and receiving a first response sent by the first device, wherein the first response is determined based on the first message.

[0007] According to a third aspect of the present disclosure, an information processing method is proposed, executed by a third device, comprising: receiving a fifth message sent by a second device, wherein the fifth message includes a second token of the second device, and the fifth message is used to request the invocation of service information of the third device; and sending a fourth response to the second device, wherein the fourth response is used to indicate a response related to the service information of the third device.

[0008] According to a fourth aspect of the present disclosure, an information processing method is proposed, executed by a fourth device, comprising: sending a third message to a first device, wherein the third message is used to request a first token; receiving a third response sent by the first device, wherein the third response includes the first token; wherein the first token is used by the fourth device to send to a second device, causing the second device to send a first message to the first device; the first message is used to request the first device to send a second token to the second device based on the first token.

[0009] According to a fifth aspect of the present disclosure, an information processing method is proposed, comprising: a second device sending a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; the first device sending a first response to the second device, wherein the response includes the second token.

[0010] According to a sixth aspect of the present disclosure, a first device is provided, comprising: a first transceiver module configured to: receive a first message sent by a second device; wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and send a first response determined based on the first message to the second device.

[0011] According to a seventh aspect of the present disclosure, a second device is provided, comprising: a second transceiver module configured to send a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and to receive a first response sent by the first device, wherein the first response is determined based on the first message.

[0012] According to an eighth aspect of the present disclosure, a third device is provided, comprising: a third transceiver module configured to receive a fifth message sent by a second device, wherein the fifth message includes a second token of the second device and is used to request the invocation of service information of the third device; and to send a fourth response to the second device, wherein the fourth response is used to indicate a response related to the service information of the third device.

[0013] According to a ninth aspect of the present disclosure, a fourth device is provided, comprising: a fourth transceiver module configured to send a third message to a first device, wherein the third message is used to request a first token; and to receive a third response sent by the first device, wherein the third response includes the first token; wherein the first token is used by the fourth device to send to a second device, causing the second device to send a first message to the first device; and the first message is used to request the first device to send a second token to the second device based on the first token.

[0014] According to a tenth aspect of the present disclosure, a communication device is provided, comprising one or more processors; wherein the communication device is configured to execute, as in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or optional implementations of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0015] According to an eleventh aspect of the present disclosure, a communication system is provided, comprising: a first device, a second device, a third device, and a fourth device; wherein the first device is configured to perform a method as described in an optional implementation of the first aspect, the second device is configured to perform a method as described in an optional implementation of the second aspect, the third device is configured to perform a method as described in an optional implementation of the third aspect, and the fourth device is configured to perform a method as described in an optional implementation of the fourth aspect.

[0016] According to a twelfth aspect of the present disclosure, a storage medium is provided that stores instructions which, when executed on a communication device, cause the communication device to perform the method described in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or an optional implementation of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0017] According to a thirteenth aspect of the present disclosure, a computer program product is provided, the computer program product including a computer program or instructions, which, when executed by a processor, implement the methods described in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or optional implementations of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0018] The embodiments disclosed herein enable an AEF to securely access the service information of another AEF through the authorization information of the API caller provided by the CCF. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings required for the description of the embodiments are introduced below. The following drawings are only some embodiments of this disclosure and do not impose specific limitations on the protection scope of this disclosure.

[0020] Figure 1A is a schematic diagram of the structure of an information processing system according to an embodiment of the present disclosure.

[0021] Figure 1B is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0022] Figure 2A is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0023] Figure 2B is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0024] Figure 2C is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0025] Figure 3A is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0026] Figure 3B is an interactive schematic diagram of an information processing method according to an embodiment of the present disclosure.

[0027] Figure 4A is a schematic flowchart illustrating an information processing method according to an embodiment of the present disclosure.

[0028] Figure 4B is a schematic flowchart illustrating an information processing method according to an embodiment of the present disclosure.

[0029] Figure 5A is a schematic diagram of the structure of a first device according to an embodiment of the present disclosure.

[0030] Figure 5B is a schematic diagram of the structure of a second device according to an embodiment of the present disclosure.

[0031] Figure 5C is a schematic diagram of the structure of a third device according to an embodiment of the present disclosure.

[0032] Figure 5D is a schematic diagram of the structure of a fourth device according to an embodiment of the present disclosure.

[0033] Figure 6A is a schematic diagram of the structure of a communication device provided according to an embodiment of the present disclosure.

[0034] Figure 6B is a schematic diagram of the structure of a chip provided according to an embodiment of the present disclosure. Detailed Implementation

[0035] This disclosure provides an information processing method, apparatus, communication system, and storage medium.

[0036] In a first aspect, embodiments of this disclosure propose an information processing method, executed by a first device, comprising: receiving a first message sent by a second device; wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and sending a first response determined based on the first message to the second device.

[0037] In the above embodiments, the second device can send a token exchange request or a first message related to the token request to the first device, causing the first device to send a response to the first message. When the first response includes a second token, the second device can obtain the second token provided by the first device (this second token is the authorization information for the second device), thereby facilitating complete access by the second device to the listeners (e.g., the third device) listed in the second token. Especially when a resource owner is involved, the second device can directly access the service information of the third device based on the authorization information provided by the first device, without needing mutual authentication with the resource owner, reducing resource waste caused by mutual authentication with the resource owner.

[0038] In conjunction with some embodiments of the first aspect, in some embodiments, the first message is used to request the first device to send a second token to the second device based on the first token. The first message includes at least one of the following: a first token; a third token, wherein the third token is used to indicate the identity of the second device; a type identifier, wherein the type identifier is used to indicate token exchange; a first device identifier, wherein the first device identifier is the identifier of the third device, and the third device is the device that the fourth device requests access to; a first service identifier, wherein the first service identifier is used to indicate the service information of the third device; or, when the first message is used to request the second token, the first message includes at least one of the following: a first device identifier; a first service identifier.

[0039] In the above embodiments, the contents included in the first message are clearly defined; for example, when the first message is used to request the exchange of tokens, the first message may include a first token and a third token, which is beneficial for the first device to determine whether the authorized actor of the first token is an authenticated second device based on the third token; or, when the first message is used to request the exchange of tokens, the first message may include a first device identifier and a first service identifier of the third device, which is beneficial for the first device to generate a second token for the third device as a listener based on the first device identifier and the first service identifier of the third device.

[0040] In conjunction with some embodiments of the first aspect, in some embodiments, the first token includes at least one of the following: a second device identifier, wherein the second device identifier is an identifier of the first device, and the second device identifier is set as a publisher statement in the first token statement; a third device identifier, wherein the third device identifier is an identifier of the second device, and the third device identifier is set as a listener statement in the first token statement, and the third device identifier is also set as an authorized actor statement in the first token statement; a fourth device identifier, wherein the fourth device identifier is an identifier of the fourth device, and the fourth device identifier is set as a subject statement in the first token statement; a second service identifier, wherein the second service identifier is used to indicate service information of the second device, and the second service identifier is set as a scope statement in the first token statement; and a resource owner identifier, wherein the resource owner identifier is an identifier of the resource owner, and the resource owner identifier is set as a resource owner identifier statement in the first token statement.

[0041] In the above embodiments, the contents included in the first token are clearly defined. For example, if the authorized actor declared in the first token is the second device, it means that the second device can act as the API caller in place of the fourth device, which means that the second device can use the first token.

[0042] In conjunction with some embodiments of the first aspect, in some embodiments, when the first message is used to request the first device to send a second token to the second device based on the first token, the second token includes at least one of the following: a second device identifier, wherein the second device identifier is the identifier of the first device, and the second device identifier is set as a publisher declaration in the second token statement; a first device identifier, wherein the first device identifier is the identifier of a third device, and the first device identifier is set as a listener declaration in the second token statement; a fourth device identifier, wherein the fourth device identifier is the identifier of a fourth device, and the fourth device identifier is set as a subject declaration in the second token statement; a first service identifier, wherein the first service identifier is used to indicate service information of the third device, and the first service identifier is set as a scope declaration in the second token statement; a resource owner identifier, wherein the resource owner identifier is the identifier of a resource owner, and the resource owner identifier is set as a resource owner identifier declaration in the second token statement; and a third device identifier. Wherein, the third device identifier is the identifier of the second device, and the third device identifier is set as the actor statement in the second token statement; or, when the first message is used to request the second token, the second token includes at least one of the following: a second device identifier, wherein the second device identifier is the identifier of the first device, and the second device identifier is set as the publisher statement in the second token statement; a first device identifier, wherein the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement; a third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the second token statement; a first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as the scope statement in the second token statement; a resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier statement in the second token statement.

[0043] In the above embodiments, the content of the second token is clearly defined; for example, if the second token is obtained through token exchange and the authorized actor declared in the second token is the second device, it means that the second device can act as an API caller to call the service information of the third device instead of the fourth device; or if the second token is obtained through token request and the subject declared in the second token is the second device, it means that the second device can act as the owner of the second token to call the service information of the third device.

[0044] In conjunction with some embodiments of the first aspect, in some embodiments, the third token includes at least one of the following: a third device identifier, wherein the third device identifier is an identifier of the second device, and the third device identifier is set as the subject statement in the third token statement.

[0045] In the above embodiments, if the subject of the third token declaration is the second device, it means that the second device is the owner of the third token, which facilitates the subsequent authentication of the third device's identity by the first device.

[0046] In conjunction with some embodiments of the first aspect, in some embodiments, before sending the second response to the second device, one of the following is further included: generating a second token based on the first token; generating a second token based on the first device identifier and the first service identifier included in the first message.

[0047] The above embodiments provide multiple ways to generate tokens, adapting to more application scenarios.

[0048] In conjunction with some embodiments of the first aspect, in some embodiments, generating a second token requires satisfying at least one of the following conditions: the second service identifier in the first token is associated with the first service identifier in the first message; the second device is authorized to access the service information of the third device; the fifth device identifier of the second device is the same as the identifier in the authorized actor declaration in the first token, and the fifth device identifier is the identifier of the authenticated second device; the identifier in the subject declaration in the third token is the same as the identifier in the authorized actor declaration in the first token; the fifth device identifier of the second device is the same as the identifier in the listener declaration in the first token; and the identifier in the listener declaration in the first token is the same as the identifier in the subject declaration in the third token.

[0049] In conjunction with some embodiments of the first aspect, in some embodiments, generating a second token based on a first token includes: determining the first device identifier and the first service identifier based on a third device identifier, a second service identifier, and first information included in the first token, when it is determined that the first message does not include a first device identifier and a first service identifier; wherein the first information is used to indicate the association relationship between at least two of the third device identifier, the second service identifier, the first device identifier, and the first service identifier; and generating a second token based on the first device identifier and the first service identifier.

[0050] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes one of the following: determining that the token exchange failed or that a second token is not generated if it is determined that the second service identifier in the first token is not associated with the first service identifier in the first message, and / or the second device is not authorized to access the service information of the third device; determining that the token exchange failed or that a second token is not generated if it is determined that the fifth device identifier of the second device is different from the identifier in the authorized actor's statement in the first token; determining that the token exchange failed or that a second token is not generated if it is determined that the identifier in the subject declaration in the third token is different from the identifier in the authorized actor's statement in the first token; determining that the token exchange failed or that a second token is not generated if it is determined that the fifth device identifier of the second device is different from the identifier in the listener's statement in the first token; and determining that the identifier in the listener's statement in the first token is different from the identifier in the subject declaration in the third token.

[0051] In conjunction with some embodiments of the first aspect, in some embodiments, the first response includes a second token, and / or the first response includes first indication information for indicating successful token exchange; or, the first response includes second indication information for indicating failed token exchange or failure to successfully generate a second token.

[0052] In conjunction with some embodiments of the first aspect, in some embodiments, before receiving the first message sent by the second device, the method further includes: receiving a second message sent by the second device, wherein the second message is used to request a third token; and sending a second response to the second device, wherein the second response includes the third token.

[0053] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes at least one of the following: obtaining first authorization information of a second device, wherein the first authorization information is used to indicate at least one of the following: API caller identifier and service information; obtaining second authorization information of a third device, wherein the second authorization information is used to indicate at least one of the following: API caller identifier and service information; obtaining third authorization information of a resource owner, wherein the third authorization information is used to indicate at least one of the following: API caller identifier and resource information.

[0054] In the above embodiments, the second device, the third device, and the resource owner can all provide authorization information to the first device, which is beneficial for the first device to subsequently authorize and authenticate these devices.

[0055] In conjunction with some embodiments of the first aspect, in some embodiments, before receiving the first message sent by the second device, the method includes: receiving a third message sent by a fourth device, wherein the third message is used to request a first token; and sending a third response to the fourth device, wherein the third response includes the first token.

[0056] In conjunction with some embodiments of the first aspect, in some embodiments, before sending the third response to the third device, one of the following is further included: generating a first token if it is determined that the fourth device is authorized; generating a first token if it is determined that the fourth device is authorized and the second device needs to obtain information from the third device to create a response for the fourth device.

[0057] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes at least one of the following: determining whether to authorize a fourth device based on first authorization information; determining whether to authorize a fourth device based on the first authorization information and third authorization information; and determining whether to authorize a second device based on second authorization information.

[0058] In conjunction with some embodiments of the first aspect, in some embodiments, generating a first token includes at least: setting a third device identifier of the second device as an authorized actor statement in the first token statement.

[0059] Secondly, embodiments of this disclosure propose an information processing method, executed by a second device, comprising: sending a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and receiving a first response sent by the first device, wherein the first response is determined based on the first message.

[0060] In conjunction with some embodiments of the second aspect, in some embodiments, sending a first message to a first device includes: sending a first message to a first device if the obtained first token includes a resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner and the resource owner identifier is set as the resource owner identifier declaration in the first token declaration.

[0061] In the above embodiments, when a resource owner exists, the second device can send a first message to the first device to obtain a second token, thereby eliminating the need for the second device to re-authenticate with the resource owner's participation, thus reducing resource waste caused by re-authentication.

[0062] In conjunction with some embodiments of the second aspect, in some embodiments, the first message is used to request the first device to send a second token to the second device based on the first token. The first message includes at least one of the following: a first token; a third token, wherein the third token is used to indicate the identity of the second device; a type identifier, wherein the type identifier is used to indicate token exchange; a first device identifier, wherein the first device identifier is the identifier of the third device, and the third device is the device that the fourth device requests access to; a first service identifier, wherein the first service identifier is used to indicate the service information of the third device; or, when the first message is used to request the second token, the first message includes at least one of the following: a first device identifier; a first service identifier.

[0063] In conjunction with some embodiments of the second aspect, in some embodiments, the first token includes at least one of the following: a second device identifier, wherein the second device identifier is an identifier of the first device, and the second device identifier is set as a publisher statement in the first token statement; a third device identifier, wherein the third device identifier is an identifier of the second device, and the third device identifier is set as a listener statement in the first token statement, and the third device identifier is also set as an authorized actor statement in the first token statement; a fourth device identifier, wherein the fourth device identifier is an identifier of the fourth device, and the fourth device identifier is set as a subject statement in the first token statement; a second service identifier, wherein the second service identifier is used to indicate service information of the second device, and the second service identifier is set as a scope statement in the first token statement; and a resource owner identifier, wherein the resource owner identifier is an identifier of the resource owner, and the resource owner identifier is set as a resource owner identifier statement in the first token statement.

[0064] In conjunction with some embodiments of the second aspect, in some embodiments, the first message is used to request the first device to send a second token to the second device based on the first token. The second token includes at least one of the following: a second device identifier, wherein the second device identifier is the identifier of the first device, and the second device identifier is set as a publisher declaration in the second token statement; a first device identifier, wherein the first device identifier is the identifier of a third device, and the first device identifier is set as a listener declaration in the second token statement; a fourth device identifier, wherein the fourth device identifier is the identifier of a fourth device, and the fourth device identifier is set as a subject declaration in the second token statement; a first service identifier, wherein the first service identifier is used to indicate service information of the third device, and the first service identifier is set as a scope declaration in the second token statement; a resource owner identifier, wherein the resource owner identifier is the identifier of a resource owner, and the resource owner identifier is set as a resource owner identifier declaration in the second token statement; and a third device identifier. Wherein, the third device identifier is the identifier of the second device, and the third device identifier is set as the actor statement in the second token statement; or, when the first message is used to request the second token, the second token includes at least one of the following: a second device identifier, wherein the second device identifier is the identifier of the first device, and the second device identifier is set as the publisher statement in the second token statement; a first device identifier, wherein the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement; a third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the second token statement; a first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as the scope statement in the second token statement; a resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier statement in the second token statement.

[0065] In conjunction with some embodiments of the second aspect, in some embodiments, the third token includes at least one of the following: a third device identifier, wherein the third device identifier is an identifier of the second device, and the third device identifier is set as the subject statement in the third token statement.

[0066] In conjunction with some embodiments of the second aspect, in some embodiments, the first response includes a second token, and / or the first response includes first indication information for indicating that the token exchange was successful; or, the first response includes second indication information for indicating that the token exchange failed or that the second token was not successfully generated.

[0067] In conjunction with some embodiments of the second aspect, in some embodiments, the method further includes: receiving a fourth message sent by a fourth device, wherein the fourth message includes a first token; and sending a fifth message to a third device, wherein the fifth message includes a second token, and the fifth message is used to request the invocation of service information of the third device.

[0068] In conjunction with some embodiments of the second aspect, in some embodiments, the method further includes: receiving a fourth response sent by a third device, wherein the fourth response is used to indicate a service information related response of the third device; and sending a fifth response to the third device, wherein the fifth response is determined based on the fourth response.

[0069] In conjunction with some embodiments of the second aspect, in some embodiments, before sending the first message to the first device, the method further includes: sending a second message to the first device, wherein the second message is used to request a third token; and receiving a second response sent by the first device, wherein the second response includes the third token.

[0070] In conjunction with some embodiments of the second aspect, in some embodiments, the method further includes: sending first authorization information of the second device to the first device, wherein the first authorization information is used to indicate at least one of the following: API caller and service information.

[0071] Thirdly, embodiments of this disclosure propose an information processing method executed by a third device, comprising: receiving a fifth message sent by a second device, wherein the fifth message includes a second token of the second device and is used to request the invocation of service information of the third device; and sending a fourth response to the second device, wherein the fourth response is used to indicate a response related to the service information of the third device.

[0072] In conjunction with some embodiments of the third aspect, in some embodiments, before sending the fourth response to the second device, one of the following is further included: if it is determined that the second token includes an actor declaration, determining authorized service information for invoking the third device based on the fact that the identifier of the actor declaration in the second token is the same as the identifier of the fifth device, wherein the identifier of the fifth device is the identifier of the authenticated second device; if it is determined that the second token does not include an actor declaration, determining authorized service information for invoking the third device based on the fact that the identifier of the subject declaration in the second token is the same as the identifier of the fifth device; if it is determined that the second token includes an actor declaration, determining unauthorized service information for invoking the third device based on the fact that the identifier of the actor declaration in the second token is different from the identifier of the fifth device; if it is determined that the second token does not include an actor declaration, determining unauthorized service information for invoking the third device based on the fact that the identifier of the subject declaration in the second token is different from the identifier of the fifth device.

[0073] In conjunction with some embodiments of the third aspect, in some embodiments, the method further includes: sending second authorization information of the third device to the first device, wherein the second authorization information is used to indicate at least one of the following: API caller and service information.

[0074] Fourthly, embodiments of this disclosure propose an information processing method, executed by a fourth device, comprising: sending a third message to a first device, wherein the third message is used to request a first token; receiving a third response sent by the first device, wherein the third response includes the first token; wherein the first token is used by the fourth device to send to a second device, so that the second device sends a first message to the first device; the first message is used to request the first device to send a second token to the second device based on the first token.

[0075] In conjunction with some embodiments of the fourth aspect, in some embodiments, the first token includes at least one of the following: a second device identifier, wherein the second device identifier is an identifier of the first device and is set as a publisher statement in the first token statement; a third device identifier, wherein the third device identifier is an identifier of the second device and is set as a listener statement in the first token statement, and the third device identifier is also set as an authorized actor statement in the first token statement; a fourth device identifier, wherein the fourth device identifier is an identifier of the fourth device and is set as a subject statement in the first token statement; a second service identifier, wherein the second service identifier is used to indicate service information of the second device and is set as a scope statement in the first token statement; and a resource owner identifier, wherein the resource owner identifier is an identifier of the resource owner and is set as a resource owner identifier statement in the first token statement.

[0076] Fifthly, embodiments of this disclosure propose an information processing method, comprising: a second device sending a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; the first device sending a first response to the second device, wherein the response includes the second token.

[0077] In a sixth aspect, embodiments of this disclosure provide a first device, comprising: a first transceiver module configured to: receive a first message sent by a second device; wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and send a first response determined based on the first message to the second device.

[0078] In a seventh aspect, embodiments of this disclosure provide a second device, comprising: a second transceiver module configured to send a first message to a first device, wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request a second token; and to receive a first response sent by the first device, wherein the first response is determined based on the first message.

[0079] Eighthly, embodiments of this disclosure provide a third device, comprising: a third transceiver module configured to receive a fifth message sent by a second device, wherein the fifth message includes a second token of the second device and is used to request the invocation of service information of the third device; and to send a fourth response to the second device, wherein the fourth response is used to indicate a response related to the service information of the third device.

[0080] In a ninth aspect, embodiments of this disclosure provide a fourth device, comprising: a fourth transceiver module configured to send a third message to a first device, wherein the third message is used to request a first token; and to receive a third response sent by the first device, wherein the third response includes the first token; wherein the first token is used by the fourth device to send to a second device, causing the second device to send a first message to the first device; and the first message is used to request the first device to send a second token to the second device based on the first token.

[0081] In a tenth aspect, embodiments of this disclosure provide a communication device including one or more processors; wherein the communication device is used to execute, as in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or optional implementations of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0082] Eleventhly, embodiments of this disclosure provide a communication system, including: a first device, a second device, a third device, and a fourth device; wherein the first device is configured to perform the method described in the optional implementation of the first aspect, the second device is configured to perform the method described in the optional implementation of the second aspect, the third device is configured to perform the method described in the optional implementation of the third aspect, and the fourth device is configured to perform the method described in the optional implementation of the fourth aspect.

[0083] In a twelfth aspect, embodiments of this disclosure provide a storage medium storing instructions that, when executed on a communication device, cause the communication device to perform the method described in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or optional implementations of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0084] In a thirteenth aspect, embodiments of this disclosure provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the methods described in the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, or optional implementations of the first aspect, the second aspect, the third aspect, the fourth aspect, and the fifth aspect.

[0085] In a fourteenth aspect, embodiments of this disclosure provide a computer program that, when run on a computer, causes the computer to perform the information processing method as described in the first aspect, second aspect, third aspect, fourth aspect, fifth aspect, or optional implementations of the first aspect, second aspect, third aspect, fourth aspect, and fifth aspect.

[0086] In a fifteenth aspect, embodiments of this disclosure provide a chip or chip system; the chip or chip system includes processing circuitry configured to perform the methods described according to the first, second, third, fourth, and fifth aspects above, or alternative implementations of the first, second, third, fourth, and fifth aspects.

[0087] It is understood that the aforementioned devices (e.g., the first device, the second device, the third device, the fourth device, etc.), communication systems, storage media, program products, computer programs, chips, or chip systems are all used to execute the methods provided in the embodiments of this disclosure. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0088] This disclosure provides an information processing method, apparatus, communication system, and storage medium. In some embodiments, the terms "information processing method" and "information processing device" are interchangeable, as are "information processing system" and "communication system".

[0089] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0090] In each of the disclosed embodiments, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be used interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0091] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure.

[0092] In this embodiment of the disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular expression or a plural expression.

[0093] In the embodiments disclosed herein, "multiple" refers to two or more.

[0094] In some embodiments, the terms “at least one of”, “one or more”, “a plurality of”, “multiple”, etc., may be used interchangeably.

[0095] In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "in response to one case A, in response to another case B", etc., may include the following technical solutions depending on the situation: in some embodiments, A (execute A regardless of B); in some embodiments, B (execute B regardless of A); in some embodiments, execution is selected from A and B (A and B are selectively executed); in some embodiments, A and B (both A and B are executed). The same applies when there are more branches such as A, B, C, etc.

[0096] In some embodiments, the notation "A or B" may include the following technical solutions, depending on the situation: in some embodiments, A (execution of A regardless of B); in some embodiments, B (execution of B regardless of A); in some embodiments, execution is selected from A and B (A and B are selectively executed). The same applies when there are more branches such as A, B, C, etc.

[0097] The prefixes "first," "second," etc., used in the embodiments of this disclosure are merely for distinguishing different descriptive objects and do not impose restrictions on the position, order, priority, quantity, or content of the descriptive objects. The description of the descriptive objects is found in the claims or the context of the embodiments, and the use of prefixes should not constitute unnecessary restrictions. For example, if the descriptive object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the descriptive object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the number of descriptive objects is not limited by ordinal numbers and can be one or more. For example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device", then "first device" and "second device" can be the same device or different devices, and their types can be the same or different. Similarly, if the object being described is "information", then "first information" and "second information" can be the same information or different information, and their content can be the same or different.

[0098] In some embodiments, “including A,” “containing A,” “for indicating A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0099] In some embodiments, the terms “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “if…”, “if…”, etc., can be used interchangeably.

[0100] In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”.

[0101] In some embodiments, devices, etc., can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as “device”, “equipment”, “circuit”, “network element”, “node”, “function”, “unit”, “section”, “system”, “network”, “chip”, “chip system”, “entity”, and “subject” can be used interchangeably.

[0102] In some embodiments, "network" can be interpreted as devices included in a network (e.g., access network devices, core network devices, etc.).

[0103] In some embodiments, the terms "access network device (AN device)," "radio access network device (RAN device)," "base station (BS)," "radio base station," "fixed station," "node," "access point," "transmission point (TP)," "reception point (RP)," "transmission / reception point (TRP)," "panel," "antenna panel," "antenna array," "cell," "macro cell," "small cell," "femto cell," "pico cell," "sector," "cell group," "carrier," "component carrier," and "bandwidth part (BWP)" can be used interchangeably.

[0104] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", "subscriber station", "mobile unit", "subscriber unit", "wireless unit", "remote unit", "mobile device", "wireless device", "wireless communication device", "remote device", "mobile subscriber station", "access terminal", "mobile terminal", "wireless terminal", "remote terminal", "handset", "user agent", "mobile client", and "client" can be used interchangeably.

[0105] In some embodiments, access network devices, core network devices, or network devices can be replaced by terminals. For example, embodiments of this disclosure can also be applied to structures that replace communication between access network devices, core network devices, or network devices and terminals with communication between multiple terminals (e.g., also referred to as device-to-device (D2D), vehicle-to-everything (V2X), etc.). In this case, the structure can also be configured such that the terminal has all or part of the functions of the access network device. Furthermore, terms such as "uplink" and "downlink" can be replaced with terms corresponding to communication between terminals (e.g., "sidelink"). For example, uplink channel, downlink channel, etc., can be replaced with sidelink channel, uplink link, downlink link, etc., can be replaced with sidelink link.

[0106] In some embodiments, the terminal may be replaced by an access network device, a core network device, or a network device. In this case, the access network device, core network device, or network device may also be configured to have all or some of the functions of the terminal.

[0107] In some embodiments, the acquisition of data, information, etc., may comply with the laws and regulations of the country where the location is situated.

[0108] In some embodiments, data, information, etc., may be obtained with the user's consent.

[0109] Furthermore, each element, each row, or each column in the table of this disclosure can be implemented as an independent embodiment, and any combination of any element, any row, or any column can also be implemented as an independent embodiment.

[0110] Figure 1A is a schematic diagram of the structure of an information processing system 100 according to an embodiment of the present disclosure. As shown in Figure 1A, the information processing system 100 may include: a terminal 101 and a network device 102.

[0111] In some embodiments, network device 102 may include at least one of an access network device and a core network device.

[0112] In some embodiments, terminal 101 includes, for example, at least one of the following: mobile phone, wearable device, Internet of Things (IoT) device or terminal, car with communication function, smart car, tablet computer, computer with wireless transceiver function, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal device in industrial control, wireless terminal device in self-driving, wireless terminal device in remote medical surgery, wireless terminal device in smart grid, wireless terminal device in transportation safety, wireless terminal device in smart city, and wireless terminal device in smart home, but is not limited thereto.

[0113] In some embodiments, the access network device is, for example, a node or device that connects a terminal to a wireless network. The access network device may include, but is not limited to, at least one of the following in a 5G communication system: evolved Node B (eNB), next-generation eNB (ng-eNB), next-generation Node B (gNB), node B (NB), home node B (HNB), home evolved node B (HeNB), radio backhaul device, radio network controller (RNC), base station controller (BSC), base transceiver station (BTS), base band unit (BBU), mobile switching center, base station in a 6G communication system, open RAN, cloud RAN, base station in other communication systems, and access node in a wireless fidelity (WiFi) system.

[0114] In some embodiments, the technical solutions of this disclosure can be applied to the Open RAN architecture. In this case, the interfaces between or within access network devices involved in the embodiments of this disclosure can be transformed into internal interfaces of Open RAN. The processes and information interactions between these internal interfaces can be implemented by software or programs.

[0115] In some embodiments, the access network device may be composed of a central unit (CU) and a distributed unit (DU). The CU may also be called a control unit. The CU-DU structure can separate the protocol layer of the access network device. Some of the protocol layer functions are centrally controlled by the CU, while the remaining part or all of the protocol layer functions are distributed in the DU and centrally controlled by the CU. However, this is not the only possibility.

[0116] In some embodiments, the core network equipment may be a single device, including a first device, a second device, a third device, and / or a fourth device, or it may be multiple devices or a group of devices, each including all or part of the aforementioned first device, second device, third device, and fourth device. The first device, second device, third device, and / or fourth device may be virtual or physical. The core network includes, for example, at least one of the following: Evolved Packet Core (EPC), 5G Core Network (5GCN), Next Generation Core (NGC), and 6G Core Network (6GCN).

[0117] In some embodiments, the name of the first device is not limited, and it may be any network element, function or entity of the core network under the CAPIF system, or any network element, function or entity of the core network used for functions such as authorization.

[0118] In some embodiments, the first device may be a Universal Application Programming Interface Framework core function (CAPIF core function, CCF) or a licensing function, etc.

[0119] In some embodiments, the names of the second and third devices are not limited, and they may be, for example, any network element, function, or entity used for open network functions.

[0120] In some embodiments, both the second device and the third device can be API Exposing Functions (AEFs); wherein the second device can be a first AEF or AEF-1, and the third device can be a second AEF or AEF-2.

[0121] In some embodiments, the fourth device may be an API invoker; the name of the fourth device is not limited thereto.

[0122] In some embodiments, the API caller may be a terminal or a user interface (UE), or an application (e.g., a browser) or a public account or mini-program running on the terminal or UE, or an application function, or an application server, or a server belonging to a third party (e.g., Company A, operator B, or platform C).

[0123] In some embodiments, the resource owner can be a user or a subscriber of the UE. The device, function, or entity used by the resource owner can be a resource owner function.

[0124] In some embodiments, the name of the resource owner function is not limited; the resource owner function may be a device, network element, function, entity, or application function (AF) used by the resource owner.

[0125] In some embodiments, the resource owner function is responsible for interacting with the resource owner; the resource owner function can be a user, a subscriber, a humane, a user appliance, a personal computer, etc.

[0126] It is understood that the information processing system described in the embodiments of this disclosure is for the purpose of more clearly illustrating the technical solutions of the embodiments of this disclosure, and does not constitute a limitation on the technical solutions provided in the embodiments of this disclosure. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this disclosure are also applicable to similar technical problems.

[0127] The following embodiments of this disclosure can be applied to the information processing system 100 shown in FIG1A, or some of its components, but are not limited thereto. The components shown in FIG1A are illustrative. The information processing system may include all or some of the components in FIG1A, or may include other components outside of FIG1A. The number and form of each component are arbitrary. The connection relationship between the components is illustrative. The components may be unconnected or connected. The connection can be in any way, either direct or indirect, wired or wireless.

[0128] The embodiments disclosed herein can be applied to Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 6th generation mobile communication system (6G), 5G New Radio (NR), Future Radio Access (FRA), New-Radio Access Technology (RAT), New Radio (NR), New Radio access (NX), Future generation radio access (FX), Global System for Mobile communications (GSM), CDMA2000, Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20, Ultra-Wideband (UWB), Bluetooth (a registered trademark), Public Land Mobile Network (PLMN) networks, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) systems, Internet of Things (IoT) systems, Vehicle-to-Everything (V2X) systems, systems utilizing other communication methods, and next-generation systems built upon them, etc. Furthermore, multiple systems can be combined (e.g., LTE or LTE-A combined with 5G, 5G combined with 5G, 5G combined with 6G, etc.) for application.

[0129] In some embodiments, a nested API call scenario can be: an API call by a first AEF requires the first AEF to request an API call by a second AEF, and the second AEF and the first AEF are in the same API provider domain. This scenario addresses situations where a service API may require services from other service APIs. For example, if an API invoker calls a location information retrieval API (e.g., SEAL SS_LocationInfoRetrieval), the location management server (acting as an AEF on the API invoker side and also as an API invoker on the NEF side) can invoke the NEF API to retrieve UE location information from the core network. Exemplarily, as shown in Figure 1B, in this scenario, CAPIF can reduce authorization information queries for nested API calls; the information processing method shown in Figure 1B includes the following steps:

[0130] Step S1101: The API caller requests authorization information.

[0131] Optionally, the authorization information may include a token that can be used to access the service API opened by the first AEF; the token may be generated with the participation of the resource owner.

[0132] Step S1102: The API caller sends a service API call request with authorization information.

[0133] In step S1103, the first AEF decides to call the service API exposed by the second AEF.

[0134] In step S1104, the first AEF uses the authorization information sent by the API caller to obtain authorization information for accessing the service API of the second AEF.

[0135] Optionally, to avoid wasting the API caller's authorization information (e.g., triggering the resource owner's re-authorization in step S1104), the authorization information of the service API of the second AEF can be obtained in step S1104 using the authorization information sent by the API caller through the first AEF.

[0136] To obtain authorization information, if the first AEF exchanges the authorization information provided in the API caller's request (e.g., step S1102) with the authorization information used to access the service API of the second AEF, then no further interaction with the API caller is required.

[0137] Step S1105: The first AEF sends a service API call request with authorization information to the second AEF.

[0138] Step S1106: The second AEF sends a service API call response to the first AEF.

[0139] Step S1107: The first AEF sends a service API call response to the API caller.

[0140] However, there is currently no mechanism that allows the first AEF to securely obtain authorization information to access the second AEF by providing the CCF with the authorization information of the API caller.

[0141] In some embodiments, the UE can be a terminal, or the terminal can be a UE.

[0142] Figure 2A is an interactive schematic diagram illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 2A, this embodiment of the present disclosure relates to an information processing method used in an information processing system 100, the method comprising:

[0143] In step S2101, the second and third devices send authorization information to the first device.

[0144] In some embodiments, the second device sends the first authorization information of the second device to the first device.

[0145] In some embodiments, the first device receives first authorization information from the second device sent by the second device.

[0146] In some embodiments, the third device sends the third device's second authorization information to the first device.

[0147] In some embodiments, the first device receives second authorization information from the third device.

[0148] In some alternative embodiments, the resource owner sends a third authorization message to the first device.

[0149] In some alternative embodiments, the resource owner function sends third authorization information of the resource owner to the first device.

[0150] In some alternative embodiments, the resource owner sends a third authorization message to the first device via a resource owner function.

[0151] In some alternative embodiments, the first device receives third authorization information from the resource owner.

[0152] In some optional embodiments, the first device receives third authorization information from the resource owner function. In some optional embodiments, the first device may receive at least one of the following through other network functions in the core network: first authorization information from the second device, second authorization information from the third device, and third authorization information from the resource owner.

[0153] Optionally, the first device can be the same as the first device in the previous embodiments; for example, the first device can be a CCF or an authorization function. The second device can be the same as the second device in the previous embodiments; for example, the second device can be a first AEF. The third device can be the same as the second device in the previous embodiments; for example, the third device can be a second AEF. The resource owner can be the same as the resource owner in the previous embodiments; for example, the resource owner can be a user of the terminal or a subscriber.

[0154] Optionally, the first authorization information, the second authorization information, and the third authorization information may each include or be used to indicate at least one of the following: API caller ID and service information.

[0155] For example, the first authorization information is used to indicate the API caller information of the authorized access to the services of the second device.

[0156] For example, the first authorization information is used to indicate the API caller authorized to access the service API of the second device.

[0157] For example, the first authorization information may include at least one of the following: a first API caller ID and first service information; the first caller ID is used to indicate the API caller authorized to access the second device; the first service information is used to indicate the service information of the second device authorized to access. For example, the first caller ID may also be used to indicate the API caller authorized to access the service information of the second device. Here, the service information of the second device may refer to a service or service API that the second device has, provides, or makes public.

[0158] For example, the first authorization information may include at least one of the following: a first API caller ID and first service information; the first service information indicates a specific service API of the second device, such as an API related to location information; the first API caller ID and the first service information may be used to indicate that the first API caller may invoke the service or service API of the second device indicated by the first service information.

[0159] For example, the second authorization information is used to indicate the API caller information of the authorized access to the services of the third device.

[0160] For example, the second authorization information may include at least one of the following: a second API caller ID and second service information; the second caller ID is used to indicate the API caller authorized to access the third device; the first service information is used to indicate the service information of the authorized third device. For example, the second caller ID may also be used to indicate the API caller authorized to access the service information of the third device. Here, the service information of the third device may refer to a service or service API that the third device has, provides, or makes public.

[0161] For example, the second authorization information may include at least one of the following: a second API caller ID and second service information; the second service information indicates a specific service API of the third device, such as an API related to location information; the second API caller ID and the second service information may be used to indicate that the second API caller may invoke the service or service API of the third device indicated by the second service information.

[0162] For example, the second API caller ID is the ID of the second device.

[0163] For example, third authorization information is used to indicate API caller information for those authorized to access the resource owner's resources.

[0164] For example, the third authorization information may include at least one of the following: a third API caller ID and resource information; the third caller ID indicates the API caller authorized to access the resource owner's resource; the resource indicates the resource owner's resource that is authorized to be accessed. For example, a second caller ID may also be used to indicate the API caller authorized to access the resource owner's resource. Here, the resource owner's resource may refer to a resource owned by the resource owner or a resource owner's resource stored on the network.

[0165] For example, the resource owner's resource can be the resource owner's location or QoS.

[0166] For example, the third API caller ID can be the ID of the second device or the ID of the fourth device.

[0167] Optionally, service information can be used to indicate services that require authorization.

[0168] Optionally, service information may include at least one of the following: service API, service operations, and resources.

[0169] For example, service operations can be, but are not limited to, deleting or adding users to the user management service.

[0170] For example, the resource may be, but is not limited to, the address information of the second device (e.g., a URL).

[0171] Optionally, the API caller ID is used to indicate the API caller.

[0172] Optionally, the API caller ID can be any string or number, as long as it can uniquely identify the API caller; the string can be, but is not limited to, at least one letter, number, and / or symbol. The name of the API caller ID is not limited.

[0173] Optionally, the names of the first authorization information, the second authorization information, and the third authorization information are not limited, and they may be, for example, the first service authorization information, the second service authorization information, the third service authorization information, the first network function profile, the second network function profile, the third network function profile, etc.; or the first authorization information, the second authorization information, and the third authorization information may all be service API authorization information or service API call authorization information, etc.

[0174] In step S2102, the fourth device sends a third message to the first device.

[0175] In some embodiments, the first device receives a third message sent by the fourth device.

[0176] Optionally, the fourth device can be the fourth device in the previous embodiments; for example, the fourth device can be an API caller.

[0177] In some embodiments, the third message is used to request the first token.

[0178] In some embodiments, the third message is used to request the first token to invoke the service information of the first AEF.

[0179] In some embodiments, the name of the third message is not limited, and it may be, for example, a token request, a token request message, or a first token request message.

[0180] In some embodiments, the first token includes at least one of the following: a second device identifier, a third device identifier, a fourth device identifier, a second service identifier, and a resource owner identifier.

[0181] Optionally, the second device identifier is the identifier of the first device; the second device identifier is set to the issuer statement in the first token statement.

[0182] Optionally, the third device identifier is the identifier of the second device; the third device identifier is set to the listener declaration in the first token declaration, and the third device identifier is also set to the authorized actor (may_act) declaration in the first token declaration. Here, the authorized actor declaration is used to indicate the actor, which is the actor authorized to delegate the API caller in the subject (sub) declaration. Optionally, the first device can determine whether the second device is authorized to delegate the API caller in the subject (sub) declaration based on the authorized actor (may_act) declaration. Optionally, the first token declaration is the declaration of the first token; the second token declaration is the declaration of the second token; and the third token declaration is the declaration of the third token.

[0183] Optionally, the first device can determine whether the second device is entitled to request token exchange for a token containing the authorized actor statement based on the authorized actor statement.

[0184] Optionally, the first device can determine whether to perform a token exchange or generate a second token based on the authorized actor (may_act) declaration.

[0185] Optionally, the fourth device identifier is the identifier of the fourth device; the fourth device identifier is set as the subject statement in the first token statement.

[0186] Optionally, the second service identifier is used to indicate the service information of the second device, and the second service identifier is set to the scope declaration in the first token declaration.

[0187] Optionally, the resource owner identifier is the identifier of the resource owner; the resource owner identifier is set to the resource owner identifier statement in the first token statement.

[0188] Optionally, the contents of the first token may be as shown in Table 1.

[0189] Table 1

[0190] Here, the CCF identifier is set as the publisher declaration; the first AEF identifier is set as the listener declaration; the API caller identifier is set as the subject declaration; the resource owner identifier is set as the resource owner identifier declaration; and the service API of the first AEF is set as the scope declaration. Optionally, the CCF identifier can be a second device identifier; the first AEF identifier can be a third device identifier; the API caller identifier can be a fourth device identifier; the service API of the first AEF can be service information indicated by the second service identifier (e.g., a service API); and the resource owner identifier can be a resource owner identifier.

[0191] Optionally, the second device identifier, the third device identifier, the fourth device identifier, the resource owner identifier, and the first device identifier and the fifth device identifier involved in the following embodiments of this disclosure can all be device identifiers, and they can all be any string or number, as long as the first device identifier, the second device identifier, the third device identifier, the fourth device identifier, the resource owner identifier, and the fifth device identifier can uniquely identify the third device, the first device, the second device, the fourth device, the resource owner, and the authenticated second device, respectively.

[0192] Optionally, both the first service identifier and the second service identifier can refer to the identifier of service information or service API; both the first service identifier and the second service identifier can be any string or number, as long as the first service identifier and the second service identifier respectively identify at least one service information (e.g., at least one service API) of the third device and at least one service information (e.g., at least one service API) of the second device.

[0193] In some alternative embodiments, the first device determines the first token. Optionally, the first device generates the first token.

[0194] In some alternative embodiments, the first device generates a first token upon determining that the fourth device is authorized.

[0195] In some alternative embodiments, the first device generates a first token upon determining that the fourth device is authorized and that the second device needs to obtain information from the third device to create a response for the third device. Here, the second device needing to obtain information from the third device to create a response for the third device may mean that the response of the second device's service API depends on the response of the third device's service API.

[0196] Optionally, the first device determines whether to authorize the fourth device based on the first authorization information.

[0197] Optionally, the first device determines whether to authorize the fourth device based on the first authorization information and the third authorization information.

[0198] For example, if the first device determines that the fourth device identifier of the fourth device is the same as one of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, it determines to authorize the fourth device. Alternatively, if the first device determines that the fourth device identifier of the fourth device is not the same as any of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, it determines not to authorize the fourth device.

[0199] For example, based on the above embodiments, if the first device determines that the service information that the fourth device needs to access is the same as at least one of the service information indicated in the first authorization information (e.g., the first service information), it determines to authorize the fourth device. Alternatively, if the first device determines that the service information that the fourth device needs to access is not the same as any one of the service information indicated in the first authorization information (e.g., the first service information), it determines not to authorize the fourth device.

[0200] For example, if the first device determines that the fourth device identifier of the fourth device is the same as one of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, and if the first device determines that the service information that the fourth device needs to access is the same as at least one of the service information (e.g., the first service information) indicated in the first authorization information, the first device determines to authorize the fourth device.

[0201] For example, if the first device determines that the fourth device identifier of the fourth device is the same as one of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, and determines that the fourth device identifier is the same as one of the API callers (e.g., the third caller ID) indicated in the third authorization information, the first device determines to authorize the fourth device. Alternatively, if the first device determines that the fourth device identifier of the fourth device is not the same as any of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, and / or determines that the fourth device identifier is not the same as any of the API callers (e.g., the third caller ID) indicated in the third authorization information, the first device determines not to authorize the fourth device.

[0202] For example, based on the above embodiments, if it is determined that the service information that the fourth device needs to access is at least the same as at least one of the service information (e.g., the first service information) indicated in the first authorization information, and the resource that the fourth device needs to access is at least one of the resources indicated in the third authorization information, then the fourth device is authorized. Alternatively, if the first device determines that the service information that the fourth device needs to access is not the same as any one of the service information (e.g., the first service information) indicated in the first authorization information, and / or that the resource that the fourth device needs to access is not the same as any one of the resources indicated in the third authorization information, then the fourth device is not authorized.

[0203] For example, if the first device determines that the fourth device identifier of the fourth device is the same as one of the API caller IDs (e.g., the first caller ID) indicated in the first authorization information, and determines that the fourth device identifier is the same as one of the API callers (e.g., the third caller ID) indicated in the third authorization information, and simultaneously determines that the service information that the fourth device needs to access is at least one of the service information (e.g., the first service information) indicated in the first authorization information, and the resources that the fourth device needs to access are at least one of the resources indicated in the third authorization information, then the first device determines to authorize the fourth device.

[0204] In some alternative embodiments, generating the first token includes at least: using or setting the third device identifier of the second device as an authorized actor statement in the first token statement. For example, as shown in Table 1 above, the third device identifier of the second device (e.g., AEF-1identity) is used as the may_act statement.

[0205] In some alternative embodiments, the first device determines, based on the characteristic that the second device needs to generate a response from the fourth device by requesting the services of the third device, that the third device identifier of the second device needs to be used as or set as the authorized actor statement in the first token statement.

[0206] In some alternative embodiments, generating the first token may further include at least one of the following: using a second device identifier as or set as a publisher statement in the first token statement; using a third device identifier as or set as an authorized actor statement in the first token statement; using a fourth device identifier as or set as a subject statement in the first token statement; using a second service identifier as or set as a scope statement in the first token statement; using a resource owner identifier as or set as a resource owner identifier statement in the first token statement.

[0207] In some alternative embodiments, the first device determines whether to authorize the second device based on the second authorization information.

[0208] For example, if the first device determines that the third device identifier of the second device is the same as one of the API caller IDs (e.g., the second caller ID) indicated in the second authorization information, it determines to authorize the second device. Alternatively, if the first device determines that the third device identifier of the second device is not the same as any of the API caller IDs (e.g., the second caller ID) indicated in the second authorization information, it determines not to authorize the second device.

[0209] For example, based on the above embodiments, if the first device determines that the service information that the second device needs to access is the same as at least one of the service information (e.g., the second service information) indicated in the second authorization information, it determines to authorize the second device. Alternatively, if the first device determines that the service information that the second device needs to access is not the same as any one of the service information (e.g., the second service information) indicated in the second authorization information, it determines not to authorize the fourth device.

[0210] For example, if the first device determines that the third device identifier of the second device is the same as one of the API caller IDs (e.g., the second caller ID) indicated in the second authorization information, and if the first device determines that the service information that the second device needs to access is the same as at least one of the service information (e.g., the second service information) indicated in the second authorization information, then the first device determines to authorize the second device.

[0211] In step S2103, the first device sends a third response to the fourth device.

[0212] In some embodiments, the fourth device receives a third response sent by the first device.

[0213] In some embodiments, the third response is used to indicate a response to the request for the first token. Optionally, the third response is determined based on a third message.

[0214] For example, a third response may be used to indicate that the first token has been successfully obtained, and in this case, the third response may include the first token; or, for example, a third response may be used to indicate that the first token has been successfully obtained.

[0215] For example, the third response includes a third indication message or a fourth indication message; wherein the third indication message is used to indicate that the first token was successfully obtained; and the fourth indication message is used to indicate that the first token was not successfully obtained.

[0216] For example, the third and fourth indication information can each be one or more bits, fields, or information units.

[0217] Optionally, the third response may include the first token. In this case, the third response is used to indicate that the first token was successfully obtained.

[0218] For example, if the first device determines that it is authorized to authorize the fourth device, it sends a third response to the fourth device including the first token.

[0219] For example, if the first device determines that it authorizes the fourth device and the second device (e.g., authorizes the second device to act as the API caller in place of the fourth device), it sends a third response including the first token to the fourth device.

[0220] In some embodiments, the name of the third response is not limited, and it may be, for example, a token response, a token response message, or a first token response message.

[0221] Step S2104: The second device sends a second message to the first device.

[0222] In some embodiments, the first device receives a second message sent by the second device.

[0223] In some embodiments, the second message is used to request a third token. Optionally, the third token can be used to prove the identity of the second device to the first device.

[0224] In some embodiments, the second message is used to request a third token. Optionally, the third token can be used to indicate the identity of the second device or the identifier of the second device to the first device.

[0225] In some embodiments, the name of the second message is not limited, and it may be, for example, an actor token request, an actor token request message, or a third token request message.

[0226] In some embodiments, the third token includes at least one of the following: a second device identifier and a third device identifier.

[0227] Optionally, the second device identifier is the identifier of the first device; the second device identifier is set to the issuer statement in the third token statement.

[0228] Optionally, the second device identifier is also set as the listener statement in the third token statement.

[0229] Optionally, the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the third token statement.

[0230] Optionally, the contents of the third token may be as shown in Table 2.

[0231] Table 2

[0232] Here, the CCF identifier is set as the publisher's statement, and the CCF identifier is set as the audience's statement; the first AEF identifier is set as the subject's statement. If other network functions request an actor token from the first device, the subject's statement of that actor token is the identifier of the other network function.

[0233] Optionally, the third token is the actor token of the second device.

[0234] In some alternative embodiments, the first device determines the third token. Alternatively, the first device generates the third token.

[0235] Optionally, generating a third token includes at least one of the following: a publisher statement that uses the second device identifier as or sets it as the third token; a listener statement that uses the second device identifier as or sets it as the third token; or a subject statement that uses the third device identifier as or sets it as the third token.

[0236] In step S2105, the first device sends a second response to the second device.

[0237] In some embodiments, the second device sends a second response to the first device.

[0238] In some embodiments, the second response is used to indicate a response requesting a third token. Optionally, the second response is determined based on the second message.

[0239] For example, the second response is used to indicate that the third token has been successfully obtained, and in this case, the second response may include the third token; or, for instance, the second response is used to indicate that the third token has been successfully obtained.

[0240] For example, the second response includes a fifth indication message or a sixth indication message; wherein the fifth indication message is used to indicate that the third token was successfully obtained; and the sixth indication message is used to indicate that the third token was not successfully obtained.

[0241] For example, the fifth and sixth indication information can each be one or more bits, fields, or information units.

[0242] Optionally, the second response may include a third token. In this case, the second response indicates that the third token has been successfully obtained. In some application scenarios, the second device can obtain the third token simply by sending a request to the first device for the third token.

[0243] In some embodiments, the name of the second response is not limited, and it may be, for example, an actor token response, an actor token response message, or a third token response message.

[0244] In some optional embodiments, steps S2104 and S2105 are implementations of the second device requesting an actor token (e.g., a third token) from the first device. Implementations of other network functions requesting their own actor tokens from the first device are similar to those in steps S2104 and S2105. Related embodiments of other network functions requesting their own actor tokens from the first device can be found in the related embodiments of steps S2104 and S2105. For example, the implementation of a third device obtaining its own actor token (e.g., a fourth token) from the second device is similar to those in steps S2104 and S2105. Exemplarily, the third device identifier is set as the subject declaration in the third token, and the first device identifier is set as the subject declaration in the fourth token.

[0245] Step S2106: The fourth device sends a fourth message to the second device.

[0246] In some embodiments, the second device receives a fourth message sent by the fourth device.

[0247] In some embodiments, the fourth message includes the first token.

[0248] In some embodiments, the fourth message is used to request service information from the second device.

[0249] In some embodiments, the name of the fourth message is not limited, and it may be, for example, a service information call request, a service API call request, or a service API call request message.

[0250] Step S2107: The second device sends a first message to the first device.

[0251] In some embodiments, the first device receives a first message sent by the second device.

[0252] In some embodiments, the first message is used to request the first device to send a second token to the second device based on the first token.

[0253] Optionally, the first message is used to request to obtain or determine a second token based on the first token.

[0254] Optionally, the first message is used to request the acquisition or determination of the second token based on the first token, so that the second device sends the second token to the third device.

[0255] Optionally, the first message is used to request the exchange of the first token for the second token. Here, the first message is a token exchange request.

[0256] Optionally, the first message is used to request the second token. Here, the first message is a token request.

[0257] Optionally, the first message is used to request the first device to send a second token to the second device based on the first token. The first message includes at least one of the following: the first token, the third token, the type identifier, the first device identifier, and the first service identifier.

[0258] Optionally, when the first message is used to request the second token, the first message includes at least one of the following: a first device identifier; a first service identifier.

[0259] For example, the third token is used to indicate the identity of the second device; the type identifier is used to indicate token exchange; the first device identifier is the identifier of the third device, which is the device that the fourth device requests access to; and the first service identifier is used to indicate the service information of the third device.

[0260] For example, the first device identifier in the first message can be transmitted through the IE via "audience"; the first service identifier in the first message can be transmitted through the IE via "scope" or through the IE via "resource".

[0261] For example, the first device identifier in the first message is passed through the "audience" parameter; the first service identifier in the first message is passed through the "scope" parameter or the "resource" parameter.

[0262] In some embodiments, the name of the first message is not limited, and it may be, for example, a token exchange request, a token exchange request message, a token request, or a token request message.

[0263] In some embodiments, the first token is a token of the fourth device (i.e., the identifier of the fourth device is set as the subject of the first token or the fourth device is the owner of the token); the second token is a token of the second device (i.e., the identifier of the second device is set as the subject of the second token or the fourth device is the owner of the token, or the identifier of the second device is set as the authorized actor of the second token).

[0264] In some embodiments, the first token is sent by the fourth device to the second device, so that the second device sends a first message to the first device; the first message is used to request the first device to send a second token to the second device based on the first token.

[0265] In some embodiments, the first token is the first token in the previous embodiments.

[0266] In some embodiments, the second token is determined based on the first token, or the second token is generated by the first device.

[0267] In some embodiments, the first message is used to request the first device to send a second token to the second device based on the first token. The second token includes at least one of the following: a second device identifier, a first device identifier, a fourth device identifier, a first service identifier, and a resource owner identifier. Here, the second token may include an actor declaration, and the subject of the second token is the fourth device.

[0268] Optionally, the second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement.

[0269] Optionally, the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement.

[0270] Optionally, the fourth device identifier is the identifier of the fourth device, which is set as the subject statement in the second token statement.

[0271] Optionally, the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as the scope declaration in the second token statement.

[0272] Optionally, the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set to the resource owner identifier statement in the second token statement.

[0273] Optionally, the third device identifier is the identifier of the second device, and the third device identifier is set as the actor statement in the second token statement.

[0274] Optionally, the contents of the second token may be as shown in Table 3 below.

[0275] Table 3

[0276] Here, the CCF identifier is set as the publisher declaration; the second AEF identifier is set as the listener declaration; the API caller identifier is set as the subject declaration; the resource owner identifier is set as the resource owner identifier declaration; the service API of the second AEF is set as the scope declaration; and the first AEF identifier is set as the actor declaration. Optionally, the CCF identifier can be a second device identifier; the first AEF identifier can be a third device identifier; the second AEF identifier can be a first device identifier; the API caller identifier can be a fourth device identifier; the service API of the second AEF can be service information (e.g., a service API) indicated by the first service identifier; and the resource owner identifier can be a resource owner identifier.

[0277] In some embodiments, when the first message is used to request the second token, the second token includes at least one of the following: a second device identifier, a first device identifier, a third device identifier, a first service identifier, and a resource owner identifier. Here, the second token may not include an actor declaration, and the subject of the second token is the second device.

[0278] Optionally, the second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement.

[0279] Optionally, the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement.

[0280] Optionally, the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the second token statement.

[0281] Optionally, the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as the scope declaration in the second token statement.

[0282] Optionally, the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set to the resource owner identifier statement in the second token statement.

[0283] Optionally, the contents of the second token may be as shown in Table 4 below.

[0284] Table 4

[0285] Here, the CCF identifier is set as the publisher declaration; the second AEF identifier is set as the audience declaration; the first AEF identifier is set as the subject declaration; the resource owner identifier is set as the resource owner identifier declaration; and the service API of the second AEF is set as the scope declaration.

[0286] In some embodiments, if the second device receives a first token that includes a resource owner identifier, it sends a first message to the first device, wherein the resource owner identifier is the identifier of the resource owner and is set to the resource owner identifier declaration in the first token declaration. This eliminates the need for the resource owner to repeatedly participate in the authorization process, reducing resource waste.

[0287] In some alternative embodiments, the first device determines whether to generate a second token. Optionally, the first device determines to generate a second token, or the first device determines not to generate a second token.

[0288] In some optional embodiments, generating a second token requires satisfying at least one of the following conditions: the second service identifier in the first token is associated with the first service identifier in the first message; the second device is authorized to access the service information of the third device; the fifth device identifier of the second device is the same as the identifier in the authorized actor declaration in the first token, and the fifth device identifier is the identifier of the authenticated second device; the identifier in the subject declaration in the third token is the same as the identifier in the authorized actor declaration in the first token; the fifth device identifier of the second device is the same as the identifier in the listener declaration in the first token; the identifier in the listener declaration in the first token is the same as the identifier in the subject declaration in the third token. That is, if the second device determines that at least one of the above conditions is satisfied, the second device generates a second token; or, if it determines that all of the above conditions are not satisfied, the second device does not generate a second token.

[0289] For example, if the first device determines that the token exchange is successful or determines that a second token is generated when it determines that the second service identifier in the first token is associated with the first service identifier in the first message, and / or the second device is authorized to access the service information of the third device.

[0290] For example, if the first device determines that the token exchange was successful or the second token was generated if it finds that the fifth device identifier of the second device is the same as the identifier of the authorized actor in the first token.

[0291] For example, if the first device determines that the token exchange was successful or that a second token was generated if it finds that the identifier of the subject declaration in the third token is the same as the identifier of the authorized actor declaration in the first token.

[0292] For example, if the first device determines that the token exchange was successful or determines that a second token has been generated if it finds that the fifth device identifier of the second device is the same as the identifier in the listener's statement in the first token.

[0293] For example, if it is determined that the identifier in the listener's statement in the first token is the same as the identifier in the subject's statement in the third token, it is determined that the token exchange was successful or that a second token was generated.

[0294] For example, if the first device determines that the token exchange failed or that a second token is not generated if it determines that the second service identifier in the first token is not associated with the first service identifier in the first message, and / or the second device is not authorized to access the service information of the third device.

[0295] For example, if the first device determines that the token exchange has failed or that a second token will not be generated if it determines that the fifth device identifier of the second device is different from the identifier of the authorized actor in the first token.

[0296] For example, if the first device determines that the token exchange has failed or that a second token will not be generated if it determines that the identifier of the subject declaration in the third token is different from the identifier of the authorized actor declaration in the first token.

[0297] For example, if the first device determines that the token exchange has failed or the second token is not generated if it determines that the fifth device identifier of the second device is different from the identifier in the listener's statement in the first token.

[0298] For example, if it is determined that the identifier in the listener's statement in the first token is different from the identifier in the subject's statement in the third token, it is determined that the token exchange failed or that a second token was not generated.

[0299] Optionally, the association between the second service identifier and the first service identifier can mean that the service information (e.g., service API) of the second device indicated by the second service identifier depends on the response of the service information (e.g., service API) of the third device indicated by the first service identifier. That is, the response of the service information (e.g., service API) of the second device needs to be generated based on the response of the service information (e.g., service API) of the third device.

[0300] Optionally, the association between the second service identifier and the first service identifier can refer to any other association or mapping relationship, as long as the information obtained or stored by the second device can indicate that the second service identifier and the first service identifier are associated.

[0301] Optionally, the authorization for the second device to access the service information of the third device can be determined based on the second authorization information.

[0302] Optionally, the authorization information for the second device to access the service information of the third device can be determined based on both the second authorization information and the third information.

[0303] Optionally, if the identifier in the subject declaration of the third token is the identifier of the third device, it proves the identity of the second device. If the identifier in the subject declaration of the third token is the same as the identifier in the authorized actor declaration of the first token, it means that the authenticated second device can act as the actor of the token. That is, the identifier of the second device can be set to the actor declaration in the token declaration. In this case, the second device can represent the fourth device to call the service information of the third device. In this way, a second token can be generated.

[0304] In some alternative embodiments, the first device determines or generates the second token.

[0305] In some alternative embodiments, the first device generates a second token based on the first token.

[0306] In some alternative embodiments, the first device generates a second token based on the first device identifier and the first service identifier included in the first message.

[0307] Optionally, the first message may include a first token and include a first device identifier and a first service identifier; or, the first message may not include a first token and include a first device identifier and a first service identifier.

[0308] Optionally, the first device may generate a second token based on the first device identifier and the first service identifier included in the first message.

[0309] Optionally, if the first device determines that the first message does not include the first device identifier and the first service identifier, it determines the first device identifier and the first service identifier based on the third device identifier, the second service identifier, and the first information included in the first token; wherein, the first information is used to indicate the association relationship between at least two of the third device identifier, the second service identifier, the first device identifier, and the first service identifier; and a second token is generated based on the first device identifier and the first service identifier.

[0310] Optionally, if the first message includes a first device identifier and a first service identifier, the second token can also be determined based on the first token.

[0311] For example, the first information is used to indicate the association between at least one of the third device identifier and the second service identifier and at least one of the first device identifier and the first service identifier.

[0312] For example, the first information is used to indicate one of the following: the third device identifier is associated with the first device identifier and the first service identifier; the second service identifier is associated with the first device identifier and the first service identifier; the third device identifier and the second service identifier are associated with the first device identifier; the third device identifier and the second service identifier are associated with the first service identifier; the third device identifier is associated with the first device identifier; the first service identifier is associated with the first device identifier, etc.

[0313] In some embodiments, generating a second token may include at least one of the following: using a second device identifier as or set as a publisher statement in a second token statement; using a first device identifier as or set as a listener statement in a second token statement; using a fourth device identifier as or set as a subject statement in a second token statement; using a first service identifier as or set as a scope statement in a second token statement; using a resource owner identifier as or set as a resource owner identifier statement in a second token statement; or using a third device identifier as or set as an actor statement in a second token statement.

[0314] In some embodiments, generating a second token may include at least one of the following: using a second device identifier as or set as a publisher statement in a second token statement; using a second device identifier as or set as a publisher statement in a second token statement; using a first device identifier as or set as a listener statement in a second token statement; using a third device identifier as or set as a subject statement in a second token statement; using a first service identifier as or set as a scope statement in a second token statement.

[0315] In step S2108, the first device sends a first response to the second device.

[0316] In some embodiments, the second device receives a first response sent by the first device.

[0317] In some embodiments, the first response is determined based on a first message.

[0318] In some embodiments, the first response is used to indicate a response requesting the first device to send a second token to the second device based on the first token, or the first response is used to indicate a response requesting the second token.

[0319] For example, when the first message is used to request the first device to send a second token to the second device based on the first token, the first response is used to indicate the response to the request for the first device to send a second token to the second device based on the first token. Here, the first response can be a response to a token exchange request.

[0320] For example, when the first message is used to request a second token, the first response is used to indicate the response to the request for the second token. Here, the first response can be a response to a token request.

[0321] In some embodiments, the first response includes a second token, and / or the first response includes a first indication message indicating that the token exchange was successful.

[0322] In some embodiments, the first response includes a second indication message, which indicates that the token exchange failed or the second token was not successfully generated.

[0323] For example, the first indication information and the second indication information can both be one or more bits, fields, or information units, etc.

[0324] In some embodiments, the name of the first response is not limited, and it may be, for example, a token exchange response or a token exchange response message or a token request response or a token request response message, etc.

[0325] In step S2109, the second device sends a fifth message to the third device.

[0326] In some embodiments, the third device receives a fifth message sent by the second device.

[0327] In some instances, after obtaining the second token, the second device sends a fifth message to the third device.

[0328] In some embodiments, the fifth message includes a second token.

[0329] In some embodiments, the fifth message is used to request the invocation of service information (e.g., service API) of a third device. Here, invoking the service information of a third device may also refer to accessing the service information of a third device.

[0330] In some embodiments, the name of the fifth message is not limited, and it may be, for example, a service call request or a service call request message, or a service API call request or a service API call request message.

[0331] In some alternative embodiments, the third device determines whether to authorize the invocation of the third device's service information.

[0332] For example, if the third device determines that the second token includes an actor statement, it determines the authorized call to the third device's service information based on the fact that the identifier in the actor statement in the second token is the same as the identifier of the fifth device, wherein the identifier of the fifth device is the identifier of the second device that has been authenticated.

[0333] For example, if the third device determines that the second token includes an actor's claim identifier, it can determine the authorized call information for the third device's services based on the fact that the actor's claim identifier in the second token is the same as the fifth device's identifier.

[0334] For example, if the third device determines that the second token does not contain an actor's statement, it determines the service information authorized to invoke the third device based on the fact that the identifier of the subject statement in the second token is the same as the identifier of the fifth device.

[0335] For example, if the third device determines that the second token includes an actor statement, it will not authorize the invocation of the third device's service information based on the fact that the identifier in the actor statement in the second token is different from the identifier of the fifth device.

[0336] For example, if the third device determines that the second token does not contain an actor declaration, it determines that it does not authorize the invocation of the third device's service information based on the fact that the identifier of the subject declaration in the second token is different from the identifier of the fifth device.

[0337] In step S2110, the third device sends a fourth response to the second device.

[0338] In some embodiments, the second device receives a fourth response sent by the third device.

[0339] In some embodiments, the fourth response is used to indicate a response that requests the invocation of service information from a third device.

[0340] In some embodiments, the fourth response is used to indicate a response related to service information of the third device. Here, a service-related response of the third device may refer to a response generated when the service of the third device is invoked, etc. For example, the fourth response is used to indicate a response when the service information of the third device is invoked.

[0341] In some embodiments, the fourth response is determined based on the fifth message.

[0342] For example, the fourth response includes a seventh instruction message or an eighth instruction message; wherein the seventh instruction message is used to indicate authorized access to the third device's service information and / or to indicate a response related to the third device's service; and the eighth instruction message is used to indicate non-authorized access to the third device's service information.

[0343] For example, the seventh and eighth indication information can each be one or more bits, fields, or information units.

[0344] In some embodiments, the name of the fourth response is not limited, and it may be, for example, a service call response, a service call request response, a service API call response, or a service API call response message.

[0345] In step S2111, the second device sends a fifth response to the fourth device.

[0346] In some embodiments, the fourth device receives a fifth response sent by the second device.

[0347] In some embodiments, the fifth response is determined based on the fourth response. For example, the response content included in the fifth response may be the same as the response content included in the fourth response.

[0348] In some embodiments, the fifth response is used to provide information on whether to authorize the invocation of services from a third device.

[0349] In some embodiments, the fifth response is used for at least a response related to service information of the third device. For example, the fifth response is used to indicate that service information of the third device has been invoked.

[0350] For example, the fifth response includes a ninth instruction message or a tenth instruction message; wherein the ninth instruction message is used to indicate authorized access to the third device's service information and / or to indicate a service-related response of the third device; and the tenth instruction message is used to indicate unauthorized access to the third device's service information.

[0351] For example, the ninth instruction information and the tenth instruction information can each be one or more bits, fields, or information units, etc.

[0352] In some embodiments, the name of the fifth response is not limited, and it may be, for example, a service call response, a service call request response, a service API call response, or a service API call response message.

[0353] In some embodiments, the names of information, etc., are not limited to the names described in the embodiments. Terms such as "information", "message", "signal", "signaling", "report", "configuration", "indication", "instruction", "command", "channel", "parameter", "domain", "field", "symbol", "symbol", "codebook", "codeword", "codepoint", "bit", "data", "program", and "chip" can be used interchangeably.

[0354] In some embodiments, “get,” “obtain,” “receive,” “transmit,” “bidirectional transmission,” and “send and / or receive” can be used interchangeably and can be interpreted as receiving from other entities, obtaining from protocols, obtaining from higher layers, obtaining through self-processing, or autonomous implementation, among other meanings.

[0355] In some embodiments, terms such as “send,” “transmit,” “report,” “distribute,” “transfer,” “bidirectional transmission,” “send and / or receive” can be used interchangeably.

[0356] In some embodiments, terms such as "certain", "preset", "default", "set", "indicated", "a certain", "any", and "first" can be used interchangeably. "Certain A", "preset A", "default A", "set A", "indicated A", "a certain A", "any A", and "first A" can be interpreted as A pre-defined in a protocol or the like, or as A obtained through setting, configuration, or instruction, or as specific A, a certain A, any A, or first A, but are not limited thereto.

[0357] In some embodiments, the determination or judgment can be made by a value represented by 1 bit (0 or 1), or by a true or false value (boolean), or by a comparison of numerical values ​​(e.g., a comparison with a predetermined value), but is not limited thereto.

[0358] The information processing method involved in the embodiments of this disclosure may include at least one of steps S2101 to S2111. For example, step S2101 can be implemented as an independent embodiment; step S2102 can be implemented as an independent embodiment; step S2103 can be implemented as an independent embodiment; step S2104 can be implemented as an independent embodiment; step S2105 can be implemented as an independent embodiment; step S2106 can be implemented as an independent embodiment; step S2107 can be implemented as an independent embodiment; step S2108 can be implemented as an independent embodiment; step S2109 can be implemented as an independent embodiment; step S2110 can be implemented as an independent embodiment; step S2111 can be implemented as an independent embodiment; the combination of steps S2102 and S2103 can be implemented as an independent embodiment; the combination of steps S2104 and S2105 can be implemented as an independent embodiment; the combination of steps S2101, S2102, and S2103 can be implemented as an independent embodiment; step S2101 step S210 The combination of step S2105 and step S2106 can be implemented as an independent embodiment; the combination of step S2107 and step S2108 can be implemented as an independent embodiment; the combination of step S2106, step S2107 and step S2108 can be implemented as an independent embodiment; the combination of step S2109, step S2110 and step S2111 can be implemented as an independent embodiment; the combination of step S2107, step S2108, step S2109, step S2110 and step S2111 can be implemented as an independent embodiment; the combination of step S2109 to step S2110 and step S2107 can be implemented as an independent embodiment; the combination of step S2106, step S2109 to step S2110 and step S2111 can be implemented as an independent embodiment; the combination of step S2101 to step S2111 can be implemented as an independent embodiment.

[0359] In some embodiments, steps S2101 to S2106 and steps S2109 to S2111 may be optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0360] In some embodiments, steps S2101 to S2103, S2106, and S2109 to S2111 may be optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0361] In some embodiments, steps S2109 to S2111 may be optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0362] In the embodiments disclosed herein, each embodiment can be implemented individually or in combination with each other, and the steps in each embodiment can be distinguished by their order.

[0363] Figure 2B is an interactive schematic diagram illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 2B, this embodiment of the present disclosure relates to an information processing method used in an information processing system 100, the method comprising:

[0364] In step S2201, the second and third devices send authorization information to the first device.

[0365] The optional implementation of step S2201 can be found in the optional implementation of step S2101 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0366] In step S2202, the second device sends a second message to the first device, which is used to request a third token.

[0367] The optional implementation of step S2202 can be found in the optional implementation of step S2104 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0368] In step S2203, the first device sends a second response to the second device, the second response including a third token.

[0369] The optional implementation of step S2203 can be found in the optional implementation of step S2105 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0370] In step S2204, the second device sends a first message to the first device. The first message includes a first token and is used to request the first device to send a second token to the second device based on the first token.

[0371] The optional implementation of step S2204 can be found in the optional implementation of step S2107 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0372] In step S2205, the first device sends a first response to the second device, the first response including a second token.

[0373] The optional implementation of step S2205 can be found in the optional implementation of step S2108 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0374] The above embodiments can be implemented individually or in combination with each other, and the steps in each embodiment can be distinguished by their order. Optional implementation methods can be found in the optional implementation methods of the steps in Figure 2A, which will not be repeated here.

[0375] Figure 2C is an interactive schematic diagram illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 2C, this embodiment of the present disclosure relates to an information processing method used in an information processing system 100, the method comprising:

[0376] In step S2301, the second and third devices send authorization information to the first device.

[0377] The optional implementation of step S2301 can be found in the optional implementation of step S2101 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0378] In step S2302, the second device sends a first message to the first device. The first message includes the first device identifier and / or the first service identifier. The first message is used to request a second token.

[0379] The optional implementation of step S2302 can be found in the optional implementation of step S2107 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0380] In step S2303, the first device sends a first response to the second device, the first response including a second token.

[0381] The optional implementation of step S2303 can be found in the optional implementation of step S2108 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0382] In step S2304, the second device sends a fifth message to the third device, which is used to request the service information of the third device.

[0383] The optional implementation of step S2304 can be found in the optional implementation of step S2109 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0384] In step S2305, the third device sends a fourth response to the second device, which is used to indicate the response related to the service information of the third device.

[0385] The optional implementation of step S2305 can be found in the optional implementation of step S2110 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0386] The above embodiments can be implemented individually or in combination with each other, and the steps in each embodiment can be distinguished by their order. Optional implementation methods can be found in the optional implementation methods of the steps in Figure 2A, which will not be repeated here.

[0387] Figure 3A is an interactive schematic diagram illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 3A, this embodiment of the present disclosure relates to an information processing method for an information processing system 100, the method including one of the following steps:

[0388] In step S3101, the second device sends a first message to the first device, wherein the first message is used to request the first device to send a second token to the second device based on the first token, or the first message is used to request the second token.

[0389] The optional implementation of step S3101 can be found in the optional implementation of step S2107 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0390] In step S3102, the first device sends a first response to the second device, the first response including a second token.

[0391] The optional implementation of step S3102 can be found in the optional implementation of step S2108 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0392] In step S3103, the second device sends a fifth message to the third device. The fifth message includes a second token and is used to request the service information of the third device.

[0393] The optional implementation of step S3103 can be found in the optional implementation of step S2109 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0394] In step S3104, the third device sends a fourth response to the second device, which is used to indicate the third device's response related to service information.

[0395] The optional implementation of step S3104 can be found in the optional implementation of step S2110 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0396] In some embodiments, the above methods may include the methods described in the above-described information processing system side, first device side, second device side, third device side and / or fourth device side embodiments, which will not be repeated here.

[0397] The above embodiments can be implemented individually or in combination with each other, and the steps in each embodiment can be distinguished by their order.

[0398] Figure 3B is an interactive schematic diagram illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 3B, this embodiment of the present disclosure relates to an information processing method for an information processing system 100, the method including one of the following steps:

[0399] In step S3201, the fourth device sends a fourth message to the core network device, the fourth message including the first token. Optionally, the core network device may include at least one of the following: the first device, the second device, and the third device.

[0400] The optional implementation of step S3201 can be found in the optional implementation of step S2106 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0401] In step S3202, the core network device determines the second token based on the first token, and invokes the service information of the third device based on the second token.

[0402] The optional implementations of step S3202 can be found in the optional implementations of steps S2107 and S2109 in Figure 2A, as well as other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0403] In step S3203, the core network device sends a fifth response to the fourth device. The fifth response is used to indicate the response for calling the service information of the third device.

[0404] The optional implementation of step S3203 can be found in the optional implementation of step S2111 in Figure 2A, and other related parts in the embodiments involved in Figure 2A, which will not be repeated here.

[0405] In some embodiments, the above methods may include the methods described in the above-described information processing system side, first device side, second device side, third device side and / or fourth device side embodiments, which will not be repeated here.

[0406] The above embodiments can be implemented individually or in combination with each other, and the steps in each embodiment can be distinguished by their order.

[0407] This disclosure provides an information processing method that enables a first AEF to securely obtain the authorization information of a second AEF by providing the CCF with the authorization information of the API caller.

[0408] Example 1: A nested API call mechanism based on token exchange.

[0409] Figure 4A is a flowchart illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 4A, the present disclosure relates to an information processing method, which includes:

[0410] In step S4100, the first AEF and the second AEF configure the authorization information to the CCF or the authorization function.

[0411] Optionally, the first AEF can be the second device in the previous embodiments, and the second AEF can be the third device in the previous embodiments; the CCF or authorization function can be the first device in the previous embodiments; the authorization information of the first AEF can be the first authorization information in the previous embodiments, and the authorization information of the second AEF can be the second authorization information in the previous embodiments. Here, the first AEF and the second AEF can be AEF-1 and AEF-2, respectively.

[0412] Optionally, the authorization information of the first AEF may include an API caller ID and service API information, which is used to indicate the API caller authorized to access the service API of the first AEF. For example, the authorization information of the first AEF may include the first API caller ID and the first service information in the previous embodiments.

[0413] Optionally, the authorization information of the second AEF may include an API caller ID and service API information, which is used to indicate the API caller authorized to access the service API of the second AEF. For example, the API caller ID included in the authorization information of the second AEF may be the identifier of the first AEF. For example, the authorization information of the second AEF may include the second API caller ID and the second service information in the previous embodiments.

[0414] Step S4101: The API caller requests the first token.

[0415] Optionally, the first token can be token1 (token#1).

[0416] Optionally, the API caller requests a first token to invoke the service API opened by the first AEF.

[0417] Optionally, the CCF authorizes API callers based on the authorization information of the first AEF.

[0418] Optionally, the CCF authorizes the API caller based on the authorization information of the first AEF and the authorization information of the resource owner. Optionally, the authorization information of the resource owner can be the third authorization information in the previous embodiments.

[0419] Optionally, if the CCF or authorization function determines that the API caller is authorized and finds that the target AEF (e.g., the first AEF) needs to trigger the service of another AEF to obtain information to generate a response for the API caller, then it adds the identifier of the target AEF (e.g., the first AEF identifier (identity, ID)) to the token's authorized actor (may_act) declaration. An example of an authorized actor declaration for the first token is as follows:

[0420] Here, `may_act` is used to declare that only the AEF listed in `may_act` can trigger the token exchange process associated with the first token. Here, the first AEF identifier can be the third device identifier from the previous embodiments.

[0421] Optionally, an example of the first token may be as shown in Table 1 of the previous embodiments; wherein, the CCF identifier is set as a publisher declaration; the first AEF identifier is set as a listener declaration; the API caller identifier is set as a subject declaration; the resource owner identifier is set as a resource owner identifier declaration; and the service API of the first AEF is set as a scope declaration. Optionally, the CCF identifier may be a second device identifier; the first AEF identifier may be a third device identifier; the API caller identifier may be a fourth device identifier; the service API of the first AEF may be service information (e.g., a service API) indicated by the second service identifier; and the resource owner identifier may be a resource owner identifier.

[0422] Nested AEFs are not defined in the communication protocol here. Nested AEFs mean that an API caller triggers one AEF to access the service API exposed by another AEF.

[0423] In step S4102, the API caller sends a service API call request to the first AEF.

[0424] Optionally, the service API call request includes the first token received in step S4101. This service API call request can be the fourth message from a previous implementation.

[0425] In step S4103, the first AEF decides to call the service API provided by the second AEF.

[0426] Optionally, the first AEF determines which service API to call based on the service API call request (i.e., the service information in the previous embodiment).

[0427] Step S4104: The first AEF performs mutual authentication with the CCF or the authorization function.

[0428] Optionally, after the first AEF and the CCF or authorized function mutually authenticate each other, the CCF or authorized function can obtain the identifier of the first AEF.

[0429] In step S4105a, the first AEF sends a token exchange request to the CCF or the authorization function.

[0430] Optionally, the token exchange request may include at least one of the following: a first token, a scope, a listener, an authorization type, and a third token of the first AEF; the authorization type is set to token exchange; the listener (IE) is set to the identifier of the second AEF; and the scope is set to the service API opened by the second AEF. Here, the token exchange request may be the first message in the previous embodiment; the scope may be the first service identifier in the previous embodiment; the listener may be the first device identifier in the previous embodiment; and the authorization type may be the authorization identifier in the previous embodiment.

[0431] Optionally, if the first AEF determines that the first token includes the resource owner's identifier, it sends a token exchange request to the CCF or the authorization function. This can reduce resource waste caused by the authorization process between the first AEF and the resource owner.

[0432] In step S4105b, the first AEF sends a token request to the CCF or the authorization function.

[0433] Optionally, the token request includes the identifier of the second AEF and the service API of the second AEF. Here, the token request can be the first message in the previous embodiment; the identifier of the second AEF can be the first device identifier in the previous embodiment; and the service API of the second AEF can be the first service identifier in the previous embodiment.

[0434] In step S4106a, the CCF or authorization function sends a token exchange response to the first AEF.

[0435] Optionally, the token exchange response can be the first response in the previous embodiments.

[0436] Optionally, the CCF may generate a second token. This second token can be the same as the one used in the previous embodiments. An example of an actor declaration for the second token is as follows:

[0437] Optionally, the second token can be as shown in Table 3 of the previous embodiments; wherein, the CCF identifier is set as a publisher declaration; the second AEF identifier is set as a listener declaration; the API caller identifier is set as a subject declaration; the resource owner identifier is set as a resource owner identifier declaration; the service API of the second AEF is set as a scope declaration; and the first AEF identifier is set as an actor declaration. Optionally, the CCF identifier can be a second device identifier; the first AEF identifier can be a third device identifier; the second AEF identifier can be a first device identifier; the API caller identifier can be a fourth device identifier; the service API of the second AEF can be service information (e.g., a service API) indicated by the first service identifier; and the resource owner identifier can be a resource owner identifier.

[0438] Optionally, the CCF generates a second token based on the token exchange request if at least one of the following conditions is met:

[0439] The scope of the first token can be mapped to the scope provided in the token exchange request. For example, if an API caller triggers a service API of the first AEF (e.g., the SEAL SS_LocationInfoRetrieval API), then the first AEF needs to trigger a service API provided by the second AEF (e.g., a location-related service API). Thus, a mapping relationship exists between the location-related service API and the SEAL SS_LocationInfoRetrieval API. The CCF needs to store this mapping relationship. Here, the mapping relationship can be the association relationship seen in previous embodiments;

[0440] The first AEF is authorized to access the service API of the second AEF, and this authorization is determined based on the authorization information of the second AEF.

[0441] The identifier of the first AEF (i.e., the first AEF identifier) ​​is the same as the identifier in the may_act declaration in the first token;

[0442] The identifier of the first AEF in the third token (actor_token) (i.e., the identifier in the main declaration) and the identifier in the may_act declaration in the first token;

[0443] The identifier in the listener's statement in the first token is the same as the identifier after the first AEF certification;

[0444] The identifier in the audience statement of the first token is the same as the identifier in the subject statement of the third token.

[0445] If the above conditions are met, the CCF or authorization function generates a second token for the first AEF; otherwise, the CCF or authorization function sends a failure message to the first AEF, indicating that the token exchange failed. This failure message can also be the first response in the previous embodiment.

[0446] For example, the CCF or authorization function checks whether the identifier of the first AEF is the same as the identifier in the may_act declaration of the first token. If the identifier of the first AEF is in the may_act declaration of the first token, then the CCF or authorization function generates a second token for the first AEF; otherwise, the CCF or authorization function sends a failure message to the first AEF.

[0447] For example, if the CCF or authorization function does not receive the identifier of the second AEF (i.e., the second AEF identifier) ​​and / or the service API of the second AEF from the token exchange request, the CCF or authorization function finds the identifier of the second AEF and the service API of the second AEF based on the mapping information. The identifier of the second AEF and the service API of the second AEF are used to generate the second token. The mapping information is stored in the CCF and is used to indicate the relationship between the service API of the first AEF, the identifier of the first AEF, the service API of the second AEF, and the identifier of the second AEF. This mapping information can be the first information in the previous embodiment.

[0448] For example, the CCF or the authorization function checks whether the identifier of the first AEF in the third token (actor_token) is the same as the identifier in the authorized actor (may_act) declaration of the first token. If the identifier of the first AEF is in the may_act declaration of the first token, then the CCF generates a second token for the first AEF. Otherwise, the CCF or the authorization function sends a failure message to the first AEF, indicating that the token exchange failed.

[0449] In step S4106b, the first AEF sends a token response to the CCF or the authorization function.

[0450] Optionally, the token response can be the first response in the previous embodiments.

[0451] Optionally, the second token may be as shown in Table 4 of the previous embodiments; wherein, the CCF identifier is set as the publisher declaration; the second AEF identifier is set as the listener declaration; the first AEF identifier is set as the subject declaration; the resource owner identifier is set as the resource owner identifier declaration; and the service API of the second AEF is set as the scope declaration.

[0452] Optionally, the CCF or authorization function may determine the authorization of the first AEF based on the authorization information provided by the second AEF. If the CCF or authorization function determines that the first AEF is authorized, it generates a second token for the first AEF. Otherwise, the CCF or authorization function sends a failure message to the first AEF, indicating that the token request failed.

[0453] Step S4107: The first AEF and the second AEF perform mutual authentication.

[0454] Optionally, after authentication between the first AEF and the second AEF, the second AEF can obtain the identifier of the first AEF.

[0455] In step S4108, the first AEF sends a service API call request to the second AEF based on the second token.

[0456] Optionally, the first AEF, acting as the API caller, sends a service API call request to the second AEF based on the second token. This service API call request can be the fifth message in the previous embodiments.

[0457] Step S4109: The second AEF performs token verification.

[0458] Optionally, if the second token includes an actor declaration, the second AEF checks whether the identifier of the first AEF obtained in step S4107 is the same as the identifier of the actor declaration in the second token; if they are the same, the second AEF sends a success message to the first AEF, which indicates that the first AEF can delegate the service request or is authorized to request the service API of the second AEF; if they are different, the second AEF sends a failure message to the first AEF, which indicates that the first AEF has not delegated the service request or that the first AEF cannot delegate the API caller to make a service request or is not authorized to request the service API of the second AEF.

[0459] Optionally, if the second token does not include an actor declaration, the second AEF checks whether the identifier of the first AEF obtained in step S4107 is the same as the identifier of the subject declaration in the second token; if they are the same, the second AEF sends a success message to the first AEF, which indicates that the first AEF can delegate the service request or is authorized to request the service API of the second AEF; if they are different, the second AEF sends a failure message to the first AEF, which indicates that the first AEF is not authorized to request the service API of the second AEF.

[0460] In step S4110, the second AEF sends a service API call response to the first AEF.

[0461] Optionally, once the second AEF has determined the API caller invoking the service API based on the authorization information, the first AEF receives the service API call response generated by the service API call. This service API call response can be the fourth response in the previous embodiments.

[0462] Step S4111: The first AEF sends an API call response to the API caller.

[0463] Optionally, the first AEF sends a service API call response generated by the service API call of the second AEF to the API caller.

[0464] Optionally, the first AEF sends information about the service API call response generated by the service API call based on the second AEF to the API caller.

[0465] Example 2: Actor token request and response.

[0466] Figure 4B is a flowchart illustrating an information processing method according to an embodiment of the present disclosure. As shown in Figure 4B, the present disclosure relates to an information processing method, which includes:

[0467] In step S4201, the CCF or authorization function and the network function (e.g., the first AEF) perform mutual authentication.

[0468] Optionally, after the CCF or authorization function mutually authenticates with the network function (e.g., the first AEF), the CCF can obtain the identifier of the network function (e.g., the first AEF).

[0469] Alternatively, the network function is a function in the CAPIF system (e.g., AEF).

[0470] In step S4202, the network function (e.g., the first AEF) sends an actor token request to the CCF or the authorization function.

[0471] Optionally, the actor token request can be the second message in the previous embodiment.

[0472] In step S4203, the CCF or authorization function sends an actor token to the network function (e.g., the first AEF).

[0473] Alternatively, the actor token can be the third token used in the previous embodiments.

[0474] Optionally, the actor token can be as shown in Table 2 of the previous embodiments; wherein, the CCF identifier is set as the publisher declaration, and the CCF identifier is set as the listener declaration; the first AEF identifier is set as the subject declaration. If other network functions request the actor token from the first device, the subject declaration of the actor token is the identifier of the other network function.

[0475] Example 3: This embodiment of the disclosure relates to an information processing method, which includes:

[0476] The method provided in this disclosure embodiment can enable the first AEF to securely access the authorization information of the second AEF through the authorization information of the API caller provided by CCF.

[0477] First AEF (e.g., AEF-1):

[0478] In some embodiments, the first AEF can configure authorization information to the CCF or authorization function. This authorization information can be the first authorization information in previous embodiments; it may include the API caller ID and the service API (or service API information).

[0479] In some embodiments, the first AEF can send a token exchange request to the CCF or an authorization function. The token exchange request may include at least one of the following: a first token (e.g., token #1), a scope (optional), an audience (optional), an authorization type, and an actor token of the first AEF (optional). The authorization type is set to token exchange; the audience is set to the identifier of the second AEF; and the scope is set to the service APIs exposed by the second AEF.

[0480] In some embodiments, if the first token includes a resource owner ID, the first AEF can send a token exchange request to the CCF or the authorization function.

[0481] In some embodiments, the first AEF can send a token request to the CCF or authorization function, the token request including the identifier of the second AEF and the service API of the second AEF.

[0482] In some embodiments, the first AEF can send a service API call request, including a second token, to the second AEF.

[0483] In some embodiments, the first AEF can send a request to the CCF or authorization function to request an actor token; the request may be the second message in the previous embodiments.

[0484] Second AEF (e.g., AEF-2):

[0485] In some embodiments, the second AEF can configure authorization information to the CCF or authorization function. This authorization information can be the second authorization information from previous embodiments; it may include the API caller ID (e.g., the identifier of the first AEF) and the service API (or service API information).

[0486] In some embodiments, the second AEF can check whether the identifier of the first AEF obtained in step S4107 (i.e., the second AEF and the first AEF mutually authenticate each other) is the same as the identifier in the actor declaration of the second token (e.g., token #2). If they are the same, the second AEF sends a success message to the first AEF, indicating that the first AEF can delegate the service request or is authorized to request the service API of the second AEF; if they are different, the second AEF sends a failure message to the first AEF, indicating that the first AEF either delegates the service request or is not authorized to request the service API of the second AEF.

[0487] In some embodiments, the second AEF can check whether the identifier of the first AEF obtained in step S4107 (i.e., the second AEF and the first AEF perform mutual authentication) is the same as the identifier declared in the subject in the second token. If they are the same, the second AEF sends a success message to the first AEF, which indicates that the first AEF can delegate the service request or is authorized to request the service API of the second AEF; if they are different, the second AEF sends a failure message to the first AEF, which indicates that the first AEF has not delegated the service request or has not been authorized to request the service API of the second AEF.

[0488] CCF:

[0489] In some embodiments, the CCF or the authorization function can receive authorization information from the AEF (e.g., the first AEF and / or the second AEF).

[0490] In some embodiments, the CCF or authorization function can determine whether to authorize the API caller based on the authorization information of the first AEF and / or the authorization information of the resource owner. The authorization information of the resource owner can be the third authorization information in the previous embodiments.

[0491] In some embodiments, the CCF or authorization function can receive a token exchange request sent by the first AEF.

[0492] In some embodiments, the CCF or authorization function can send a failure message to the first AEF, indicating that the token exchange failed.

[0493] In some embodiments, the CCF or authorization function can generate a second token based on a token exchange request if at least one of the following conditions is met: the scope of the first token can be mapped to the scope provided in the token exchange request; the first AEF is authorized to access the service API of the second AEF; the identifier of the first AEF is the same as the identifier in the may_act declaration in the first token; whether the identifier of the first AEF in the third token (i.e., the identifier in the subject declaration) is the same as the identifier in the may_act declaration in the first token; the identifier in the listener declaration in the first token is the same as the identifier after authentication of the first AEF; and the identifier in the listener declaration in the first token is the same as the identifier in the subject declaration in the third token.

[0494] In some embodiments, the CCF or authorization function checks whether the identifier of the first AEF is the same as the identifier in the may_act declaration of the first token. If the identifier of the first AEF is in the may_act declaration of the first token, the CCF or authorization function generates a second token for the first AEF; otherwise, the CCF or authorization function sends a failure message to the first AEF.

[0495] In some embodiments, the CCF or the authorization function checks whether the identifier of the first AEF in the third token (actor_token) is the same as the identifier in the authorized actor (may_act) declaration of the first token. If the identifier of the first AEF is in the may_act declaration of the first token, then the CCF generates a second token for the first AEF. Otherwise, the CCF or the authorization function sends a failure message to the first AEF, indicating that the token exchange failed.

[0496] In some embodiments, if the CCF or authorization function does not receive the identifier of the second AEF and the service API of the second AEF from the token exchange request, the CCF or authorization function finds the identifier of the second AEF and the service API of the second AEF based on the mapping information. The identifier of the second AEF and the service API of the second AEF are used to generate a second token. The mapping information is stored in the CCF and is used to indicate the relationship between the service API of the first AEF, the identifier of the first AEF, the service API of the second AEF, and the identifier of the second AEF. This mapping information may be the first information in the previous embodiments.

[0497] In this embodiment, some or all of the steps and their optional implementations can be arbitrarily combined with some or all of the steps in other embodiments, and the steps in each embodiment can be distinguished by their order, and can also be arbitrarily combined with the optional implementations of other embodiments.

[0498] This disclosure also proposes an apparatus for implementing any of the above methods. For example, an apparatus is proposed that includes units or modules for implementing the steps performed by the terminal in any of the above methods. Furthermore, another apparatus is proposed that includes units or modules for implementing the steps performed by network devices (e.g., access network devices, core network functional nodes, core network devices (e.g., first device, second device, and / or third device), fourth devices (e.g., API callers)) in any of the above methods.

[0499] It should be understood that the division of units or modules in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units or modules in the device can be implemented by a processor calling software: for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units or modules in the above device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits. The functionality of some or all of the units or modules can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an Application-Specific Integrated Circuit (ASIC), and the functionality of some or all of the units or modules is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby achieving the functionality of some or all of the units or modules. All units or modules of the above device can be implemented entirely through processor-called software, entirely through hardware circuits, or partially through processor-called software with the remaining parts implemented through hardware circuits.

[0500] In this embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a Digital Signal Processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an Application-Specific Integrated Circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. In addition, it can also be hardware circuits designed for artificial intelligence, which can be understood as ASICs, such as Neural Network Processing Units (NPUs), Tensor Processing Units (TPUs), and Deep Learning Processing Units (DPUs).

[0501] Figure 5A is a schematic diagram of the structure of a first device 5100 provided in an embodiment of this disclosure. As shown in Figure 5A, the first device 5100 includes a first transceiver module 5101. In some embodiments, the first transceiver module 5101 is used to acquire a first message. Optionally, the first transceiver module 5101 is used to perform at least one of the sending and / or receiving steps (e.g., steps S2101, S2102, S2103, S2104, S2105, S2107 and / or S2108, etc., but not limited thereto) performed by the first device 5100 in any of the above methods, which will not be described in detail here. In some embodiments, the first processing module 5102 is used to perform a first operation and / or a second operation. In some embodiments, the first device 5100 may include the first processing module.

[0502] Figure 5B is a schematic diagram of the structure of the second device 5200 provided in an embodiment of this disclosure. As shown in Figure 5B, the second device 5200 includes a second transceiver module 5201. In some embodiments, the second transceiver module 5201 is used to send a first message. Optionally, the second transceiver module 5201 is used to perform at least one of the sending and / or receiving steps (e.g., steps S2101, S2104, S2105, S2106, S2107, S2108, S2109, S2110 and / or S2111, etc., but not limited thereto) performed by the second device 5200 in any of the above methods, which will not be described in detail here. In some embodiments, the second device 5200 may include a second processing module.

[0503] Figure 5C is a schematic diagram of the structure of a third device 5300 provided in an embodiment of this disclosure. As shown in Figure 5C, the third device 5300 includes a third transceiver module 5301. In some embodiments, the third transceiver module 5301 is used to send authorization information. Optionally, the third transceiver module 5301 is used to perform at least one of the sending and / or receiving steps (e.g., steps S2101, S2109, and / or S2110, but not limited thereto) performed by the third device 5300 in any of the above methods, which will not be described in detail here. In some embodiments, the third device 5300 may include a third processing module.

[0504] Figure 5D is a schematic diagram of the structure of the fourth device 5400 provided in an embodiment of this disclosure. As shown in Figure 5D, the fourth device 5400 includes a fourth transceiver module 5401. In some embodiments, the fourth transceiver module 5401 is used to receive and acquire a first token. Optionally, the fourth transceiver module 5401 is used to perform at least one of the sending and / or receiving steps (e.g., steps S2102, S2103, S2106 and / or step S2111, but not limited thereto) performed by the fourth device 5400 in any of the above methods, which will not be described in detail here. In some embodiments, the fourth processing module 5402 is used to interact with the server to perform a third operation. In some embodiments, the fourth device 5400 may include the fourth processing module.

[0505] In some embodiments, the transceiver module may include a transmitting module and / or a receiving module, which may be separate or integrated. Optionally, the transceiver module may be interchangeable with a transceiver. For example, the first transceiver module described above includes a first transmitting module and / or a first receiving module. For example, the second transceiver module described above includes a second transmitting module and / or a second receiving module.

[0506] In some embodiments, the processing module may be a single module or may include multiple sub-modules. Optionally, the multiple sub-modules may each perform all or part of the steps required by the processing module. Optionally, the processing module may be interchangeable with a processor.

[0507] Figure 6A is a schematic diagram of the structure of the communication device 6100 proposed in an embodiment of this disclosure. The communication device 6100 can be a network device (e.g., an access network device, a core network device (e.g., a first device, a second device, a third device, etc., or a fourth device), a terminal, a chip, a chip system, or a processor that supports the network device in implementing any of the above methods, or a chip, chip system, or processor that supports the terminal in implementing any of the above methods. The communication device 6100 can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0508] As shown in Figure 6A, the communication device 6100 includes one or more processors 6101. The processor 6101 can be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit (CPU). The baseband processor can be used to process communication protocols and communication data, while the CPU can be used to control communication devices (e.g., base stations, baseband chips, terminal devices, terminal device chips, DUs or CUs, etc.), execute programs, and process program data. Optionally, the communication device 6100 can be used to execute any of the above methods. Optionally, one or more processors 6101 can be used to invoke instructions to cause the communication device 6100 to execute any of the above methods.

[0509] In some embodiments, the communication device 6100 further includes one or more transceivers 6102. When the communication device 6100 includes one or more transceivers 6102, the transceivers 6102 perform at least one of the communication steps such as sending and / or receiving in the above method (e.g., steps S2101 to S2111, but not limited thereto), and the processor 6101 performs at least one of other steps (e.g., steps corresponding to optional embodiments of steps S2107 and / or S2109, but not limited thereto). In optional embodiments, the transceiver may include a receiver and / or a transmitter, which may be separate or integrated. Optionally, the terms transceiver, transceiver unit, transceiver, transceiver circuit, interface circuit, interface, etc., can be used interchangeably; the terms transmitter, transmitting unit, transmitter, transmitting circuit, etc., can be used interchangeably; and the terms receiver, receiving unit, receiver, receiving circuit, etc., can be used interchangeably.

[0510] In some embodiments, the communication device 6100 further includes one or more memories 6103 for storing data. Optionally, all or part of the memories 6103 may be located outside the communication device 6100. In optional embodiments, the communication device 6100 may include one or more interface circuits 6104. Optionally, the interface circuits 6104 are connected to the memories 6103 and can be used to receive data from the memories 6103 or other devices, and to send data to the memories 6103 or other devices. For example, the interface circuits 6104 can read data stored in the memories 6103 and send that data to the processor 6101.

[0511] The communication device 6100 described in the above embodiments may be a network device or a terminal, but the scope of the communication device 6100 described in this disclosure is not limited thereto, and the structure of the communication device 6100 may not be limited by FIG. 6A. The communication device may be a standalone device or a part of a larger device. For example, the communication device may be: (1) a standalone integrated circuit IC, or chip, or chip system or subsystem; (2) a collection of one or more ICs, optionally, the IC collection may also include storage components for storing data and programs; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, terminal device, smart terminal device, cellular phone, wireless device, handheld device, mobile unit, vehicle device, network device, cloud device, artificial intelligence device, etc.; (6) others, etc.

[0512] Figure 6B is a schematic diagram of the structure of chip 6200 according to an embodiment of this disclosure. For cases where the communication device 6100 can be a chip or a chip system, please refer to the schematic diagram of chip 6200 shown in Figure 6B, but it is not limited thereto.

[0513] Chip 6200 includes one or more processors 6201. Chip 6200 is used to perform any of the methods described above.

[0514] In some embodiments, chip 6200 further includes one or more interface circuits 6202. Optionally, terms such as interface circuit, interface, and transceiver pin can be used interchangeably. In some embodiments, chip 6200 further includes one or more memories 6203 for storing data. Optionally, all or part of the memories 6203 may be located outside chip 6200. Optionally, interface circuit 6202 is connected to memory 6203, and interface circuit 6202 can be used to receive data from memory 6203 or other devices, and interface circuit 6202 can be used to send data to memory 6203 or other devices. For example, interface circuit 6202 can read data stored in memory 6203 and send the data to processor 6201.

[0515] In some embodiments, the interface circuit 6202 performs at least one of the communication steps such as sending and / or receiving in the above-described method (e.g., steps S2101 to S2111, but not limited thereto). For example, the interface circuit 6202 performing the communication steps such as sending and / or receiving in the above-described method means that the interface circuit 6202 performs data interaction between the processor 6201, the chip 6200, the memory 6203, or the transceiver device. In some embodiments, the processor 6201 performs at least one of other steps (e.g., steps corresponding to optional embodiments in steps S2107 and / or S2109, but not limited thereto).

[0516] The modules and / or devices described in the various embodiments, such as virtual devices, physical devices, and chips, can be combined or separated arbitrarily as needed. Optionally, some or all steps can also be performed collaboratively by multiple modules and / or devices, which is not limited here.

[0517] This disclosure also proposes a storage medium storing instructions that, when executed on the communication device 6100, cause the communication device 6100 to perform any of the above methods. Optionally, the storage medium is an electronic storage medium. Optionally, the storage medium is a computer-readable storage medium, but not limited thereto; it may also be a storage medium readable by other devices. Optionally, the storage medium may be a non-transitory storage medium, but not limited thereto; it may also be a temporary storage medium.

[0518] This disclosure also proposes a program product, including a program and / or instructions, which, when executed by a communication device, cause the communication device to perform any of the above methods. Optionally, the program product is a computer program product. Optionally, the program product is stored on the storage medium.

[0519] This disclosure also proposes a computer program that, when run on a computer, causes the computer to perform any of the above methods.

Claims

1. An information processing method, characterized in that, Performed by the first device, including: Receive a first message sent by a second device; wherein the first message is used to request the first device to send a second token to the second device based on a first token, or the first message is used to request the second token; Send a first response to the second device based on the first message.

2. The method according to claim 1, characterized in that, The first message is used to request the first device to send a second token to the second device based on the first token, and the first message includes at least one of the following: The first token; A third token, wherein the third token is used to indicate the identity of the second device; Type identifier, wherein the type identifier is used to indicate token exchange; The first device identifier is the identifier of the third device, which is the device that the fourth device requests access to; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device; or, When the first message is used to request the second token, the first message includes at least one of the following: First device identifier; The first service identifier.

3. The method according to claim 1 or 2, characterized in that, The first token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer declaration in the first token declaration, wherein the first token declaration is the declaration of the first token; A third device identifier, wherein the third device identifier is the identifier of the second device, the third device identifier is set as the listener statement in the first token statement, and the third device identifier is also set as the authorized actor statement in the first token statement; The fourth device identifier is the identifier of the fourth device, and the fourth device identifier is set as the subject declaration in the first token declaration; The second service identifier is used to indicate the service information of the second device, and the second service identifier is set to the scope declaration in the first token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the first token declaration.

4. The method according to any one of claims 1 to 3, characterized in that, When the first message requests the first device to send a second token to the second device based on the first token, the second token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement, wherein the second token statement is the statement of the second token; A first device identifier, wherein the first device identifier is the identifier of a third device, and the first device identifier is set as the listener statement in the second token statement; The fourth device identifier is the identifier of the fourth device, and the fourth device identifier is set as the subject statement in the second token statement; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as a scope declaration in the second token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the second token declaration; A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the actor statement in the second token statement; or, When the first message is used to request the second token, the second token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement; A first device identifier, wherein the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement; A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the second token statement; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as a scope declaration in the second token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the second token declaration.

5. The method according to claim 2, characterized in that, The third token includes at least one of the following: A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the third token statement, wherein the third token statement is the statement of the third token.

6. The method according to any one of claims 1 to 5, characterized in that, Before sending the second response to the second device, one of the following is also included: Generate the second token based on the first token; The second token is generated based on the first device identifier and the first service identifier included in the first message.

7. The method according to claim 6, characterized in that, The generation of the second token must satisfy at least one of the following conditions: The second service identifier in the first token is associated with the first service identifier in the first message; The second device is authorized to access the service information of the third device; The fifth device identifier of the second device is the same as the identifier in the authorized actor statement in the first token, and the fifth device identifier is the identifier of the authenticated second device; The identifier of the subject declaration in the third token is the same as the identifier of the authorized actor declaration in the first token; The fifth device identifier of the second device is the same as the identifier in the listener's statement in the first token; The identifier in the audience statement of the first token is the same as the identifier in the subject statement of the third token.

8. The method according to claim 6 or 7, characterized in that, The process of generating the second token based on the first token includes: If it is determined that the first message does not include the first device identifier and the first service identifier, the first device identifier and the first service identifier are determined based on the third device identifier, the second service identifier, and the first information included in the first token; wherein, the first information is used to indicate the association relationship between at least two of the third device identifier, the second service identifier, the first device identifier, and the first service identifier. The second token is generated based on the first device identifier and the first service identifier.

9. The method according to any one of claims 6 to 8, characterized in that, The method also includes one of the following: If it is determined that the second service identifier in the first token is not associated with the first service identifier in the first message, and / or the second device is not authorized to access the service information of the third device, then the token exchange fails or the second token is not generated. If it is determined that the fifth device identifier of the second device is different from the identifier in the authorized actor in the first token, it is determined that the token exchange failed or the second token was not generated. If the identifier of the subject declaration in the third token is different from the identifier of the authorized actor declaration in the first token, it is determined that the token exchange failed or the second token was not generated. If it is determined that the fifth device identifier of the second device is different from the identifier in the listener's statement in the first token, it is determined that the token exchange failed or the second token was not generated; If it is determined that the identifier in the listener's statement in the first token is different from the identifier in the subject's statement in the third token, the token exchange fails or a second token is not generated.

10. The method according to any one of claims 1 to 9, characterized in that, The first response includes the second token, and / or the first response includes first indication information, which indicates that the token exchange was successful; or, The first response includes a second indication message, which indicates that the token exchange failed or the second token was not successfully generated.

11. The method according to claim 2 or 5, characterized in that, Before receiving the first message sent by the second device, the method further includes: Receive a second message sent by the second device, wherein the second message is used to request the third token; Send a second response to the second device, wherein the second response includes the third token.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes at least one of the following: Obtain first authorization information from the second device, wherein the first authorization information is used to indicate at least one of the following: API caller identifier and service information; Obtain second authorization information from a third device, wherein the second authorization information is used to indicate at least one of the following: API caller identifier and service information; Obtain third-party authorization information from the resource owner, wherein the third-party authorization information is used to indicate at least one of the following: API caller identifier and resource information.

13. The method according to any one of claims 1 to 12, characterized in that, Before receiving the first message sent by the second device, the following steps are included: Receive a third message sent by a fourth device, wherein the third message is used to request the first token; A third response is sent to the fourth device, wherein the third response includes the first token.

14. The method according to claim 13, characterized in that, Before sending the third response to the fourth device, one of the following is also included: If it is determined that the fourth device is authorized, the first token is generated; The first token is generated when it is determined that the fourth device is authorized and the second device needs to obtain information from the third device to create a response for the fourth device.

15. The method according to claim 12 or 14, characterized in that, The method further includes at least one of the following: Based on the first authorization information, determine whether to authorize the fourth device; Based on the first authorization information and the third authorization information, determine whether to authorize the fourth device; Based on the second authorization information, determine whether to authorize the second device.

16. The method according to claim 14, characterized in that, The generation of the first token includes at least: Set the third device identifier of the second device to the authorized actor statement in the first token statement.

17. The method according to any one of claims 1 to 16, characterized in that, The first message is sent by the second device when it determines that the first token it has obtained includes a resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner and is set as the resource owner identifier declaration in the first token declaration.

18. An information processing method, characterized in that, Performed by a second device, including: Send a first message to a first device, wherein the first message is used to request the first device to send a second token to a second device based on a first token, or the first message is used to request the second token; Receive a first response sent by the first device, wherein the first response is determined based on the first message.

19. The method according to claim 18, characterized in that, Sending the first message to the first device includes: If the obtained first token includes a resource owner identifier, the first message is sent to the first device, wherein the resource owner identifier is the identifier of the resource owner and is set as the resource owner identifier declaration in the first token declaration.

20. The method according to claim 18 or 19, characterized in that, The first message is used to request the first device to send a second token to the second device based on the first token, and the first message includes at least one of the following: The first token; A third token, wherein the third token is used to indicate the identity of the second device; Type identifier, wherein the type identifier is used to indicate token exchange; The first device identifier is the identifier of the third device, which is the device that the fourth device requests access to; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device; or, When the first message is used to request the second token, the first message includes at least one of the following: First device identifier; The first service identifier.

21. The method according to any one of claims 18 to 20, characterized in that, The first token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer declaration in the first token declaration, wherein the first token declaration is the declaration of the first token; A third device identifier, wherein the third device identifier is the identifier of the second device, the third device identifier is set as the listener statement in the first token statement, and the third device identifier is also set as the authorized actor statement in the first token statement; The fourth device identifier is the identifier of the fourth device, and the fourth device identifier is set as the subject declaration in the first token declaration; The second service identifier is used to indicate the service information of the second device, and the second service identifier is set to the scope declaration in the first token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the first token declaration.

22. The method according to any one of claims 18 to 21, characterized in that, When the first message requests the first device to send a second token to the second device based on the first token, the second token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement, wherein the second token statement is the statement of the second token; A first device identifier, wherein the first device identifier is the identifier of a third device, and the first device identifier is set as the listener statement in the second token statement; The fourth device identifier is the identifier of the fourth device, and the fourth device identifier is set as the subject statement in the second token statement; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as a scope declaration in the second token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the second token declaration; A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the actor statement in the second token statement; or, When the first message is used to request the second token, the second token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer statement in the second token statement; A first device identifier, wherein the first device identifier is the identifier of the third device, and the first device identifier is set as the listener statement in the second token statement; A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the second token statement; A first service identifier, wherein the first service identifier is used to indicate the service information of the third device, and the first service identifier is set as a scope declaration in the second token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the second token declaration.

23. The method according to claim 20, characterized in that, The third token includes at least one of the following: A third device identifier, wherein the third device identifier is the identifier of the second device, and the third device identifier is set as the subject statement in the third token statement, wherein the third token statement is the statement of the third token.

24. The method according to any one of claims 18 to 23, characterized in that, The first response includes the second token, and / or the first response includes first indication information, which indicates that the token exchange was successful; or, The first response includes a second indication message, which indicates that the token exchange failed or the second token was not successfully generated.

25. The method according to any one of claims 18 to 24, characterized in that, The method further includes: Receive a fourth message sent by a fourth device, wherein the fourth message includes the first token; A fifth message is sent to a third device, wherein the fifth message includes the second token and is used to request the invocation of the service information of the third device.

26. The method according to claim 25, characterized in that, The method further includes: Receive a fourth response sent by the third device, wherein the fourth response is used to indicate a response related to the service information of the third device; A fifth response is sent to the third device, wherein the fifth response is determined based on the fourth response.

27. The method according to claim 20 or 23, characterized in that, Before sending the first message to the first device, the method further includes: Send a second message to the first device, wherein the second message is used to request the third token; Receive a second response sent by the first device, wherein the second response includes the third token.

28. The method according to any one of claims 18 to 27, characterized in that, The method further includes: Send the first authorization information of the second device to the first device, wherein the first authorization information is used to indicate at least one of the following: API caller and service information.

29. An information processing method, characterized in that, Performed by a fourth device, including: Send a third message to the first device, wherein the third message is used to request the first token; Receive a third response sent by the first device, wherein the third response includes the first token; The first token is sent by the fourth device to the second device, so that the second device sends a first message to the first device; the first message is used to request the first device to send a second token to the second device based on the first token.

30. The method according to claim 29, characterized in that, The first token includes at least one of the following: The second device identifier is the identifier of the first device, and the second device identifier is set as the issuer declaration in the first token declaration; A third device identifier, wherein the third device identifier is the identifier of the second device, the third device identifier is set as the listener statement in the first token statement, and the third device identifier is also set as the authorized actor statement in the first token statement; The fourth device identifier is the identifier of the fourth device, and the fourth device identifier is set as the subject declaration in the first token declaration; The second service identifier is used to indicate the service information of the second device, and the second service identifier is set to the scope declaration in the first token declaration; Resource owner identifier, wherein the resource owner identifier is the identifier of the resource owner, and the resource owner identifier is set as the resource owner identifier declaration in the first token declaration.

31. An information processing method, characterized in that, The method includes: The second device sends a first message to the first device, wherein the first message is used to request the first device to send a second token to the second device based on the first token, or the first message is used to request the second token; The first device sends a first response to the second device, wherein the first response includes the second token.

32. A communication device, characterized in that, The communication device is used to perform the information processing method according to any one of claims 1 to 17, or claims 18 to 28, or claims 29 to 30, or claim 31.

33. A communication system, characterized in that, include: A first device, a second device, and a fourth device; wherein the first device is configured to implement the information processing method according to any one of claims 1 to 17, the second device is configured to implement the information processing method according to any one of claims 18 to 28, and the fourth device is configured to implement the information processing method according to any one of claims 29 to 30.

34. A storage medium storing instructions, characterized in that, When the instructions are executed on the communication device, the communication device performs the information processing method as described in any one of claims 1 to 17, or claims 18 to 28, or claims 29 to 30, or claim 31.

35. A computer program product, said computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the information processing method according to any one of claims 1 to 17, or claims 18 to 28, or claims 29 to 30, or claim 31.

Images