Authentication and authorization of digital assets

Abstract

Example embodiments of the present disclosure are directed to authentication and authorization of digital assets. A method comprises transmitting, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; and receiving, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.

Description

AUTHENTICATION AND AUTHORIZATION OF DIGITAL ASSETSFIELD

[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for authentication and authorization of digital assets.BACKGROUND

[0002] A communication network may serve as a facility that enables communications between two or more communication devices or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. A communication device may be provided with a service by an application server.

[0003] The communication network may operate in accordance with standards such as those provided by Third Generation Partnership Project (3GPP) or European Telecommunications Standards Institute (ETSI) . Examples of standards provided by 3GPP are the so-called 3GPP standards for cellular technology generations, such as 3GPP standards for 4G technology, 5G technology, 6G technology etc.SUMMARY

[0004] In a first aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to: transmit, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; and receive, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.

[0005] In a second aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to: obtain first information regarding retrieval of a digital asset for using by a  second user; transmit, to an application function, second information indicating that the digital asset is to be used by the second user; and receive, from the application function, a validation result of the use of the digital asset by the second user.

[0006] In a third aspect of the present disclosure, there is provided a third apparatus. The third apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the third apparatus at least to: receive, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; validate the retrieval of the digital asset based on at least the first authorization information; and transmit, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.

[0007] In a fourth aspect of the present disclosure, there is provided a fourth apparatus. The fourth apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the fourth apparatus at least to: receive, from a second requesting entity, second information indicating that a digital asset is to be used by a second user; validate the use of the digital asset by the second user based on the second information; and transmit, to the second requesting entity, a validation result of the use of the digital asset by the second user.

[0008] In a fifth aspect of the present disclosure, there is provided a fifth apparatus. The fifth apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the fifth apparatus at least to: receive, from a first requesting entity, an access token request for an asset retrieval service; obtain first authorization information about usage at least a digital asset allowed to be used by the first requesting entity; and transmit, to the first requesting entity, an access token comprising the first authorization information.

[0009] In a sixth aspect of the present disclosure, there is provided a method. The method comprises: transmitting, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; and receiving, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.

[0010] In a seventh aspect of the present disclosure, there is provided a method. The  method comprises: obtaining first information regarding retrieval of a digital asset for using by a second user; transmitting, to an application function, second information indicating that the digital asset is to be used by the second user; and receiving, from the application function, a validation result of the use of the digital asset by the second user.

[0011] In an eighth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; validating the retrieval of the digital asset based on at least the first authorization information; and transmitting, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.

[0012] In a ninth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a second requesting entity, second information indicating that a digital asset is to be used by a second user; validating the use of the digital asset by the second user based on the second information; and transmitting, to the second requesting entity, a validation result of the use of the digital asset by the second user.

[0013] In a tenth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a first requesting entity, an access token request for an asset retrieval service; obtaining first authorization information about usage at least a digital asset allowed to be used by the first requesting entity; and transmitting, to the first requesting entity, an access token comprising the first authorization information.

[0014] In an eleventh aspect of the present disclosure, there is provided a first apparatus. The first apparatus comprises means for transmitting, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; and means for receiving, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.

[0015] In a twelfth aspect of the present disclosure, there is provided a second apparatus. The second apparatus comprises means for obtaining first information regarding retrieval of a digital asset for using by a second user; means for transmitting, to an application function, second information indicating that the digital asset is to be used by the second  user; and means for receiving, from the application function, a validation result of the use of the digital asset by the second user.

[0016] In a thirteenth aspect of the present disclosure, there is provided a third apparatus. The third apparatus comprises means for receiving, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; means for validating the retrieval of the digital asset based on at least the first authorization information; and means for transmitting, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.

[0017] In a fourteenth aspect of the present disclosure, there is provided a fourth apparatus. The fourth apparatus comprises means for receiving, from a second requesting entity, second information indicating that a digital asset is to be used by a second user; means for validating the use of the digital asset by the second user based on the second information; and means for transmitting, to the second requesting entity, a validation result of the use of the digital asset by the second user.

[0018] In a fifteenth aspect of the present disclosure, there is provided a fifth apparatus. The fifth apparatus comprises means for receiving, from a first requesting entity, an access token request for an asset retrieval service; means for obtaining first authorization information about usage at least a digital asset allowed to be used by the first requesting entity; and means for transmitting, to the first requesting entity, an access token comprising the first authorization information.

[0019] In a sixteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the sixth aspect.

[0020] In a seventeenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the seventh aspect.

[0021] In an eighteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the eighth aspect.

[0022] In a nineteenth aspect of the present disclosure, there is provided a computer  readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the ninth aspect.

[0023] In a twentieth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the tenth aspect.

[0024] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Some example embodiments will now be described with reference to the accompanying drawings, where:

[0026] FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0027] FIG. 2 illustrates an example block diagram of on-network mobile metaverse application layer functional model;

[0028] FIG. 3A illustrates a flow chart of an example process for authentication and authorization of asset retrieval according to some example embodiments of the present disclosure;

[0029] FIG. 3B illustrates a flow chart of an example process for authentication and authorization by an application function according to some example embodiments of the present disclosure;

[0030] FIG. 4 illustrates a flow chart of an example process for authentication and authorization of avatar retrieval in the use case 1 according to some example embodiments ;

[0031] FIG. 5 illustrates a flow chart of an example process for authentication and authorization of avatar retrieval in the use case 2 according to some example embodiments;

[0032] FIG. 6 illustrates a flow chart of an example process for authentication and authorization of avatar retrieval in the use case 3 according to some example embodiments;

[0033] FIG. 7 illustrates a flow chart of another example process for authentication and authorization of avatar retrieval according to some example embodiments;

[0034] FIG. 8 illustrates a flow chart of a further example process for authentication and authorization of avatar retrieval according to some example embodiments;

[0035] FIG. 9 illustrates a flowchart of a method implemented at a first apparatus in accordance with some example embodiments of the present disclosure;

[0036] FIG. 10 illustrates a flowchart of a method implemented at a second apparatus in accordance with some example embodiments of the present disclosure;

[0037] FIG. 11 illustrates a flowchart of a method implemented at a third apparatus in accordance with some example embodiments of the present disclosure;

[0038] FIG. 12 illustrates a flowchart of a method implemented at a fourth apparatus in accordance with some example embodiments of the present disclosure;

[0039] FIG. 13illustrates a flowchart of a method implemented at a fifth apparatus in accordance with some example embodiments of the present disclosure;

[0040] FIG. 14 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

[0041] FIG. 15 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

[0042] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0043] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

[0044] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one  of ordinary skills in the art to which this disclosure belongs.

[0045] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0046] It shall be understood that although the terms “first, ” “second, ” …, etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0047] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0048] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

[0049] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0050] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0051] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and

[0052] (b) combinations of hardware circuits and software, such as (as applicable) :

[0053] (i) a combination of analog and / or digital hardware circuit (s) with software / firmware and

[0054] (ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0055] (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0056] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0057] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) ,  4.5G, the fifth generation (5G) , 5.5G, the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0058] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

[0059] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted  display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

[0060] As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

[0061] A network function as described herein may be implemented as a network entity that includes a combination of hardware processing circuit and software and / or firmware comprising machine-readable instructions, or software comprising machine-readable instructions that are executable by at least one processor of hardware processing circuit of an apparatus. The network function may be implemented at any suitable part, level or layer of the network, including but not limited to a core network, an application level, etc. For example, an Application Programming Interface (API) Exposure Function (AEF) and Common API Framework (CAPIF) Core Function (CCF) as described below may be implemented at application enabler layer. A hardware processing circuit includes at least one processor and at least one memory storing machine-readable instructions that are executable by the at least one processor of the hardware processing circuit. A processor includes any or some combination of an accelerator, a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, a central processing unit, a graphic  processing unit, a tensor processing unit. Memory includes any or some combination of volatile or non-volatile memory (e.g., a flash memory, cache, a random-access memory (RAM) , and / or a read-only memory (ROM) ) . The memory stores the machine-readable instructions of the software and / or firmware for execution by the at least one processor of the hardware processing circuit. The machine-readable instructions are executable by the at least one processor of the hardware processing circuit cause the hardware processing circuit to perform the actions or operations of the methods described herein.

[0062] FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the communication environment 100, a first terminal device 110 (for example, a UE) is associated with a first user 101 and a second terminal device 120 (for example, a UE) is associated with a second user 102. The first user 101 and the second user 102 may access an application associated with an application function (AF) 140 by using the first terminal device 110 and the second terminal device 120, respectively. The application may include for example a gaming application, a social media application, etc. To support running of the application, the first terminal device 110, the second terminal device 120 and the AF 140 may communicate with one or more network functions (NFs) in the core network, for example, the NF 130, and the NF 150 as shown in FIG. 1.

[0063] It is to be understood that the number of devices, functions and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of devices and functions configured to implementing example embodiments of the present disclosure. For example, the environment 100 may include more than one Afs and more than two terminal devices. It is also to be noted that although the first user and the second user are shown separately in FIG. 1, in some example embodiments, they may be the same, and the first terminal device and the second terminal device may be same.

[0064] Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple  Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0065] In the communication environment 100, a user may own one or more digital assets and use one or more digital assets in an application. A digital representation of a user (for example, an avatar of the user) is a type of digital asset. Other types of digital asset may include but not limited to a token, a license (for example, a software license) , a certificate (for example, a gift certificate) , etc.

[0066] Digital asset and avatar management service requirements includes requirements related to digital assets (such as avatar, token, licenses) management. As a requirement, subject to operator policy, regulatory requirements and user consent, the metaverse enablement service should provide digital asset management mechanisms. For example, the metaverse enablement service should create, update, retrieve, delete and discover digital assets securely; manage associations between digital assets and user identifiers; allow an authorized third party to manage digital asset (s) associated with a user; differentiate between multiple types of digital assets, e.g. avatars, tokens, licenses; and manage sets of related digital assets jointly (e.g. as blocks of digital assets) . As another requirement, the metaverse enablement service should provide mechanisms to create, update, get / discover avatars as digital assets.

[0067] For the metaverse enablement service, a mobile metaverse application layer is introduced to the application enablement architecture. FIG. 2 illustrates an example of the on-network mobile metaverse application layer functional model.

[0068] As shown in FIG. 2, the mobile metaverse application layer functional entities are grouped into the vertical application layer (VAL) and the mobile metaverse application enablement layer. The mobile metaverse application enablement layer offers the mobile metaverse application enablement capabilities to the vertical application layer. The mobile metaverse application layer functional model utilizes Service Enabler Architecture Layer (SEAL) services.

[0069] The mobile metaverse application enablement layer functional entities on the UE 201 and in the network are respectively the mobile metaverse enabler client (MMEC) 202  and mobile metaverse enabler server (MMES) 203. The MMEC 202 communicates with the MMES 203 over the MM-UU reference point. The MMEC 202 provides functionality to the VAL client (s) 204 over the MM-C reference point. The VAL server (s) 205 communicate with the MMES 203 over the MM-Sreference point. The MMES 203 communicates with other MMES instances over the MM-E reference point. The MMES 203 communicates with the underlying 3GPP network system using 3GPP interfaces specified by the 3GPP network system.

[0070] There are some valid scenarios where the digital representation / avatar may be created and assigned to a user. In an example scenario, a user creates an avatar by themselves and stores in 5G system (5GS) . Then, the user has full privileges on the avatar to use in different applications. In another example scenario, the 5GS creates avatars and allocates a list of avatars to a user to use in different applications. In a further example scenario, an application function creates an avatar and synchronizes to 5GS, either 5GS or the application function grants a user to use the avatars for the application function. In this case, the avatar can only be used for this application.

[0071] One user (referred to as user A) may share his / her avatar with other user (referred to as user B) , however, the avatar shared cannot be used to represent / authenticate user B, rather user B need to be authenticated with its own identity and be proved authorized to use user A's avatar. For example, the user A creates a family avatar and can share authorization rights to the user B (for example, his / her family member) . In this case, the user B will be authenticated by the application function as the user B only and application function will check if the user B is authorized to access user A’s avatar.

[0072] A key issue with respect to authentication and authorization of a digital representation has been outlined. The key issue is related to authentication and authorization of the digital representation. Specifically, the following requirement implies the need of authentication of digital assets: the 5G system should provide mechanisms to certify the authenticity of digital assets associated with a user. The following requirement implies the need of authorization of digital assets: subject to operator policy, regulatory requirements and user consent, the 5G system should be able to authorize the avatar to be used in mobile metaverse services.

[0073] Digital assets used in mobile metaverse services may be digital representation (avatar) , software licenses, gift certificates, tokens, etc., which should be uniquely  identifiable. Avatars are digital representations of users interacting with the metaverse and other users in mobile metaverse services. In current mobile network services, users need to be authenticated to connect to mobile networks and authorized to access the requested services. In mobile metaverse services with the avatar representing the user, user authentication and authorization need to be realized via the avatar.

[0074] This key issue focuses on authentication and authorization of digital representation (e.g. avatar) which has its unique identifier.

[0075] Without authentication of avatar, an attacker can falsify an avatar to impersonate the user represented by the legitimate avatar. Then the attacker can manipulate the falsified avatar in a mobile metaverse service to launch more types of attacks. Even if the unique identifier of a legitimate avatar can be changed from time to time, the attacker can still launch such attack during the valid period of the identifier.

[0076] The 5G system should provide a means to support authenticating a digital representation to represent a user in mobile metaverse services. To meet the security requirements, the 5G system should provide a means to authenticate and authorize a user to use the digital representation (avatar) . The 5G system should provide a means to validate the authenticity of an avatar, e.g. the avatar is issued by a trusted entity, e.g. a Mobile Network Operator (MNO) , the avatar was not tampered, and the avatar is not spoofed. The 5G system should provide a means to authorize an avatar, which represents a user in specific system / context, to access the corresponding metaverse service.

[0077] It is to be noted that a user may be assigned with more than one avatar, and an avatar may represent more than one user. It is assumed that authentication is targeted on a user represented by an avatar, and authorization is targeted on the avatar which represents the user in specific system / context.

[0078] As mentioned above, avatars may be created by users, the 5GS, or application functions and stored within the 5GS. Avatars created by users or the 5GS may be utilized in application functions, whereas avatars created by application functions and stored in the 5GS may only be used within the originating application function. If the user A shares their avatar with the user B for use in an application function, the user B should be authenticated as themselves and authorized to use the user A's avatar by the application. Although the above issue is described with respect to the avatar, other types of digital asset may be faced with the similar issue.

[0079] In accordance with some example embodiments of the present disclosure, there is provided a solution for authentication and authorization of digital assets. In the solution, a requesting entity requests an NF to retrieve a digital asset. The request made by the requesting entity may include first authorization information about usage of the digital asset. The requesting entity may be a terminal device associated with a first user owning the digital asset, a terminal device associated with a second user to use the digital asset, or an AF on behalf of the first user or the second user. The NF may validate the retrieval of the digital asset at least based on the first authorization information. Then, the NF may respond to the requesting entity based on a result of the validation. In this way, the authentication and authorization of digital assets can be achieved. The security risk in using the digital assets can be reduced accordingly.

[0080] Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0081] The example embodiments may be applied to different use cases, for example the following use cases. In a first use case (also referred to as use case 1) , the first user 101 expects to use his or her digital asset in an application function. In other words, a user owning the digital asset is the same as a user to use the digital asset. In the use case 1, the first terminal device 110 or the AF 140 on behalf of the first user 101 may request retrieval of the digital asset for using by himself or herself.

[0082] In a second use case (also referred to as use case 2) , the first user 101 may share his or her digital asset with another user, for example, the second user 102. In other words, a user owning the digital asset is different from a user to use the digital asset. In the use case 2, the first terminal device 110 or the AF 140 on behalf of the first user 101 may request retrieval of the digital asset for using by the second user 102.

[0083] In a third use case (also referred to as use case 3) , the second user 102 may expect to use a digital asset of another user, for example, the first user 101. In other words, a user owning the digital asset is different from a user to use the digital asset. In the use case 3, the second terminal device 110 or the AF 140 on behalf of the second user 102 may request retrieval of the digital asset for using by the second user 102.

[0084] Some example processes are now described. FIG. 3A illustrates a flow chart of a process 300A for authentication and authorization of asset retrieval according to some example embodiments of the present disclosure. As illustrated in FIG. 3A, the process  300A involves a first requesting entity 391, a first network function 393 and a second network function 395. For the purposes of discussion, the process 300A will be discussed with reference to FIG. 1.

[0085] In the following descriptions, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0086] As shown in FIG. 3A, the first requesting entity 391 transmits (320) , to the first network function 393, a service request to retrieve a digital asset. The service request comprises first authorization information about usage of at least the digital asset. The first NF 393 may be a function or entity in the 5GS, such as API Exposure Function (AEF) . The first requesting entity 391 may include a terminal device or AF which requests the 5GS to retrieve the digital asset. In the use case 1, the first requesting entity may include the first terminal device 110 associated with the first user 101 or an AF on behalf of the first user 101. In the use case 2, the first requesting entity 391 may include the first terminal device 110 or an AF on behalf of the first user 101. In the use case 3, the first requesting entity 110 may include the second terminal device 120 associated with the second user 102 or an AF on behalf of the second user 102.

[0087] In some example embodiments, the digital asset may include a digital representation (e.g., an avatar) , a software license, a gift certificate, a token and the like. In the following, some examples or example embodiments are described with respect to the avatar. However, this is merely an example without limitation. Aspects described with respect to the avatar can be applied to other type of digital assets. Moreover, although singular form is used for “digital asset” , the service request may be related to more than one digital asset.

[0088] The first authorization information may indicate what the first requesting entity 391 requests for authorization. In some example embodiments, the first authorization information may include an identity of the first user owning the digital asset, for example, a subscription identifier or other user identity of the first user. Alternatively, or in addition, the first authorization information may include an identification of the digital asset, for example, an asset ID. Alternatively, or in addition, the first authorization information may include an identity of the second user to use the digital asset, for example, a subscription identifier or other user identity of the second user. Alternatively, or in addition, in some example embodiments, the first authorization information may include information about a service scenario for which the digital asset is to be used, for example, a purpose of retrieving the digital asset, such as “gaming” , “social-media” , “video-calling” . Alternatively, or in addition, the first authorization information may include information about an application function for which the digital asset is to be used, for example, information about the AFs with which the digital asset is to be used. Alternatively, or in addition, the first authorization information may include information about a time period during which the digital asset is to be used, for example, an indication of an intended usage time.

[0089] The first authorization information required in different use cases may be the same or different and will be described in detail later. In the following, authorization information (for example, the first authorization information, the second authorization information to be described below) related to usage of a digital asset may be referred to as asset authorization information, for example avatar authorization information for the avatar or digital representation.

[0090] In some example embodiments, the first authorization information may be carried in the service request directly. Alternatively, or in addition, in some example embodiments, the service request may include an access token, which in turn includes the first authorization information.

[0091] In the example embodiments where the service request includes the access token, the first requesting entity 391 may obtain 305 the access token including the first authorization information from the second NF 395 before transmitting the service request. In some example embodiments, as shown in FIG. 3A, the first requesting entity 391 may transmit (302) , to the second NF 395, an access token request for an asset retrieval service. The second NF 395 may receive (304) the access token request and obtain (305) the first  authorization information about usage at least a digital asset allowed to be used by the first requesting entity 391. After the first authorization information is obtained, the second NF 395 may transmit (316) , to the first requesting entity 391, the access token comprising the first authorization information. The first requesting entity 391 may receive (318) the access token to be comprised in the service request.

[0092] In some example embodiments, the detailed procedure of obtaining (305) the first authorization information may be as follows. The second NF 395 may transmit (306) , to the first NF 393, an authorization request for asset authorization information about the digital asset. The first NF 393 may receive (308) the authorization request and validate (310) it based on allowance information for using the digital asset. The allowance information will be described in detail when it is mentioned in the following text. In some example embodiments, if the validation of the authorization request is successful, the first NF 393 may transmit (312) , to the second NF 395, the first authorization information. Accordingly, the first NF 393 may receive (314) the first authorization information.

[0093] Continue with FIG. 3A. The first NF 393 receives (322) the service request from the first requesting entity 391 and validates (326) the retrieval of the digital asset based on at least the first authorization information.

[0094] In some example embodiments, the first NF 393 may validate the retrieval of the digital asset only based on the first authorization information. For example, in the case that the authorization information is included in the access token, the first NF 393 may validate the retrieval of the digital asset only based on the first authorization information. That is because the first authorization information, in this case, is obtained based on a validation process associated with the allowance information.

[0095] In some example embodiments, the first NF 393 may validate the retrieval of the digital asset based on the first authorization information and allowance information for using the digital asset. For example, in the case that the first authorization information is carried in the service request directly rather than included in the access token, the first NF 393 may further take the allowance information into account to validate the retrieval of the digital asset.

[0096] The allowance information may indicate configuration information or permission related to the use of the digital asset. More specifically, it may indicate the usage permission, usage scope or usage preference of the digital asset. In some example  embodiments, the allowance information may indicate at least one of: a set of users allowed to use the digital asset, a set of application functions for which the digital asset is allowed to be used, one or more service scenarios for which the digital asset is allowed to be used, or preference in using the digital asset.

[0097] As an example, the allowance information may include a parameter allowedUserList to indicate the set of users. For example, the parameter allowedUserList may specify which users are authorized to use the digital asset. The allowance information may include the parameter allowedAFList to indicate a list of application functions that are associated with the digital asset. The allowance information may include the parameter “purpose” to indicate the one or more service scenarios for which the digital asset is allowed to be used. For example, the parameter “purpose” may indicate one or more purposed for which the digital asset can be used. A single application function may provide multiple services, such as gaming, social media, video call, etc. In such cases, the parameter “purpose” may be specified as “gaming”  /  “social-media”  /  “video-calling” . The allowance information may include the parameter “preference information” to indicate preference in using the digital asset. For example, the preference information may indicate a preference scenario or condition of using the digital asset or service. In an example, specific digital assets may be used based on location. In another example, audio-only service may only be used when experiencing low bandwidth.

[0098] The allowance information may be pre-stored in the first network function 393. The allowance information may be specified by a user / owner or an application function or 5GS while creating the digital asset. For example, when storing the digital asset in the 5GS by the user, the application function or 5GS, the one or more parameters in the allowance information may be specified. In a use case where the application function is storing the digital asset, the 5GS may mark the parameter allowedAFList as only that application.

[0099] Some more example embodiments are provided in the case that the first requesting entity 391 is associated with the first user 101 owning the digital asset (e.g., in use case 1 and use case 2) . If an identification of the digital asset is absent in the service request, the first NF 393 may determine (324) the digital asset based on the first authorization information and one or more digital assets of the first user 101. For example, if no avatarId (s) are provided in the service request, the first NF 393 may return a list of allowed avatars associated to the first user 101 based on the first authorization information  received from the first user 101.

[0100] In the example embodiments where the first user 101 is different from the second user 102 to use the digital asset and the first requesting entity 391 is associated with the first user 101 (as in use case 2) , the identity of the second user 102 may be not present in the allowed list. In some example embodiments, if the second user 102 is not comprised in a set of users allowed to use the digital asset, the first NF 393 may apply one of the following strategies. In an example, the first NF 393 may determine that the validation of the retrieval of the digital asset is failed, which means that the first NF 393 may reject the second user 102 to use the digital asset of the first user 101. In another example, the first NF 393 may determine that the validation of the retrieval of the digital asset is successful with addition of the second user 102 to the set of users. For example, the identity of the second user 102 may be added to the parameter allowedUserList. In a further example, the first NF 393 may determine that the validation of the retrieval of the digital asset is successful without addition of the second user 102 to the set of users. For example, the first NF 393 may accept the second user 102 to use the digital asset but may not add the identity of the second user 102 to the parameter allowedUserList. It is to be noted that which strategy is applied may be based on implementation of the first NF 393.

[0101] In the example embodiments where the first user 101 owning the digital asset is different from the second user 102 to use the digital asset and the first requesting entity 391 is associated with the second user 102 (as in use case 3) , the first NF 393 may identify the identity of the first user 101 associated with the digital asset according to the identity of the digital asset. After identifying the associated first user 101, the first NF 393 may determine whether the first authorization information received from the first requesting entity 391 matches with the preconfigured authorization information of the first user 101. If it matches, the first NF 393 may determine the validation is successful. If it does not match, the first NF 393 may reject the service request (e.g., based on operator policy) or further communicate with the first user 101 directly or indirectly to validate the retrieval of the digital asset. In some example embodiments, the first NF 393 may obtain a consent response from the first user 101. The consent response may indicate whether the second user 102 is allowed to use the digital asset.

[0102] In some example embodiments, to obtain the consent response, the first NF 393 may communicate with the second NF 395. For example, the first NF 393 may transmit, to the second NF 395, a consent request for the second user 102 to use the digital asset  and receive, from the second NF 395, the consent response from the first user 101. Then, the first NF 393 may determine the result of the validation based on the consent response. Specifically, if the consent response indicates that the second user 102 is allowed to use the digital asset, the validation is successful. If the consent response indicates that the second user 102 is not allowed to use the digital asset, the validation is failed.

[0103] In some example embodiments, the validation of the retrieval may involve validation of the access token included in the service request. For example, if the first authorization information is included in the access token, the first NF 393 may validate the access token first. If the validation of the access token is successful, the first NF 393 may derive the first authorization information from the access token and validate the retrieval of the digital asset based on the derived first authorization information. Alternatively, only the access token is validated. If the validation of the access token is successful, the first NF 393 may determine that the first authorization information is validated.

[0104] Continue with FIG. 3A. After the validation, the first NF 393 transmits (328) , to the first requesting entity 391, a service response to the service request based on a validation result of the retrieval of the digital asset. Accordingly, the first requesting entity 391 receives (330) the service response.

[0105] In some example embodiments, if the validation is successful, the first NF 393 may obtain a signature at least for the digital asset and second authorization information about usage of the digital asset, and then transmit the service response comprising the digital asset, the second authorization information and the signature. The first NF 393 may generate the signature itself or obtain it from the second NF 395. In an example, the first NF 393 may transmit the digital asset and the second authorization information to the second NF 395 and receive the signature from the second NF 395.

[0106] The second authorization information may indicate what the first NF 393 determine to authorize. In some example embodiment, the second authorization information may include an identity of the first user owning the digital asset, for example, a subscription identifier or other user identity of the first user. Alternatively, or in addition, the second authorization information may include an identification of the digital asset for example, an asset ID. Alternatively, or in addition, the second authorization information may include an identity of a second user allowed to use the digital asset, for example, a  subscription identifier or other user identity of the second user. Alternatively, or in addition, the second authorization information may include information about a service scenario for which the digital asset is allowed to be used, Alternatively, or in addition, the second authorization information may include information about an application function for which the digital asset is allowed to be used, for example, a purpose of “gaming” , “social-media” , “video-calling” . Alternatively, or in addition, the second authorization information may include information about a time period during which the digital asset is allowed to be used, for example, an indication of an allowed usage time. It is to be understood that the second authorization information may be the same as or different from the first authorization information. For example, the requested scenarios included in the first authorization information and the valid scenarios included in the second authorization information may be different.

[0107] In some example embodiments, if the validation is successful, the service response may include an indication of the allowance to use the digital asset. In such example embodiments, the service response may not include the digital asset per se. Instead, the service response may include the identity of the digital asset and / or the second authorization information without the signature for example. For another example, the service response may include the identity of the digital asset, which may implicitly mean that use of digital asset is allowed.

[0108] In some example embodiments, if the first user 101 is different from the second user 102 and the first requesting entity 391 is associated with the first user 101 owning the digital asset (as in use case 2) , the first requesting entity 391 may forward at least a portion of information in the service request to another entity related to the second user 102. For example, the first requesting entity 391 may transmit the digital asset, the second authorization information and the signature to a second requesting entity associated with a second user 102 to use the digital asset.

[0109] The process 319 is generally described above. Use case 1, use case 2 and use case 3 are now described in detail to give more examples of the process 319 above. It is to be understood that in the following description, the avatar is illustrated as an example of the digital asset without any limitation.

[0110] In the use case 1, the first UE (as an example of the first requesting entity 391) may send a service request to the 5GS (as an example of the first NF 393) to retrieve an  avatar. The first UE may specify the first authorization information (comprising avatarId and other avatar authorization information details) in the service request. For example, the first authorization information may include Generic Public Subscription Identifier (GPSI)  / a user identity (e.g., user@domain / user@email. com / Social Security Number, SSN,  / 5GC assigned user identity) of the user (herein the first user 101) who will be using the avatar, a purpose of retrieving the avatar, the intended usage time and information about the AF (s) with which the avatar will be used, etc. The first authorization information may further include the avatar Id (s) for which the avatars are requested. If no avatar ID is provided in the request, the 5GS may return a list of allowed avatars associated to the first user based on the first authorization information received from the first UE. The 5GS may authenticate and authorize the first UE 110 based on the parameters allowedUserList, allowedAFList, purpose and other UE preferences. The 5GS may further generate a signature for the avatar and second authorization information, which includes the GPSI / user identity, purpose, usage time, and application function details. If any parameter of the first authorization information is not received, the 5GS may fill in this parameter according to its available information. After the validation, the 5GS sends the avatar, the second authorization information and the signature to the first UE. Alternatively, the 5GS may send the avatar ID and the second authorization information.

[0111] In the use case 2, if the first user 101 decides to share their associated avatar with the second user 102, the first UE (as an example of the first requesting entity 391) may request the 5GS to retrieve the avatar by providing the first authorization information that specify GPSI / user identity associated to the second UE (as an example of the second requesting entity associated with the second user 102) . The first UE may optionally provide the avatar ID (as part of the first authorization information) in the service request or the 5GS may derive a list of allowed avatar (s) of the first user 101 associated with the avatar authorization information. The 5GS may authenticate and authorize the avatar based on the parameters allowedUserList, allowedAFList, purpose and other preferences of the first UE. If the second user 102 is allowed to use the avatar (s) of the first user 101, the application present in the service request is allowed and other information also matches, it is determined that the authentication and authorization is successful. After successful authentication and authorization, the 5GS may generate a signature at least for both the avatar and the avatar authorization information and send the avatar, the second  authorization information and the signature to the first UE. Then, the first UE may share the avatar, the second authorization information along with the signature to the second UE.If the identity of the second user 102 is not present in the parameter allowedUserList of the avatar, it is up to implementation to reject the request, to add the identity of the second user 102 to the parameter allowedUserList or to provide the service without adding the identity of the second user 102 to the parameter allowedUserList.

[0112] In the use case 3, if the second UE (as an example of the first requesting entity 391) requests retrieval of an avatar associated to the first user 101 from 5GS by providing first authorization information. The first authorization information may include avatar authorization information containing the GPSI / user identity of the second user 102 and avatar details containing the avatar ID. The 5GS identifies the GPSI associated with the owner of the avatar (the first user 101) based on the avatar ID. The 5GS sends a consent request to the first UE or reject the request based on an operator policy if the avatar authorization information received from the second UE does not match with the preconfigured authorization information. If matches, the 5GS may not send the consent request. If consent is required, the 5GS will get the consent from the GPSI associated with the first user 101. Based on the consent response from the first UE, the 5GS provides the avatar, the second authorization information along with the 5GS signature to the second UE.

[0113] The process of the retrieval of the digital asset is described above. Now the process of validating the use of the digital asset is described.

[0114] FIG. 3B illustrates a flow chart of a process 300B for authentication and authorization by an application function according to some example embodiments of the present disclosure. As illustrated in FIG. 3B, the process 300B involves a second requesting entity 392, an AF 394 and the first NF 393. For the purposes of discussion, the process 300B will be discussed with reference to FIG. 1.

[0115] As shown in FIG. 3B, the second requesting entity 392 obtains (332) first information regarding retrieval of the digital asset for using by a second user 102. In some example embodiments, the first information may include the digital asset, the second authorization information about usage of the digital asset, and the signature for the digital asset and the second authorization information. The first information may be obtained from the first NF 393 or the first requesting entity 391 associated with the first user 101.  Specifically, in the example embodiments where the second requesting entity 392 is the first requesting entity 391 (e.g., in the use case 1 and use case 3) , the second requesting entity 392 may receive the first information from the first NF 393 as described above with respect to the process 300B. In the example embodiments where the second requesting entity 392 is different from the first requesting entity 391 (e.g., the use case 2) , the second requesting entity 392 may receive the first information from the first requesting entity 391 associated with the first user 101.

[0116] Then, the second requesting entity 392 transmits (334) , to the AF 394, second information indicating that the digital asset is to be used by the second user. In some example embodiments, the second information may include the digital asset, the second authorization information about usage of the digital asset, and the signature for the digital asset and the second authorization information. In some example embodiments, the second information may include an identity of the digital asset (for example, an avatar ID) and the second authorization information without the signature.

[0117] The AF 394 receives (336) the second information, and validates (338) the use of the digital asset by the second user based on the second information.

[0118] In the example embodiments where the second information includes the digital asset, the second authorization information and the signature, the AF 394 may perform the validation by at least one of the following methods. For example, the AF 394 may verify the signature based on a certificate of the first NF 393. To be more specific, the AF 394 may be preconfigured with a certificate of the first NF 393 as a trust anchor to verify the signature of the first NF 393. For example, the AF 394 may check the second authorization information received for validation. The check may include a series of contents, such as the identification of the digital asset, the identity of the owner and / or the user of the digital asset, usage scenarios, usage time and so on. For example, the AF 394 may authenticate the user identity (such as GPSI) in the second authorization information.

[0119] In the example embodiments where the second information comprises an identification of the digital asset, the process of validating the use of the digital asset may be performed as follows. The AF 394 may transmit (342) , to the first NF 393, a request to validate the use of the digital asset by the second user. The first NF 393 may receive (344) the request and validate (346) the use of the digital asset by the second user. For example, the first NF 393 may validate the use of digital asset against its local database. Then, the  first NF 393 may transmit (348) , to the AF 394, a response indicating whether the second user 102 is allowed to use the digital asset. The AF 394 may receive (350) the response from the first NF 393, and generate a validation result of use of the digital asset.

[0120] Then, the AF 394 may transmit (352) , to the second requesting entity 392, a validation result of the use of the digital asset by the second user. Accordingly, the second requesting entity 392 may receive (354) the validation result. If the result is successful, the second requesting entity 392 may use the digital asset. If the result indicates failure, the second requesting entity 392 may be prohibited from using the digital asset.

[0121] The process 300B is generally described above. Now continue with the use case 1, use case 2 and use case 3 to describe the process 300B in detail. It is to be understood that in the following description, the avatar is illustrated as an example of the digital asset without any limitation.

[0122] In the use case 1, the first UE logins to an application function with any username (such as an email, a mobile number, an anonymous username, etc. ) . After successful login, the first UE presents the avatar, the second authorization information and the 5GS signature to the AF. The AF is preconfigured with the 5GS certificate as a trust anchor to verify the 5GS signature. Then, the AF validates the 5GS signature. Upon successful signature validation, it also checks the second authorization information, including a usage time, purpose and etc. Once these validations are confirmed, the AF (as a third party) sends a One-Time Password (OTP) , a link associated with the AF, or employs another identity verification method to authenticate the GPSI / user identity present in the second authorization information. Upon successful authentication (OTP / link / identity confirmation verification from user of the GPSI / user identity) and authorization, the AF ensures that the avatar is used by a legitimate or valid user and allows the avatar to be used in the AF. In this way, even if the avatar is available to another user (such as the third user) , the third user’s usage of the avatar is restricted by AF as the third user cannot authenticate itself as identity verification fails.

[0123] In the use case 2, after successful login to the AF, the second user 102 may present the avatar, the second authorization information along with the 5GS signature to the AF. The AF validates the 5GS signature. Upon successful signature validation, it also checks the second authorization information, including usage time, purpose and etc. Once these validations are confirmed, the third party sends an OTP, a link associated with the AF, or  employs another identity verification method to authenticate the GPSI / user identity present in the avatar authorization information. Upon successful authentication (OTP / link / identity confirmation verification from user of the GPSI / user identity) and authorization, the AF ensures the avatar is used by a legitimate or valid user and allows the avatar to be used in the AF. In this way, even if the avatar is available to another user (such as the third user with GSPI3) , the third user’s usage of avatar is restricted by the AF as the third user cannot authenticate itself by providing the OTP / link sent to GPSI / user identity of the second authorization information.

[0124] In the use case 3, after successful login to the AF, the second user 102 may present the avatar, the second authorization information along with the 5GS signature to the AF. Then the AF validates the 5GS signature. Upon successful signature validation, it also checks the second authorization information, including a usage time, purpose and etc. Once these validations are confirmed, the AF sends an OTP, a link associated with the AF, or employs another identity verification method to authenticate the GPSI / user identity present in the second authorization information. Upon successful authentication (OTP / link / identity confirmation verification from user of the GPSI / user identity) and authorization, the AF ensures that the avatar is used by a legitimate or valid user and allows the avatar to be used in the AF. In this way, even if the avatar is available to another user (such as the third user with GSPI3) , the third user’s usage of avatar is restricted by the AF as the third user cannot authenticate itself by providing OTP / link sent to GPSI / user identity of the second authorization information.

[0125] In some example embodiments, for all the three use cases above, 5G CAPIF framework may be used. If the CAPIF framework is utilized, the SEAL server or metaverse server functions as a 5G system storing digital assets (such as avatars and digital representations) , and acts as the API Exposure Function (AEF) . The AEF exposes Create Retrieve Update Delete (CRUD) of digital asset operations to API Invoker via CCF. In such example embodiments, the first NF 393 may be the AEF, and the second NF 395 may be the CCF.

[0126] The UE through an API Invoker (application function) or an application function (a network API Invoker) , performs CRUD operations of digital assets on the AEF, following authorization from the CCF. The 5GS signature on asset authorization information (here refers to the second authorization information) may be provided by either the CCF or the AEF.

[0127] The CCF handles the authorization of the API Invoker for accessing the asset service (such as avatar service) , while the AEF manages authorization for retrieving / updating specific avatar (s) based on the fine-grained authorization policies, such as the parameters allowedUserList, allowedAFList, purpose and other preferences associated with the digital asset. If the AEF decides to get user consent, the AEF triggers the CCF to get consent from the owner of the digital asset. If the owner is a mobile user, the CCF, after getting consent via resource owner function (ROF) from UE, forwards the consent response to the AEF. If the owner is an organization, the CCF may get consent through Uniform Resource Locator (URL) published by the organization.

[0128] To better understand the solution of the present disclosure, some more examples are described below with reference to the CAPIF framework. In the following examples, the avatar is used as an example of the digital asset merely for purpose of illustration without any limitation.

[0129] FIG. 4 illustrates a flow chart of an example process 400 for authentication and authorization of avatar retrieval in the use case 1 according to some example embodiments. As illustrated in FIG. 4, the process 400 involves an API Invoker 491 on a UE, a CCF 495, AEF 493 (implemented by a SEAL Server) and an AF 494. The process 400 may be considered as an example of the process 300A and process 300B. In the example, the API Invoker 491 may be considered as an example of the first requesting entity 391 and the second requesting entity 392; the CCF 495 may be considered as an example of the second NF 395; the AEF 493 may be considered as an example of the first NF 393; and the AF 494 may be considered as an example of the AF 394.

[0130] As shown in FIG. 4, at 401, the UE, AF, or 5GS may store the avatars along with the allowance information in the AEF 493 or the SEAL server. The allowance information may include the associated parameters allowedUserList, allowedAFList, purpose and preferences, as described above. Each avatar may be assigned a unique avatar ID by SEAL server or the AEF 493. At 402, the API Invoker 491 (on the UE) may be onboarded successfully and CAPIF-1E authentication is performed with the CCF 495.

[0131] At 403, the API Invoker 491 may send an access token request to the CCF 495 for avatar retrieval service. In the access token request, client_Id=API Invoker ID, scope=3gpp#aef1: avatar-retrieval-service, etc. At 404, the CCF 495 may check if an ID of the API Invoker 491 is allowed to perform avatar retrieval service operation and grants  an access token if the API invoker 491 is allowed. At 405, the CCF 495 may send the access token to the API Invoker 491.

[0132] At 406, the API Invoker 491 may send a service request for the retrieval of an avatar to the AEF 493. The service request may include an avatar ID, avatar authorization information (which is an example of the first authorization information, such as GPSI / user identity, a usage time, purpose, target application function details) and the access token.

[0133] At 407, the AEF 493 validates the avatar authorization information with allowance information for example, the parameters allowAFList, purpose, allowedUserList, preferences. In case of successful validation, the AEF 493 may generate a signature on the avatar and avatar authorization information (which is an example of the second authorization information and may be the same or different from the avatar authorization information in the service request) . The signature may be also referred to as a 5GS signature. The AEF 493 may generate the signature. Alternatively, the AEF 493 may pass the avatar, the avatar authorization information to the CCF 495 and get the signature from the CCF 495.

[0134] At 408, the AEF 493 may send the service response to the API Invoker 491. The service response may include the avatar, the avatar authorization information, and the 5GS signature.

[0135] At 409, the 5GS (AEF / CCF) certificate is configured as trust anchor in the AF 494 to valid the 5GS certificate presented by the API Invoker 491. At 410, the API Invoker 491 successfully logins to the AF 494 for example using an email ID  / mobile number / some anonymous username.

[0136] At 411, the API Invoker 491 presents the avatar, avatar authorization information and 5GS signature to the AF 494. At 412, the AF 494 verifies the 5GS signature, and if valid, the AF 494 checks if the avatar authorization information is valid.

[0137] Upon successful validation, the AF 494 gets the GPSI / user identity from the avatar authorization information and triggers OTP / link / any identity verification method. Based on authentication of the GPSI / user identity, the AF 494 may allow the avatar in the AF 494. At 413, the AF 494 returns success / failure to the API Invoker 491 based on the avatar validation.

[0138] FIG. 5 illustrates a flow chart of an example process 500 for authentication and  authorization of avatar retrieval in the use case 2 according to some example embodiments. As illustrated in FIG. 5, the process 500 involves a first API Invoker 591 (on the first UE) , a second API Invoker 592 (on the second UE) , a CCF 595, an AEF 593 (implemented by a SEAL Server) and an AF 594. The process 500 may be considered as an example of the process 300A and process 300B. In the example, the first API Invoker 591 may be considered as an example of the first requesting entity 391; the second API Invoker 592 may be considered as an example of the second requesting entity 392; the CCF 595 may be considered as an example of the second NF 395; the AEF 593 may be considered as an example of the first NF 393; and the AF 594 may be considered as an example of the AF 394. In the example, the first user and the second user are users of the first UE and the second UE.

[0139] As shown in FIG. 5, at 501, the UE, AF, or 5GS may store the avatars along with the allowance information in the AEF 593 or the SEAL server. The allowance information may include the associated parameters allowedUserList, allowedAFList, purpose and preferences, as described above. Each avatar may be assigned a unique avatar ID by SEAL server.

[0140] At 502, the first API Invoker 591 may be onboarded successfully and CAPIF-1E authentication is performed with the CCF 595. At 503, the first API Invoker 591 may send an access token request to the CCF 595 for avatar retrieval service. In the access token request, client_Id=API Invoker ID, scope=3gpp#aef1: avatar-retrieval-service, etc.

[0141] At 504, the CCF 595 may check if an ID of the first API Invoker 591 is allowed to perform avatar retrieval service operation and grant an access token if the first API Invoker 591 is allowed. At 505, the CCF 595 may send the access token to the first API Invoker 591.

[0142] At 506, the first API Invoker 591 may send a service request for the retrieval of an avatar to the AEF 593. The service request may include an avatar ID, avatar authorization information (which is an example of the first authorization information, such as GPSI / identity of the second user, a usage time, purpose, target application function details) and the access token.

[0143] At 507, the AEF 593 validates the avatar authorization information with the allowance information for example, the parameters allowAFList, purpose, allowedUserList, preferences. In case of successful validation, the AEF 593 may generate  a signature on the avatar and avatar authorization information (which is an example of the second authorization information and may be the same or different from the avatar authorization information in the service request) . The signature may be also referred to as a 5GS signature. The AEF 593 may generate the signature. Alternatively, the AEF 593 may pass the avatar, the avatar authorization information to the CCF 595 and get the signature from the CCF 595.

[0144] At 508, the AEF 593 may send the service response to the first API Invoker 591. The service response may include the avatar, the avatar authorization information, and the 5GS signature. At 509, the first API Invoker 591 may provide the retrieved avatar, avatar authorization information and the 5GS signature to the second API Invoker 592.

[0145] At 510, the 5GS (AEF / CCF) certificate is configured as trust anchor in the AF 594 to valid the 5GS certificate presented by API Invokers. At 511, the second API Invoker 592 (for example, the second user) successfully logins to the AF 594 for example using an email ID / mobile number / some anonymous username.

[0146] At 512, the second API Invoker 592 (for example, the second user) presents the avatar, avatar authorization information and the 5GS signature to the AF 594. At 513, the AF 594 verifies the 5GS signature, and if valid, the AF 594 checks if the avatar authorization information is valid.

[0147] Upon successful validation, the AF 594 gets the GPSI / the identity of the second user from avatar authorization information and triggers OTP / link / any identity verification method. Based on authentication of the GPSI / the identity of the second user, the AF 594 may allow the usage of the avatar in the AF 594. At 514, the AF 594 returns success / failure to the second API Invoker 592 based on the avatar validation.

[0148] FIG. 6 illustrates a flow chart of an example process 600 for authentication and authorization of avatar retrieval in the use case 3 according to some example embodiments. As illustrated in FIG. 6, the process 600 involves a first API Invoker 692 (on the first UE) , a CCF 695, an AEF 693 (implemented by a SEAL Server) and a second API Invoker 691 (on the second UE) . The process 600 may be considered as an example of the process 300A. In the example, the first API Invoker 692 may be considered as an example of the second requesting entity 392; the CCF 695 may be considered as an example of the second NF 395; the AEF 693 may be considered as an example of the first NF 393; and the second API Invoker 691 may be considered as an example of the first requesting entity 391.

[0149] As shown in FIG. 6, at 601, the UE, AF, or 5GS may store the avatars along with the allowance information in the AEF 693 or the SEAL server. The allowance information may include the associated parameters allowedUserList, allowedAFList, purpose and preferences, as described above. Each avatar may be assigned a unique avatar ID by the SEAL server. In this use case, the avatar ID is linked to the user identifier (such as the GPSI) associated with the first UE.

[0150] At 602, the second API Invoker 691 (on the second UE) is onboarded successfully and CAPIF-1E authentication is performed with the CCF 695. At 603, the second API Invoker 691 may send an access token request to the CCF 695 for avatar retrieval service. In the access token request, client_Id=API Invoker ID, scope=3gpp#aef1: avatar-retrieval-service, etc.

[0151] At 604, the CCF 695 may check if an ID of the second API Invoker 691 is allowed to perform avatar retrieval service operation and grant an access token if the second API Invoker 691 is allowed. At 605, the CCF 695 may send the access token to the second API Invoker 691. At 606, CAPIF-2E authentication is performed between the second API Invoker 691 and the AEF 693.

[0152] At 607, the second API Invoker 691 may send a service request for the retrieval of an avatar to the AEF 693. The service request may include an avatar ID, avatar authorization information (which is an example of the first authorization information, such as GPSI / identity of the second user, a usage time, purpose, target application function details) and the access token. The GPSI / user identity is the GPSI associated with the second user.

[0153] At 608, the AEF 693 validates the avatar authorization information with the allowance information for example, the parameters allowAFList, purpose, allowedUserList, preferences for the avatar ID provided and retrieves GPSI associated with the avatar ID.

[0154] If the second API Invoker 691 / GPSI / identity of the second user is not present in the allowedUserList or application details are not present in allowedAFList, the AEF 693 may reject the service request based on operator policy. Alternatively, the AEF 693 may get a consent from the first user.

[0155] As shown in FIG. 6, at 609, the AEF 693 may request the CCF 695 to get the  consent from the first user of the first UE by providing the avatar ID and the avatar authorization information.

[0156] At 610, the CCF 695 may transmit a consent request to the first API Invoker 692. At 611, the first API Invoker 692 may transmit a consent response to the CCF 695. At 610 and 611, the CCF 695 may get the consent from the first user of the first UE via ROF.

[0157] At 612, the CCF 695 forwards the consent response to the AEF 693. At 613, based on the consent response, the AEF 693 generates a signature on the avatar and the avatar authorization information or asks the CCF 695 to provide a signature on the avatar and the avatar authorization information.

[0158] At 614, the AEF 693 sends the service response, the avatar authorization information and the 5GS signature to the second API Invoker 691. At 615, the API Invoker authentication and avatar authorization may be performed with the AF, which may follow the same procedure mentioned in FIG. 4 for the use case 1 and in FIG. 5 for the use case 2.

[0159] As described above, in some example embodiments, the service request may not include the digital asset and the signature and instead may include the identity of the digital asset and / or the asset authorization information. Reference is now made to FIG. 7 to illustrate such an example.

[0160] FIG. 7 illustrates a flow chart of another example process 700 for authentication and authorization of avatar retrieval according to some example embodiments. As illustrated in FIG. 7, the process 700 involves an API Invoker 791 on a UE, a CCF 795, AEF 793 (implemented by a SEAL Server) and an AF 794. The process 700 may be considered as an example of the process 300A and process 300B. In the example, the API Invoker 791 may be considered as an example of the first requesting entity 391 and the second requesting entity 392; the CCF 795 may be considered as an example of the second NF 395; the AEF 793 may be considered as an example of the first NF 393; and the AF 794 may be considered as an example of the AF 394.

[0161] As shown in FIG. 7, at 701, the UE, AF, or 5GS may store the avatars along with the allowance information in the AEF 793 or the SEAL server. The allowance information may include the associated parameters allowedUserList, allowedAFList, purpose and preferences, as described above. Each avatar may be assigned a unique avatar ID by SEAL  server or the AEF 793. At 702, the API Invoker 791 (on the UE) may be onboarded successfully and CAPIF-1E authentication is performed with the CCF 795.

[0162] At 703, the API Invoker 791 may send an access token request to the CCF 795 for avatar retrieval service. In the access token request, client_Id=API Invoker ID, scope=3gpp#aef1: avatar-retrieval-service, etc. At 704, the CCF 795 may check if an ID of the API Invoker 791 is allowed to perform avatar retrieval service operation and grants an access token if the API invoker 791 is allowed. At 705, the CCF 795 may send the access token to the API Invoker 791.

[0163] At 706, the API Invoker 791 may send a service request for the retrieval of an avatar to the AEF 793. The service request may include an avatar ID, avatar authorization information (which is an example of the first authorization information, such as GPSI / user identity, a usage time, purpose, target application function details) and the access token.

[0164] At 707, the AEF 793 validates the avatar authorization information with allowance information for example, the parameters allowAFList, purpose, allowedUserList, preferences. In case of successful validation, the AEF 793 may store the agreed avatar authorization information against the avatar ID for example, in its local database. At 708, the AEF 793 may send the service response to the API Invoker 791. The service response may include the avatar ID and the avatar authorization information.

[0165] At 709, the details of reaching the AEF 792 are known at the AF 794. At 710, the API Invoker 791 successfully logins to the AF 794 for example using an email ID  / mobile number / some anonymous username.

[0166] At 711, the API Invoker 491 presents the avatar ID and the avatar authorization information to the AF 794. At 712, the AF 794 may request the AEF 793 to verify the avatar authorization information. At 713, the AEF 793 may verify the avatar authorization information against its local database. At 714, the AEF 793 may respond the AF 794 with verification success or failure.

[0167] At 715, upon successful validation, the AF 794 may get the GPSI / user identity from the avatar authorization information and triggers OTP / link / any identity verification method. Based on authentication of the GPSI / user identity, the AF 794 may allow the avatar in the AF 794. At 716, the AF 494 returns success / failure to the API Invoker 491 based on the avatar validation.

[0168] As described above, in some example embodiments, the service request may include an access token including the asset authorization information. Reference is now made to FIG. 8 to illustrate such an example.

[0169] FIG. 8 illustrates a flow chart of a further example process 800 for authentication and authorization of avatar retrieval according to some example embodiments. As illustrated in FIG. 8, the process 800 involves an API Invoker 891 on a UE, a CCF 895, and an AEF 893 (implemented by a SEAL Server) . The process 800 may be considered as an example of the process 300A. In the example, the API Invoker 891 may be considered as an example of the first requesting entity 391 and optionally the second requesting entity 392; the CCF 895 may be considered as an example of the second NF 395; and the AEF 893 may be considered as an example of the first NF 393. In this example, the API invoker 891 may be a terminal device associated with a first user owning the avatar, a terminal device associated with a second user to use the avatar, or an AF.

[0170] As shown in FIG. 8, at 801, the UE, AF, or 5GS may store the avatars along with the allowance information in the AEF 893 or the SEAL server. The allowance information may include the associated parameters allowedUserList, allowedAFList, purpose and preferences, as described above. Each avatar may be assigned a unique avatar ID by the SEAL server or the AEF 893. At 802, the API Invoker 891 (on the UE) may be onboarded successfully and CAPIF-1E authentication is performed with the CCF 895.

[0171] At 803, the API Invoker 891 may send an access token request to the CCF 895 for avatar retrieval service. In the access token request, client_Id=API Invoker ID, scope=3gpp#aef1: avatar-retrieval-service, etc. At 804, the CCF 895 may check if an ID of the API Invoker 891 is allowed to perform avatar retrieval service operation. At 805, the CCF 895 may request the AEF 895 to get avatar authorization for one or more avatars. The request from the CCF 895 may include for example, an avatar ID, GPSI, a usage time, a purpose, application function details, etc.

[0172] At 806, the AEF 895 may validate the information in the request with the allowance information, for example, the parameters allowAFList, purpose, allowedUserList, preferences. In case of successful validation, at 807, the AEF 893 may respond the CCF 895 with avatar authorization information. Upon receiving the avatar authorization information, the CCD 895 may generate an access token which includes the avatar authorization information.

[0173] At 809, the CCF 895 may send the access token including the avatar authorization information to the API Invoker 891. Then, CAPIF-2E authentication is performed between the API Invoker 891 and AEF 895.

[0174] At 810, the API Invoker 891 may send a service request for the retrieval of an avatar to the AEF 893. The service request may include the access token including the avatar authorization information. At 811, the AEF 493 validates the access token. For example, the AEF 493 may verify the access token first and if the access token is verified, the avatar authorization information in the access token is verified. At 812, the AEF 893 may send the service response to the API Invoker 891. The service response may include information about the avatar, for example, the avatar ID and other related information.

[0175] The example described with reference to FIG. 8 is aligned with existing CAPIF security framework and also can address security concern on Service and System Aspects Working Group 6 (SA6) use cases.

[0176] FIG. 9 shows a flowchart of an example method 900 implemented at a first apparatus in accordance with some example embodiments of the present disclosure.

[0177] At block 910, the first apparatus transmits, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset.

[0178] At block 920, the first apparatus receives, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.

[0179] In some example embodiments, the validation result is based on the first authorization information and allowance information for using the digital asset, and the allowance information indicates at least one of: a set of users allowed to use the digital asset, a set of application functions for which the digital asset is allowed to be used, one or more service scenarios for which the digital asset is allowed to be used, or preference in using the digital asset.

[0180] In some example embodiments, the first authorization information comprises at least one of: an identity of a first user owning the digital asset, an identification of the digital asset, an identity of a second user to use the digital asset, information about a service scenario for which the digital asset is to be used, information about an application  function for which the digital asset is to be used, or information about a time period during which the digital asset is to be used.

[0181] In some example embodiments, the service response comprises the digital asset, second authorization information about usage of the digital asset, and a signature at least for the digital asset and the second authorization information.

[0182] In some example embodiments, the second authorization information comprises at least one of: an identity of a first user owning the digital asset, an identification of the digital asset, an identity of a second user allowed to use the digital asset, information about a service scenario for which the digital asset is allowed to be used, information about an application function for which the digital asset is allowed to be used, or information about a time period during which the digital asset is allowed to be used.

[0183] In some example embodiments, the first user is different from the second user, the first requesting entity is associated with a first user owning the digital asset, and the first apparatus is may further transmit the digital asset, the second authorization information and the signature to a second requesting entity associated with a second user to use the digital asset.

[0184] In some example embodiments, the method 900 further comprises: transmitting, to a second network function, an access token request for an asset retrieval service; and receiving, from the second network function, an access token comprising the first authorization information.

[0185] In some example embodiments, the service request comprises the access token, the access token comprises the first authorization information, and the service response comprises information of the digital asset.

[0186] FIG. 10 shows a flowchart of an example method 1000 implemented at a second apparatus in accordance with some example embodiments of the present disclosure.

[0187] At block 1010, the second apparatus obtains first information regarding retrieval of a digital asset for using by a second user.

[0188] At block 1020, the second apparatus transmits, to an application function, second information indicating that the digital asset is to be used by the second user.

[0189] At block 1030, the second apparatus receives, from the application function, a  validation result of the use of the digital asset by the second user.

[0190] In some example embodiments, the first information and the second information comprise: the digital asset, second authorization information about usage of the digital asset, and a signature for the digital asset and the second authorization information.

[0191] In some example embodiments, obtaining the first information comprises: receiving the first information from a first network function.

[0192] In some example embodiments, a first user owning the digital asset is different from the second user, the second apparatus comprises or is comprised in a second requesting entity associated with the second user, and obtaining the first information comprises: receiving the first information from a first requesting entity associated with the first user.

[0193] FIG. 11 shows a flowchart of an example method 1100 implemented at a third apparatus in accordance with some example embodiments of the present disclosure.

[0194] At block 1110, the third apparatus receives, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset.

[0195] At block 1120, the third apparatus validates the retrieval of the digital asset based on at least the first authorization information.

[0196] At block 1130, the third apparatus transmits, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.

[0197] In some example embodiments, validating the retrieval of the digital asset comprises: validating the retrieval of the digital asset based on the first authorization information and allowance information for using the digital asset.

[0198] In some example embodiments, the allowance information indicates at least one of:a set of users allowed to use the digital asset, a set of application functions for which the digital asset is allowed to be used, one or more service scenarios for which the digital asset is allowed to be used, or preference in using the digital asset.

[0199] In some example embodiments, the first authorization information comprises at least one of: an identity of a first user owning the digital asset, an identification of the  digital asset, an identity of a second user to use the digital asset, information about a service scenario for which the digital asset is to be used, information about an application function for which the digital asset is to be used, or information about a time period during which the digital asset is to be used.

[0200] In some example embodiments, the method 1100 further comprises: in accordance with a determination that an identification of the digital asset is absent in the service request, determining the digital asset based on the first authorization information and one or more digital assets of the first user.

[0201] In some example embodiments, transmitting the service response to the first requesting entity comprises: in accordance with a determination that the validation is successful, obtaining a signature for the digital asset and second authorization information about usage of the digital asset; and transmitting, to the first requesting entity, the service response comprising the digital asset, the second authorization information and the signature.

[0202] In some example embodiments, the third apparatus comprises or is comprised in a first network function, and obtaining the signature comprises: transmitting the digital asset and the second authorization information to a second network function; and receiving the signature from the second network function.

[0203] In some example embodiments, the second authorization information comprises at least one of: an identity of a first user owning the digital asset, an identification of the digital asset, an identity of a second user allowed to use the digital asset, information about a service scenario for which the digital asset is allowed to be used, information about an application function for which the digital asset is allowed to be used, or information about a time period during which the digital asset is allowed to be used.

[0204] In some example embodiments, transmitting the service response to the first requesting entity comprises: in accordance with a determination that the validation is successful, transmitting, to the first requesting entity, the service response indicating allowance to use the digital asset.

[0205] In some example embodiments, a first user owning the digital asset is different from a second user to use the digital asset, the first requesting entity is associated with the first user, and validating the retrieval of the digital asset comprises: in accordance  with a determination that the second user is not comprised in a set of users allowed to use the digital asset, performing one of: determining that the validation of the retrieval of the digital asset is failed, determining that the validation of the retrieval of the digital asset is successful with addition of the second user to the set of users, or determining that the validation of the retrieval of the digital asset is successful without addition of the second user to the set of users.

[0206] In some example embodiments, a first user owning the digital asset is different from a second user to use the digital asset, the first requesting entity is associated with the second user, and validating the retrieval of the digital asset comprises: obtaining a consent response from the first user, the consent response indicating whether the second user is allowed to use the digital asset; and determining the result of the validation based on the consent response.

[0207] In some example embodiments, the third apparatus comprises or is comprised in a first network function, and obtaining the consent response from the first user comprises: transmitting, to a second network function, a consent request for the second user to use the digital asset; and receiving, from the second network function, the consent response from the first user.

[0208] In some example embodiments, the method 1100 further comprises: receiving, from an application function, a request to validate the use of the digital asset by a second user; and transmitting, to the application function based on the result of the validation, a response indicating whether the second user is allowed to use the digital asset.

[0209] In some example embodiments, the service request comprises an access token for asset retrieval service, the access token comprises the first authorization information, and validating the retrieval of the digital asset comprises: in accordance with a successful validation of the access token, deriving the first authorization information from the access token; and validating the retrieval of the digital asset based on the derived first authorization information.

[0210] In some example embodiments, the method 1100 further comprises: receiving, from a second network function, an authorization request for asset authorization information about the digital asset; validating the authorization request based on allowance information for using the digital asset; and in accordance with a successful validation of the authorization request, transmitting to the second network function, the  first authorization information.

[0211] In some example embodiments, the service response comprises information of the digital asset.

[0212] FIG. 12 shows a flowchart of an example method 1200 implemented at a fourth apparatus in accordance with some example embodiments of the present disclosure.

[0213] At block 1210, the fourth apparatus receives, from a second requesting entity, second information indicating that a digital asset is to be used by a second user.

[0214] At block 1220, the fourth apparatus validates the use of the digital asset by the second user based on the second information.

[0215] At block 1230, the fourth apparatus transmits, to the second requesting entity, a validation result of the use of the digital asset by the second user.

[0216] In some example embodiments, the second information comprises the digital asset, second authorization information about usage of the digital asset, and a signature for the digital asset and the second authorization information, and validating the use of the digital asset by the second user comprises at least one of: verifying the signature based on a certificate of a first network function, checking the second authorization information, or authenticating a user identity in the second authorization information.

[0217] In some example embodiments, the second information comprises an identification of the digital asset, and validating the use of the digital asset by the second user comprises : transmit, to a first network function, a request to validate the use of the digital asset by the second user; and receiving, from the first network function, a response indicating whether the second user is allowed to use the digital asset.

[0218] FIG. 13 shows a flowchart of an example method 1300 implemented at a fifth apparatus in accordance with some example embodiments of the present disclosure.

[0219] At block 1310, the fifth apparatus receives, from a first requesting entity, an access token request for an asset retrieval service.

[0220] At block 1320, the fifth apparatus obtains first authorization information about usage at least a digital asset allowed to be used by the first requesting entity.

[0221] At block 1330, the fifth apparatus transmits, to the first requesting entity, an access token comprising the first authorization information.

[0222] In some example embodiments, the fifth apparatus comprises or is comprised in a second network function, and obtaining the first authorization information comprises : transmitting, to a first network function, an authorization request for asset authorization information about the digital asset; and receiving the first authorization information from the first network function.

[0223] In some example embodiments, a first apparatus capable of performing any of the method 900may comprise means for performing the respective operations of the method 900 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the first requesting entity 391.

[0224] In some example embodiments, a second apparatus capable of performing any of the method 1000 may comprise means for performing the respective operations of the method 1000 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the second requesting entity 392.

[0225] In some example embodiments, a third apparatus capable of performing any of the method 1100 may comprise means for performing the respective operations of the method 1100 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The third apparatus may be implemented as or included in the first NF 393.

[0226] In some example embodiments, a fourth apparatus capable of performing any of the method 1200 may comprise means for performing the respective operations of the method 1200 and / or any of the described one or more example embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The fourth apparatus may be implemented as or included in the AF 394.

[0227] In some example embodiments, a fifth apparatus capable of performing any of the method 1300 may comprise means for performing the respective operations of the method 1300 and / or any of the described one or more example embodiments thereof. The means  may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The fifth apparatus may be implemented as or included in the second NF 395.

[0228] FIG. 14 is a simplified block diagram of a device 1400 that is suitable for implementing example embodiments of the present disclosure. The device 1400 may be provided to implement a communication device, function, or entity, for example, those described with reference to FIG. 1 to FIG. 8. As shown, the device 1400 includes one or more processors 1410, one or more memories 1420 coupled to the processor 1410, and one or more communication modules 1440 coupled to the processor 1410.

[0229] The communication module 1440 is for bidirectional communications. The communication module 1440 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 1440 may include at least one antenna.

[0230] The processor 1410 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1400 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0231] The memory 1420 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1424, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 1422 and other volatile memories that will not last in the power-down duration.

[0232] A computer program 1430 includes computer executable instructions that are executed by the associated processor 1410. The instructions of the program 1430 may include instructions for performing operations / acts of some example embodiments of the  present disclosure. The program 1430 may be stored in the memory, e.g., the ROM 1424. The processor 1410 may perform any suitable actions and processing by loading the program 1430 into the RAM 1422.

[0233] The example embodiments of the present disclosure may be implemented by means of the program 1430 so that the device 1400 may perform any process of the disclosure as discussed with reference to FIG. 3 to FIG. 13. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0234] In some example embodiments, the program 1430 may be tangibly contained in a computer readable medium which may be included in the device 1400 (such as in the memory 1420) or other storage devices that are accessible by the device 1400. The device 1400 may load the program 1430 from the computer readable medium to the RAM 1422 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0235] FIG. 15 shows an example of the computer readable medium 1500 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1500 has the program 1430 stored thereon.

[0236] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0237] Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non- transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0238] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0239] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0240] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0241] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

[0242] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A first apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to:transmit, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; andreceive, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.2.The first apparatus of claim 1, wherein the validation result is based on the first authorization information and allowance information for using the digital asset, and the allowance information indicates at least one of:a set of users allowed to use the digital asset,a set of application functions for which the digital asset is allowed to be used,one or more service scenarios for which the digital asset is allowed to be used, orpreference in using the digital asset.3.The first apparatus of claim 1, wherein the first authorization information comprises at least one of:an identity of a first user owning the digital asset,an identification of the digital asset,an identity of a second user to use the digital asset,information about a service scenario for which the digital asset is to be used,information about an application function for which the digital asset is to be used, orinformation about a time period during which the digital asset is to be used.4.The first apparatus of claim 1, wherein the service response comprises the digital asset, second authorization information about usage of the digital asset, and a signature at least for the digital asset and the second authorization information.5.The first apparatus of claim 4, wherein the second authorization information comprises at least one of:an identity of a first user owning the digital asset,an identification of the digital asset,an identity of a second user allowed to use the digital asset,information about a service scenario for which the digital asset is allowed to be used,information about an application function for which the digital asset is allowed to be used, orinformation about a time period during which the digital asset is allowed to be used.6.The first apparatus of claim 4, wherein the first user is different from the second user, the first requesting entity is associated with a first user owning the digital asset, and the first apparatus is further caused:transmit the digital asset, the second authorization information and the signature to a second requesting entity associated with a second user to use the digital asset.7.The first apparatus of claim 1, wherein the first apparatus is further caused to:transmit, to a second network function, an access token request for an asset retrieval service; andreceive, from the second network function, an access token comprising the first authorization information.8.The first apparatus of claim 1, wherein the service request comprises the access token, the access token comprises the first authorization information, and the service response comprises information of the digital asset.9.A second apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the second apparatus at least to:obtain first information regarding retrieval of a digital asset for using by a second user;transmit, to an application function, second information indicating that the digital asset is to be used by the second user; andreceive, from the application function, a validation result of the use of the digital asset by the second user.10.The second apparatus of claim 9, wherein the first information and the second information comprise: the digital asset, second authorization information about usage of the digital asset, and a signature for the digital asset and the second authorization information.11.The second apparatus of claim 9, wherein the second apparatus is caused to obtain the first information by:receiving the first information from a first network function.12.The second apparatus of claim 9, wherein a first user owning the digital asset is different from the second user, the second apparatus comprises or is comprised in a second requesting entity associated with the second user, and the second apparatus is caused to obtain the first information by:receiving the first information from a first requesting entity associated with the first user.13.A third apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the third apparatus at least to:receive, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset;validate the retrieval of the digital asset based on at least the first authorization information; andtransmit, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.14.The third apparatus of claim 13, wherein the third apparatus is caused to validate the retrieval of the digital asset by:validate the retrieval of the digital asset based on the first authorization information and allowance information for using the digital asset.15.The third apparatus of claim 14, wherein the allowance information indicates at least one of:a set of users allowed to use the digital asset,a set of application functions for which the digital asset is allowed to be used,one or more service scenarios for which the digital asset is allowed to be used, orpreference in using the digital asset.16.The third apparatus of claim 13, wherein the first authorization information comprises at least one of:an identity of a first user owning the digital asset,an identification of the digital asset,an identity of a second user to use the digital asset,information about a service scenario for which the digital asset is to be used,information about an application function for which the digital asset is to be used, orinformation about a time period during which the digital asset is to be used.17.The third apparatus of claim 13, wherein the first requesting entity is associated with a first user owning the digital asset and the third apparatus is further caused to:in accordance with a determination that an identification of the digital asset is absent in the service request, determine the digital asset based on the first authorization information and one or more digital assets of the first user.18.The third apparatus of claim 13, wherein the third apparatus is caused to transmit the service response to the first requesting entity by:in accordance with a determination that the validation is successful, obtaining a signature for the digital asset and second authorization information about usage of the digital asset; andtransmitting, to the first requesting entity, the service response comprising the digital asset, the second authorization information and the signature.19.The third apparatus of claim 18, wherein the third apparatus comprises or is comprised in a first network function, and the third apparatus is caused to obtain the signature by:transmitting the digital asset and the second authorization information to a second network function; andreceiving the signature from the second network function.20.The third apparatus of claim 18, wherein the second authorization information comprises at least one of:an identity of a first user owning the digital asset,an identification of the digital asset,an identity of a second user allowed to use the digital asset,information about a service scenario for which the digital asset is allowed to be used,information about an application function for which the digital asset is allowed to be used, orinformation about a time period during which the digital asset is allowed to be used.21.The third apparatus of claim 13, wherein the third apparatus is caused to transmit the service response to the first requesting entity by:in accordance with a determination that the validation is successful, transmitting, to the first requesting entity, the service response indicating allowance to use the digital asset.22.The third apparatus of claim 13, wherein a first user owning the digital asset is different from a second user to use the digital asset, the first requesting entity is associated with the first user, and the third apparatus is caused to validate the retrieval of the digital asset by:in accordance with a determination that the second user is not comprised in a set of users allowed to use the digital asset, performing one of:determining that the validation of the retrieval of the digital asset is failed,determining that the validation of the retrieval of the digital asset is successful with addition of the second user to the set of users, ordetermining that the validation of the retrieval of the digital asset is successful without addition of the second user to the set of users.23.The third apparatus of claim 13, wherein a first user owning the digital asset is different from a second user to use the digital asset, the first requesting entity is associated with the second user, and the third apparatus is caused to validate the retrieval of the digital asset by:obtaining a consent response from the first user, the consent response indicating whether the second user is allowed to use the digital asset; anddetermining the result of the validation based on the consent response.24.The third apparatus of claim 23, wherein the third apparatus comprises or is comprised in a first network function, and the third apparatus is caused to obtain the consent response from the first user by:transmitting, to a second network function, a consent request for the second user to use the digital asset; andreceiving, from the second network function, the consent response from the first user.25.The third apparatus of claim 13, wherein the third apparatus is further caused to:receive, from an application function, a request to validate the use of the digital asset by a second user; andtransmit, to the application function based on the result of the validation, a response indicating whether the second user is allowed to use the digital asset.26.The third apparatus of claim 13, wherein the service request comprises an access token for asset retrieval service, the access token comprises the first authorization information, and the third apparatus is caused to validate the retrieval of the digital asset by:in accordance with a successful validation of the access token, deriving the first authorization information from the access token; andvalidate the retrieval of the digital asset based on the derived first authorization information.27.The third apparatus of claim 26, wherein the third apparatus comprises or is comprised in a first network function, and the third apparatus is further caused to:receive, from a second network function, an authorization request for asset authorization information about the digital asset;validate the authorization request based on allowance information for using the digital asset; andin accordance with a successful validation of the authorization request, transmit, to the second network function, the first authorization information.28.The third apparatus of claim 26, wherein the service response comprises information of the digital asset.29.A fourth apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the fourth apparatus at least to:receive, from a second requesting entity, second information indicating that a digital asset is to be used by a second user;validate the use of the digital asset by the second user based on the second information; andtransmit, to the second requesting entity, a validation result of the use of the digital asset by the second user.30.The fourth apparatus of claim 29, wherein the second information comprises the digital asset, second authorization information about usage of the digital asset, and a signature for the digital asset and the second authorization information, and the fourth apparatus is caused to validate the use of the digital asset by the second user by at least one of:verifying the signature based on a certificate of a first network function,checking the second authorization information, orauthenticating a user identity in the second authorization information.31.The fourth apparatus of claim 29, wherein the second information comprises an identification of the digital asset, and the fourth apparatus is caused to validate the use of the digital asset by the second user by:transmit, to a first network function, a request to validate the use of the digital asset by the second user; andreceive, from the first network function, a response indicating whether the second user is allowed to use the digital asset.32.A fifth apparatus comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the fifth apparatus at least to:receive, from a first requesting entity, an access token request for an asset retrieval service;obtain first authorization information about usage at least a digital asset allowed to be used by the first requesting entity; andtransmit, to the first requesting entity, an access token comprising the first authorization information.33.The fifth apparatus of claim 32, wherein the fifth apparatus comprises or is comprised in a second network function, and the fifth apparatus is caused to obtain the first authorization information by:transmitting, to a first network function, an authorization request for asset authorization information about the digital asset; andreceiving the first authorization information from the first network function.34.A method comprising:transmitting, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset.receiving, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.35.A method comprising:obtaining first information regarding retrieval of a digital asset for using by a second user.transmitting, to an application function, second information indicating that the digital asset is to be used by the second user.receiving, from the application function, a validation result of the use of the digital asset by the second user.36.A method comprising:receiving, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset.validating the retrieval of the digital asset based on at least the first authorization information.transmitting, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.37.A method comprising:receiving, from a second requesting entity, second information indicating that a digital asset is to be used by a second user.validating the use of the digital asset by the second user based on the second information.transmitting, to the second requesting entity, a validation result of the use of the digital asset by the second user.38.A method comprising:receiving, from a first requesting entity, an access token request for an asset retrieval service.obtaining first authorization information about usage at least a digital asset allowed to be used by the first requesting entity.transmitting, to the first requesting entity, an access token comprising the first authorization information.39.A first apparatus comprising:means for transmitting, to a first network function, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset; andmeans for receiving, from the first network function, a service response to the service request, wherein the service response is based on a validation result of the retrieval of the digital asset.40.A second apparatus comprising:means for obtaining first information regarding retrieval of a digital asset for using by a second user;means for transmitting, to an application function, second information indicating that the digital asset is to be used by the second user; andmeans for receiving, from the application function, a validation result of the use of the digital asset by the second user.41.A third apparatus comprising:means for receiving, from a first requesting entity, a service request to retrieve a digital asset, the service request comprising first authorization information about usage of at least the digital asset;means for validating the retrieval of the digital asset based on at least the first authorization information; andmeans for transmitting, to the first requesting entity, a service response to the service request based on a validation result of the retrieval of the digital asset.42.A fourth apparatus comprising:means for receiving, from a second requesting entity, second information indicating that a digital asset is to be used by a second user;means for validating the use of the digital asset by the second user based on the second information; andmeans for transmitting, to the second requesting entity, a validation result of the use of the digital asset by the second user.43.A fifth apparatus comprising:means for receiving, from a first requesting entity, an access token request for an asset retrieval service;means for obtaining first authorization information about usage at least a digital asset allowed to be used by the first requesting entity; andmeans for transmitting, to the first requesting entity, an access token comprising the first authorization information.44.A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 6 or the method of claim 7 or the method of claim 8 or the method of claim 9 or the method of claim 10.

Images