WO2025245782A1

WO2025245782A1 - Methods and apparatuses for privacy management

Info

Publication number: WO2025245782A1
Application number: PCT/CN2024/096331
Authority: WO
Inventors: Fengpei Zhang; Ajit RAGHAVAN
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-05-30
Filing date: 2024-05-30
Publication date: 2025-12-04
Anticipated expiration: 2026-11-30

Abstract

Methods and apparatuses for privacy management are disclosed. According to an embodiment, a privacy management system receives, from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request comprises a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. The privacy management system checks whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices. The privacy management system sends, to the requesting entity, a sixth response comprising a result of the checking.

Description

METHODS AND APPARATUSES FOR PRIVACY MANAGEMENT

Technical Field

Embodiments of the disclosure generally relate to communication, and, more particularly, to methods and apparatuses for privacy management.

Background

This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

The 5th generation (5G) has enabled many innovative use cases related to enterprise usage of connectivity. Enterprises are now given more control to influence the connectivity and other assets which have traditionally been within only communication service provider (CSP) control. CSPs are enabling enterprises to use the network assets via exposing various network application programming interfaces (APIs) . These new capabilities are attracting a new breed of application service providers who want to leverage these CSP’s network APIs (e.g., location, device status, number verify, etc. ) to provide innovative applications to the enterprises.

Summary

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

One of the objects of the disclosure is to provide an improved solution for privacy management. In particular, one of the problems to be solved by the disclosure is that the existing solution for privacy management captures consent individually for each of a plurality of terminal devices of an enterprise, resulting in cumbersome burden on the enterprise administrator and high storage cost of individual consent records.

According to a first aspect of the disclosure, there is provided a method at a privacy management system. The method may comprise receiving, from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise a target device identifier (ID) identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. The method may further comprise checking whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices. The method may further comprise sending, to the requesting entity, a sixth response comprising a result of the checking.

According to a second aspect of the disclosure, there is provided a method at an identity management system. The method may comprise obtaining a target device ID identifying a target terminal device and a target group ID identifying a target group that the target terminal device belongs to. The method may further comprise sending, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise the target device ID, the target group ID, and a target application ID identifying the target application. The method may further comprise receiving, from the privacy management system, a sixth response comprising a result of the checking.

According to a third aspect of the disclosure, there is provided a method at an administration device. The method may comprise sending, to a privacy management system, a fifth request for providing a grant of a common privacy management configuration to a group of terminal devices. The common privacy management configuration may comprise a group ID identifying the group and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. The method may further comprise receiving a fifth response from the privacy management system.

According to a fourth aspect of the disclosure, there is provided a method at an application server for a target application. The method may comprise sending, to an identity management system, an eleventh request for obtaining an access token for a target terminal device. The method may further comprise receiving, from the identity management system, an eleventh response comprising the access token of the target terminal device. The access token of the target terminal device may comprise a claim indicating a target group that the target terminal device belongs to.

With the above fourth aspect, because the access token indicates the target group, whenever the access token is used for API invocation, the target group indicated in the access token can be recorded into a log so as to be used at a possible future time for auditing whether a historic API invocation is eligible.

According to a fifth aspect of the disclosure, there is provided a method at a device ID server. The method may comprise receiving, from a target terminal device, a twelfth request for obtaining an ID token of a target terminal device. The method may further comprise sending, to an identity management system, a ninth request for obtaining a target group that the target terminal device belongs to. The ninth request may comprise a target device ID identifying the target terminal device. The method may further comprise receiving, from the identity management system, a ninth response comprising a target group ID identifying the target group. The method may further comprise generating an ID token for the target terminal device. The ID token may comprise the target group ID. The method may further comprise sending a twelfth response comprising the ID token of the target terminal device to the target terminal device.

According to a sixth aspect of the disclosure, there is provided a method at a target terminal device. The method may comprise sending, to a device ID server, a twelfth request for obtaining an ID token of the target terminal device. The method may further comprise receiving, from the device ID server, a twelfth response comprising the ID token of the target terminal device. The ID token may comprise a target group ID identifying a target group that the target terminal device belongs to.

With any one of the above fifth and sixth aspects, the enrichment of the ID token with group information allows more efficient authorization checks as well as privacy management configuration checks (e.g. consent checks) during API service invocation time or at access token generation time. When resolving an ID token received from API services or authorization server (e.g. identity management system) , the device ID server does not need to query to get the group associated with the target terminal device since it is already available in the ID token. Because the authorization server or API services can know the group when the ID token is resolved, it has no need to repeatedly query the group. This again results in better utilization of resources by avoiding multiple lookups in API services or authorization server.

According to a seventh aspect of the disclosure, there is provided a method at an API server. The method may comprise sending, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. The method may further comprise receiving, from the privacy management system, a sixth response comprising a result of the checking.

With any one of the above first to third aspects and seventh aspect, it can provide a better total cost of ownership and less resource/storage utilization by maintaining the privacy management configuration at a group level, instead of maintaining the privacy management configuration at individual device level. Further, the complexity of privacy management can be reduced since the amount of stored configuration is reduced. The efficiency of querying of the stored configuration can also be increased.

According to an eighth aspect of the disclosure, there is provided a privacy management system. The privacy management system may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the privacy management system may be operative to execute the method according to the first aspect of the present disclosure.

According to a ninth aspect of the disclosure, there is provided an identity management system. The identity management system may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the identity management system may be operative to execute the method according to the second aspect of the disclosure.

According to a tenth aspect of the disclosure, there is provided an administration device. The administration device may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the administration device may be operative to execute the method acccording to the third aspect of the present disclosure.

According to an eleventh aspect of the disclosure, there is provided an application server for a target application. The application server may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the application server may be operative to execute the method acccording to the fourth aspect of the present disclosure.

According to a twelfth aspect of the disclosure, there is provided a device ID server. The device ID server may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the device ID server may be operative to execute the method acccording to the fifth aspect of the present disclosure.

According to a thirteenth aspect of the disclosure, there is provided a target terminal device. The target terminal device may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the target terminal device may be operative to execute the method acccording to the sixth aspect of the present disclosure.

According to a fourteenth aspect of the disclosure, there is provided an API server. The API server may comprise at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the API server may be operative to execute the method acccording to the seventh aspect of the present disclosure.

According to a fifteenth aspect of the disclosure, there is provided a computer program product. The computer program product may comprise instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above first to seventh aspects.

According to a sixteenth aspect of the disclosure, there is provided a computer readable storage medium. The computer readable storage medium may store thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above first to seventh aspects.

According to a seventeenth aspect of the disclosure, there is provided a method implemented in a communication system. The communication system may include any two or more of: a privacy management system, an identity management system, an administration device, an application server, a device ID server, a target terminal device, and an API server. The method may comprise any two or more of: steps of the method according to the above first aspect; steps of the method according to the above second aspect; steps of the method according to the above third aspect; steps of the method according to the above fourth aspect; steps of the method according to the above fifth aspect; steps of the method according to the above sixth aspect; and steps of the method according to the above seventh aspect.

According to an eighteenth aspect of the disclosure, there is provided a communication system. The communication system may include any two or more of: a privacy management system according to the above eighth aspect; an identity management system according to the above ninth aspect; an administration device according to the above tenth aspect; an application server according to the above eleventh aspect; a device ID server according to the above twelfth aspect; a target terminal device according to the above thirteenth aspect; and an API server according to the above fourteenth aspect.

Brief Description of the Drawings

These and other objects, features and advantages of the disclosure will become apparent from the following detailed description of illustrative embodiments thereof, which are to be read in connection with the accompanying drawings.

FIG. 1 is a diagram illustrating an open gateway network-as-a-service (NaaS) architecture;

FIG. 2 is a diagram illustrating an exemplary architecture into which an embodiment of the disclosure is applicable;

FIGs. 3-6 are flowcharts illustrating processes according to embodiments of the disclosure;

FIGs. 7A-7C are flowcharts each illustrating a process according to an embodiment of the disclosure;

FIG. 8 is a flowchart illustrating a process according to an embodiment of the disclosure;

FIGs. 9-13 are flowcharts illustrating methods performed by a privacy management system according to embodiments of the disclosure;

FIGs. 14-18 are flowcharts illustrating methods performed by an identity management system according to embodiments of the disclosure;

FIGs. 19A and 19B are flowcharts for explaining the method of FIG. 18;

FIGs. 20-21 are flowcharts illustrating methods performed by an identity management system according to embodiments of the disclosure;

FIGs. 22-25 are flowcharts illustrating methods performed by an administration device according to embodiments of the disclosure;

FIG. 26 is a flowchart illustrating a method performed by an application server according to an embodiment of the disclosure;

FIG. 27 is a flowchart illustrating a method performed by a device ID server according to an embodiment of the disclosure;

FIG. 28 is a flowchart illustrating a method performed by a target terminal device according to an embodiment of the disclosure;

FIGs. 29-30 are flowcharts illustrating methods performed by an API server according to embodiments of the disclosure;

FIGs. 31A and 31B are flowcharts illustrating an exemplary process according to an embodiment of the disclosure;

FIG. 32 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure;

FIGs. 33A and 33B are flowcharts each illustrating an exemplary process according to an embodiment of the disclosure;

FIG. 34 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure;

FIGs. 35A-35C are flowcharts each illustrating an exemplary process according to an embodiment of the disclosure;

FIG. 36 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure;

FIG. 37 is a block diagram illustrating an apparatus suitable for use in practicing some embodiments of the disclosure;

FIG. 38 is a block diagram illustrating a privacy management system according to an embodiment of the disclosure;

FIG. 39 is a block diagram illustrating an identity management system according to an embodiment of the disclosure;

FIG. 40 is a block diagram illustrating an administration device according to an embodiment of the disclosure;

FIG. 41 is a block diagram illustrating an application server according to an embodiment of the disclosure;

FIG. 42 is a block diagram illustrating a device ID server according to an embodiment of the disclosure;

FIG. 43 is a block diagram illustrating a target terminal device according to an embodiment of the disclosure; and

FIG. 44 is a block diagram illustrating an API server according to an embodiment of the disclosure.

Detailed Description

For the purpose of explanation, details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed. It is apparent, however, to those skilled in the art that the embodiments may be implemented without these specific details or with an equivalent arrangement.

As described above, communication service providers (CSPs) are enabling enterprises to use the network assets via exposing various network application programming interfaces (APIs) . These new capabilities are attracting a new breed of application service providers who want to leverage these CSP’s network APIs (e.g., location, device status, number verify, etc. ) to provide innovative applications to the enterprises. But the access of enterprises’ resource by these applications does bring in security concern. CSPs as the resource providers need to ensure that the access to these resources happens only once the requisite consents have been provided by the enterprises.

Many of the enterprises, especially those related to mass device scenarios like Internet of things (IoT) sensors, surveillance cameras, fleet management, etc., usually have hundreds and thousands of such devices. Access to these devices via APIs by the application means that there needs to be consent available for each of the devices before CSP can grant access to these devices via APIs.

There are many industry bodies which are trying to standardize these network APIs and how the consent is handled for allowing access to these devices. Notably among them are CAMARA initiative and global system for mobile communication association (GSMA) open gateway initiatives. The CAMARA is an open source project within Linux foundation to define, develop and test the APIs. CAMARA works in close collaboration with the GSMA operator platform group to align API requirements and publish API definitions and APIs.

FIG. 1 illustrates GSMA open gateway network-as-a-service (NaaS) architecture. As shown, the architecture may comprise 3rd party domain and CSP domain. Customers, such as enterprise customers (e.g. enterprise customer #1 and enterprise customer #2) , application service providers and application developers, may be in the 3rd party domain. There may optionally be an aggregator in the 3rd party domain. In the aggregator model, the third party marketplace enables a single channel for tenant applications to gain access to capabilities from multiple CSPs, without the need for the customer to set up a contractual relationship with each of them. Instead of employing the aggregator, operator’s portal/marketplace may enable tenant applications to gain access to capabilities from the operator.

There may be an open gateway NaaS platform, an API integration component, an operation and management system, network capabilities and cloud capabilities in the CSP domain. The open gateway NaaS platform may provide all the features that are needed to policy manage the interaction between the CSP and the third-party domains (other operators and third party aggregators) , including an access control component, a transaction record component, a user consent management component, a privacy and security component and a platform federation component. Between the open gateway NaaS platform and the operator’s portal/marketplace or the third party marketplace, there may be CAMARA APIs and operate APIs.

The CAMARA APIs are APIs exposed to customers, directly or through the aggregator. Depending on their semantic scope, CAMARA APIs can be clustered into two groups: Service APIs and Service Management APIs. Each of Service APIs provides a purpose-specific capability to third parties, e.g., quality on demand (QoD) , device location, edge discovery and selection, etc. Service APIs may be provided by operators directly or with the support of bodies like GSMA, 5G future forum (5GFF) , CableLabs, BridgeAlliance, TM Forum, etc., and are typically developed and validated in collaboration with customers.

Service Management APIs allow the application developer to run certain management functions from within the application, like ordering the enablement of certain functionality for that application, monitoring, eligibility check or consumption check. These APIs may be contributed by CAMARA partners from TM Forum and are typically designed and tested, partnering with application developers.

Operate APIs offer programmable access to operation, administration and management (OAM) capabilities to facilitate the integration of the open gateway NaaS platform with portals, marketplaces and other aggregator platforms.

From a CSP domain standpoint, the 3rd party-facing APIs are constructions that result from the abstraction, aggregation, and enrichment of the operator’s internal APIs (technology-specific APIs and OAM APIs) . This abstraction is performed by the transformation functions in the API integration component. The transformation function translates CAMARA API calls into calls to technology specific APIs, executing the workflows that implement this mapping.

The technology-specific APIs are operator internal APIs offering programmable access to telecommunication infrastructure and network, service and information technology (IT) capabilities. The technology-specific APIs may include network APIs and cloud APIs. Through the network APIs, network capabilities including home and fixed network capabilities, radio access network capabilities, transport network capabilities and core network capabilities can be accessed. Through the cloud APIs, cloud capabilities including infrastructure-as-a-service (IaaS) and containers-as-a-service (CaaS) can be accessed.

One more aspect related to consent handling is the identification and authentication/authorization of the device before access is allowed to the application. Due to privacy concerns, the mobile station international ISDN number (MSISDN) /Internet protocol (IP) address of the device is not recommended to be exchanged directly in these network APIs as plain text, where the term ISDN refers to integrated services digital network. To tackle this, a proposal is now available within CAMARA/Open Gateway where the device is provided with a secure identifier (ID) token by the CSP’s authorization server. That ID token includes an anonymized identifier of the device which can be shared with the application by the device. That ID token can be used by the application to trigger the network API without specifying the device identifier like MSISDN/IP address. The ID token can be decoded by the CSP to identify the device ID (MSISDN) and then provide the services on the device as required in that network API.

According to the regulations of certain regions, processing personal data is generally prohibited, unless it is expressly allowed by law, or the resource owner has consented to the processing. CSPs must ensure that they have had the consent from their subscribers or current device users before their personal data is shared with an application. Another important aspect is that the resource owner may need to understand the purpose of processing his/her personal data. For example, the resource owner needs to understand, whether the purpose of processing location data is essential for providing the contracted service (e.g. showing the device position on a map) or for other purposes like personalized advertisements (like depicting sales offering in addition on the map) . For example, the personal data may include: 1) static information such as identity, demographical information or subscription information; 2) dynamic information such as device status or device location; 3) service adjustment (e.g. service activation or deactivation) such as changing the quality of service (QoS) of a device connection.

As mentioned hereinbefore, most enterprise scenarios involve a huge number of devices which will be the target of these network APIs. To capture consent individually for each of the devices will be a huge challenge for the enterprise administrators. Therefore, it would be desirable for them to register a single consent for a group of devices. It would also be desirable for them to add or remove device (s) as needed from the group consent scope. However, this is currently not supported. Consent records are created and evaluated separately for each of the devices.

When a device retrieves an ID token from the CSP user equipment (UE) identity server, the ID token only contains information about the device (as is proposed in CAMARA currently) . There is no indicator of the group the device belongs to. Because of this, there is no optimization possible in consent management for handling any group-based consent if that solution was available.

The present disclosure proposes an improved solution for privacy management. Hereinafter, the solution will be described in detail with reference to FIGs. 2-44.

FIG. 2 is a diagram illustrating an exemplary architecture into which an embodiment of the disclosure is applicable. The exemplary architecture of FIG. 2 follows the GSMA open gateway NaaS reference architecture of FIG. 1. As shown in FIG. 2, the architecture may comprise 3rd party domain 21 and CSP domain 22. There may be a terminal device 211 and an application server 212 in the 3rd party domain 21. Note that there are a plurality of terminal devices 211 which are owned by an enterprise and FIG. 2 shows only one terminal device 212 for illustration purpose. These terminal devices 212 may be managed by an administrator of the enterprise on behalf of the enterprise. Note that the enterprise mentioned here may refer to any organization which owns (or has a right to manage) the plurality of terminal devices 212. For example, the terminal device 211 may run a target application and interact with an application server 212 for the target application in client-server manner where the terminal device 211 acts as a client and the application server 212 acts as an application backend.

As an exemplary example, there may be a mobile application running in the terminal device 211. The mobile application can work together with the application backend to deliver a certain service (e.g., video streaming) to the user of the terminal device. The application backend may invoke service APIs exposed by the CSP, e.g., QoD, to boost the mobile connection for video streaming in order to delivery better experience to the user. For that purpose, the application backend will have access to an identity management system 222 and an API server 226 (exposing the service APIs) through an API gateway 221.

The API gateway 221, the identity management system 222, a privacy management system 223, a subscription management system 224, a provisioning system 225, the API server 226 and a device ID server 227 may be in the CSP domain 22. The API gateway 221 may be a service, device or proxy acting as an intermediary for accepting, routing and managing API traffic to backend services. The application server 212 may invoke service APIs towards the API gateway 221 to access corresponding network assets of the CSP. The identity management system 222 may be responsible for management of user identities. For example, the identity management system 222 may be an identity and access management (IAM) system which may be further responsible for authentication and authorization of users according to e.g. open authorization 2.0 (OAuth 2.0) . The privacy management system 223 may be responsible for privacy management (e.g. consent management) . For the example of consent management, the privacy management system 223 may manage the consents for application to access to network assets of the CSP (e.g. personal data of UEs) through service APIs. The privacy management system 223 may provide a management portal via the API gateway 221 to the administrator of the enterprise, so that the administrator can manage the plurality of terminal devices 211 owned by the enterprise.

The subscription management system 224 may be responsible for managing the subscriptions of terminal devices to different services. The provisioning system 225 may be responsible for configuring, activating, and managing the network services and resources for users. The API server 226 can expose the services and capabilities provided by the network of the CSP through corresponding service APIs. There may be multiple API servers 226 in the CSP domain. For example, the API server may be a network exposure function (NEF) , a service capability exposure function (SCEF) , or any other server having similar functionality. The device ID server 227 can generate an ID token for the terminal device 211.

Within the context of this disclosure, the term terminal device or user equipment (UE) may also be referred to as, for example, access terminal, mobile station, mobile unit, subscriber station, or the like. It may refer to any end device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the terminal device or UE may include a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback appliance, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA) , or the like.

In an Internet of things (IoT) scenario, a terminal device or UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device or UE and/or a network equipment. In this case, the terminal device or UE may be a machine-to-machine (M2M) device, which may, in a 3GPP context, be referred to as a machine-type communication (MTC) device. Particular examples of such machines or devices may include sensors, metering devices such as power meters, industrial machineries, bikes, vehicles, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches, and so on.

Note that at least some of the components shown in FIG. 2 may be implemented either as a device on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. Also note that the specific terms used herein do not limit the present disclosure only to the architecture or communication system related to the specific terms, which however can be more generally applied to other architectures or communication systems.

FIG. 3 is a flowchart illustrating a process according to an embodiment of the disclosure. As shown, the process involves three entities: an administration device, a privacy management system and an identity management system. The administration device may refer to a device used by an administrator of an enterprise to perform management operations for a plurality of terminal devices owned by the enterprise. Thus, any device having wired and/or wireless communication capability may be used as the administration device. The privacy management system and the identity management system have been described above with respect to FIG. 2. Note that only those blocks relevant to the present disclosure are shown in FIGs. 3-8 and some blocks may be omitted so as not to obscure the principle of the present disclosure.

At block 301, the administration device sends, to the privacy management system, a first request for creating a group of terminal devices to which a common privacy management configuration can be granted. The group of terminal devices may be the plurality of terminal devices owned by the enterprise or a portion of the plurality of terminal devices. The common privacy management configuration means that the privacy management configuration is applicable to every member of the group. The common privacy management configuration may be used for checking whether a given application is allowed to access resources associated with the group or perform service adjustment for the group. The resources associated with the group may include, but not limited to: static information of the group, such as identity, demographical information or subscription information of the members of the group; and dynamic information such as device statuses or device locations of the members of the group. The service adjustment may include, but not limited to, service activation or deactivation (e.g. changing the QoS of a device connection) . For example, the common privacy management configuration for a given application may be a consent (from the administrator) indicating the given application is allowed to access resources associated with the group or perform service adjustment for the group. Note that any other common privacy management configuration may be possible as long as it is applicable to every member of the group.

For example, the administration device may be used by the administrator to log in to a management portal provided by the privacy management system, so that the first request is sent to the privacy management system. The first request may comprise at least a name of the group. The first request may also comprise a description about the group (e.g. “staff members or connected vehicles of the enterprise” ) .

At block 302, the privacy management system sends, to the identity management system, a second request for creating the group. The second request may comprise at least the name of the group, which is indicated in the first request. The second request may also comprise the description about the group, which is indicated in the first request.

At block 303, the identity management system determines a group ID identifying the group. As a simplest example, the group ID may be a binary number having a predetermined number of bits. For determining the group ID, any one from the unused binary numbers that can be represented by the predetermined number of bits may be selected as the group ID. Note that the constituent components of the group ID may be not limited to the binary digits and any other method for assigning unique IDs to indivisual objects may be used at block 303.

At block 304, the identity management system sends, to the privacy management system, a second response comprising the group ID. At block 305, the privacy management system sends, to the administration device, a first response comprising the group ID.

At block 306, the administration device sends, to the privacy management system, a third request for indicating members of the group or adding a first terminal device into the group. The third request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device. For example, the device ID of a terminal device may be an MSISDN of the terminal device. The list of device IDs may be used at the time when the group is created initially, to indicate the original members of the group. The first device ID may be used at later time when there are new member (s) added into the group. Note that the number of the first terminal device and thus the number of the first device ID may be more than one depending on the specific scenario.

At block 307, the privacy management system sends, to the identity management system, a fourth request for indicating the members of the group or adding the first terminal device into the group. The fourth request comprises the group ID, and the list of device IDs or the first device ID.

At block 308, the identity management system stores or updates the members of the group. In the case where the fourth request comprises the group ID and the list of device IDs, the group ID and the list of device IDs may be stored. In the case where the fourth request comprises the group ID and the first device ID, the first device ID may be additionally stored for the group.

At block 309, the identity management system sends a fourth response to the privacy management system. For example, the fourth response may indicate a successful storage or update of the members of the group. Note that if the indicated members of the group or the added first terminal device are not managed by the administrator of the enterprise, the fourth response may indicate a failed storage or update of the members of the group, which will be described later with respect to FIG. 17.

At block 310, the privacy management system sends a third response to the administration device based on the fourth response. For example, if the fourth response is a successful response, the third response may indicate a successful storage or update of the members of the group. On the other hand, if the fourth response is a failed response, the third response may be a failed response.

With the process of FIG. 3, it is possible to improve the efficiency for the owner of the group of terminal devices (e.g. the administrator of an enterprise owning the group of terminal devices) by managing the group creation or member addition in group level since the owner can avoid the need to register individual privacy management configuration for each terminal device the enterprise owns.

FIG. 4 is a flowchart illustrating a process according to an embodiment of the disclosure. The process of FIG. 4 may be performed when the process of FIG. 3 has been performed. At block 401, the administration device sends, to the privacy management system, a fifth request for providing a grant of a common privacy management configuration to the group. The common privacy management configuration comprises the group ID and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. Optionally, with respect to the access of resources, the common privacy management configuration may further comprise one or more of: a scope indicating which resource or resources (e.g. static information, dynamic information, the specific information type of the static or dynamic information) associated with the group are allowed to be accessed by the application; and a purpose (e.g. navigation, advertisement) indicating a reason why the application needs to access resources associated with the group. Optionally, with respect to the service adjustment, the common privacy management configuration may further comprise one or more of: a scope indicating a scope of service adjustment; and a purpose indicating a reason why the application needs to perform service adjustment for the group. With the optional scope and/or purpose, a finer granularity of control over the privacy management can be achieved. For example, the administration device may be used by the administrator to log in to a management portal provided by the privacy management system, so that the fifth request is sent to the privacy management system.

At block 402, the privacy management system stores the common privacy management configuration for the group. At block 403, the privacy management system sends a fifth response to the administration device. For example, the fifth response may indicate a successful storage of the common privacy management configuration.

With the process of FIG. 4, it can provide a better total cost of ownership and less resource/storage utilization by maintaining the privacy management configuration at a group level, instead of maintaining the privacy management configuration at individual device level. Further, the complexity of privacy management can be reduced since the amount of stored configuration is reduced. The efficiency of querying of the stored configuration can also be increased.

FIG. 5 is a flowchart illustrating a process according to an embodiment of the disclosure. The process of FIG. 5 may be performed when the process of FIG. 4 has been performed. As shown, the process involves four entities: a target terminal device, an application server, an identity management system and a privacy management system. Since there may be multiple enterprises each of which owns its group of terminal devices, there may be multiple groups created respectively for the multiple enterprises, and there may be multiple common privacy management configurations granted respectively for the multiple enterprises. The target terminal device may be a member of a group of terminal devices which are owned by any one of the multiple enterprises. The target terminal device may run a target application and interact with the application server for the target application in client-server manner. The identity management system and the privacy management system have been described above with respect to FIG. 2.

At block 502, authentication is performed for the target terminal device. Block 502 may be performed in response to the target application requiring invocation of a service API exposed by an API server in CSP domain. The authentication may be based on authentication code flow or client initiated backchannel authentication (CIBA) flow. As an option, the authentication may be based on an IP address of the target terminal device. For example, the identity management system may use the IP address to obtain the corresponding device ID (e.g. MSISDN) from the core network of the CSP serving the target terminal device. When the device ID is obtained, the authentication is done for the target terminal device. As another option, the authentication may be based on subscriber identity module (SIM) information of the target terminal device. Various SIM-based authentication techniques such as EAP-AKA or AKMA may be used, where the term EAP refers to extensible authentication protocol, the term AKA refers to authentication and key agreement, and the term AKMA refers to authentication and key management for application. As yet another option, the authentication may be based on username and password. For example, the target terminal device may be previously registered in the identity management system by using its device ID, a username and password. If the username and password which are indicated by the target terminal device in the authorization request are same as the previously registered username and password, the authentication is done for the target terminal device. Note that the authentication may be performed in any other suitable way.

At block 504, the identity management system determines the target device ID. In the above option of IP address based authentication and SIM information based authentication, the device ID obtained from the core network may be determined as the target device ID. In the above option of username/password based authentication, if the username and password which are indicated by the target terminal device in the authorization request are same as the previously registered username and password, the previously registered device ID may be determined as the target device ID.

At block 506, the identity management system retrieves the target group ID. As described above, there may be multiple groups created respectively for the multiple enterprises, so that group IDs and corresponding lists of device IDs may be stored at the identity management system. By using the target device ID determined at block 504, a list of device IDs that contains the target device ID may be found and the corresponding group ID may be retrieved as the target group ID.

At block 508, the identity management system sends, to the privacy management system, a sixth request for checking whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application. Optionally, with respect to the access of resources, the sixth request may further comprise one or more of: a target scope indicating which resource or resources associated with the target terminal device are desired to be accessed by the target application; and a target purpose indicating a reason why the target application needs to access resources associated with the target terminal device. Optionally, with respect to the service adjustment, the sixth request may further comprise one or more of: a target scope indicating a desired scope of service adjustment; and a target purpose indicating a reason why the target application needs to perform service adjustment for the target terminal device.

At block 509, the privacy management system checks whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on the stored common privacy management configuration. As described above, there may be multiple common privacy management configurations granted respectively for the multiple enterprises. Thus, depending on specific application scenario, there may be one or more common privacy management configurations stored at the privacy management system. If one of the stored one or more common privacy management configurations contains the target device ID, the target group ID, and optionally the target scope and/or the target purpose, it may be determined that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. Otherwise, it may be determined that the target application is not allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device.

At block 510, the privacy management system sends, to the identity management system, a sixth response comprising a result of the checking. At block 512, when the result of the checking indicates that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, the identity management system generates an access token for the target terminal device. The access token comprises a claim indicating the target group.

As an exempary example, Table 1 below shows an extension of the access token information, where an additional “group” claim is introduced and this extension is highlighted with underlines.

Table 1: access token extension

At block 514, the application server sends, to the identity management system, an eleventh request for obtaining an access token for the target terminal device. At block 516, the identity management system sends, to the application server, an eleventh response comprising the access token of the target terminal device. By using the access token, the application server can invoke the required service API. It should be noted that the generation of access token as described above is merely an exemplary example of the behavior that can be driven by the group-level configuration. The principle of the present disclosure may also be applicable to any other behavior besides the generation of access token.

With the process of FIG. 5, due to the use of the target group ID for performing privacy management configuration check, the effect described above with respect to FIG. 4 also applies to the process of FIG. 5. In addition, because the access token indicates the target group, whenever the access token is used for API invocation, the target group indicated in the access token can be recorded into a log so as to be used at a possible future time for auditing whether a historic API invocation is eligible.

FIG. 6 is a flowchart illustrating a process according to an embodiment of the disclosure. As shown, the process involves four entities: a target terminal device, an application server for a target application, a device ID server and an identity management system. The target terminal device and the application server have been described above with respect to FIG. 5. The device ID server and the identity management system have been described above with respect to FIG. 2.

At block 601, the target terminal device sends, to the device ID server, a twelfth request for obtaining an ID token of the target terminal device. At block 602, authentication is performed for the target terminal device. As an option, the authentication may be based on an IP address of the target terminal device. This option may be similar to the option of IP address based authentication as described above with respect to block 502 of FIG. 5. As another option, the authentication may be based on SIM information of the target terminal device. Various SIM-based authentication techniques such as EAP-AKA or AKMA may be used.

At block 603, the device ID server sends, to the identity management system, a ninth request for obtaining a target group that the target terminal device belongs to. The ninth request comprises the target device ID. In the above two options of IP address based authentication and SIM information based authentication, when the authentication is done, the device ID obtained from the core network may be determined as the target device ID. At block 604, the identity management system retrieves the target group ID identifying the target group. Block 604 is similar to block 506 of FIG. 5. At block 605, the identity management system sends, to the device ID server, a ninth response comprising the target group ID.

At block 606, the device ID server generates an ID token for the target terminal device. The ID token comprises the target group ID. The target group ID in the ID token may be either in anonymized form or in plaintext form. At block 607, the device ID server sends a twelfth response comprising the ID token of the target terminal device to the target terminal device.

With the process of FIG. 6, the enrichment of the ID token with group information allows more efficient authorization checks as well as privacy management configuration checks (e.g. consent checks) during API service invocation time or at access token generation time. When resolving an ID token received from API services or authorization server (e.g. identity management system) , the device ID server does not need to query to get the group associated with the target terminal device since it is already available in the ID token. Because the authorization server or API services can know the group when the ID token is resolved, it has no need to repeatedly query the group. This again results in better utilization of resources by avoiding multiple lookups in API services or authorization server.

FIGs. 7A-7C are flowcharts each illustrating a process according to an embodiment of the disclosure. The process of each of FIGs. 7A-7C may be performed when the process of FIG. 4 has been performed. As shown, the process of each of FIGs. 7A-7B involves five entities: a target terminal device, an application server for a target application, a device ID server, an identity management system, and a privacy management system. The target terminal device and the application server have been described above with respect to FIG. 5. The device ID server, the identity management system and the privacy management system have been described above with respect to FIG. 2.

In the process of FIG. 7A, at block 701, an ID token retrieval process shown in FIG. 6 is performed. At block 702, the target terminal device sends the ID token of the target terminal device to the identity management system. Block 702 may be a part of authentication code flow. The authentication code flow may be triggered in response to the target application requiring invocation of a service API exposed by an API server in CSP domain. Note that some part of the authentication code flow is omitted so as not to obscure the principle of the present disclosure.

At block 704, the identity management system sends, to the device ID server, a tenth request for obtaining a target device ID identifying the target terminal device and a target group ID identifying a target group that the target terminal device belongs to. The tenth request comprises the ID token of the target terminal device. Since the ID token of the target terminal device was previously generated by the device ID server, the device ID server can retrieve the device ID and the group ID which correspond to the ID token, as the target device ID and the target group ID. Note that if the group ID contained in the ID token is in plaintext form, the group ID may also be extracted from the ID token. At block 706, the device ID server sends, to the identity management system, a tenth response comprising the target device ID and the target group ID.

At block 708, the identity management system sends, to the privacy management system, a sixth request for checking whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application. Block 708 may be similar to block 508 of FIG. 5. At block 709, the privacy management system checks whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on the stored common privacy management configuration. Block 709 may be similar to block 509 of FIG. 5. At block 710, the privacy management system sends, to the identity management system, a sixth response comprising a result of the checking.

At block 712, when the result of the checking indicates that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, the identity management system generates an access token for the target terminal device. The access token comprises a claim indicating the target group. Block 712 may be similar to block 512 of FIG. 5. At block 714, the application server sends, to the identity management system, an eleventh request for obtaining an access token for the target terminal device. At block 716, the identity management system sends, to the application server, an eleventh response comprising the access token of the target terminal device. By using the access token, the application server can invoke the required service API. With the process of FIG. 7A, the same effect as the process of FIG. 5 can be achieved. Further, due to the use of the device ID token, the security of privacy management can be enhanced.

The process of FIG. 7B is basically same as the process of FIG. 7A except that the application server sends the ID token of the target terminal device to the identity management system at block 703. Block 703 may be a part of CIBA flow. The CIBA flow may be triggered in response to the target application requiring invocation of a service API exposed by an API server in CSP domain. Note that some part of the CIBA flow is omitted so as not to obscure the principle of the present disclosure. With the process of FIG. 7B, the same effect as the process of FIG. 7A can be achieved.

As shown, the process of FIG. 7C involves six entities: a target terminal device, an application server for a target application, a device ID server, an identity management system, an API server, and a privacy management system. The target terminal device and the application server have been described above with respect to FIG. 5. The device ID server, the identity management system, the API server and the privacy management system have been described above with respect to FIG. 2.

In the process of FIG. 7C, at block 701, an ID token retrieval process shown in FIG. 6 is performed. At block 703’ , the application server sends an API invocation request to the API server. The API invocation request comprises the ID token of the target terminal device. Block 703’ may be a part of client credentials flow. The client credentials flow may be triggered in response to the target application requiring invocation of a service API exposed by an API server in CSP domain. Note that some part of the client credentials flow is omitted so as not to obscure the principle of the present disclosure.

At block 704’ , the API server sends, to the device ID server, a tenth request for obtaining a target device ID identifying the target terminal device and a target group ID identifying a target group that the target terminal device belongs to. The tenth request comprises the ID token of the target terminal device. Since the ID token of the target terminal device was previously generated by the device ID server, the device ID server can retrieve the device ID and the group ID which correspond to the ID token, as the target device ID and the target group ID. Note that if the group ID contained in the ID token is in plaintext form, the group ID may also be extracted from the ID token. At block 706’ , the device ID server sends, to the API server, a tenth response comprising the target device ID and the target group ID.

At block 708’ , the API server sends, to the privacy management system, a sixth request for checking whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application. Block 708’ may be similar to block 508 of FIG. 5. At block 709, the privacy management system checks whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on the stored common privacy management configuration. Block 709 may be similar to block 509 of FIG. 5. At block 710’ , the privacy management system sends, to the API server, a sixth response comprising a result of the checking.

At block 714’ , when the result of the checking indicates that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, the API server sends an API invocation response to the application server. With the process of FIG. 7C, the same effect as the process of FIG. 7A can be achieved except that the access token does not indicate the target group.

FIG. 8 is a flowchart illustrating a process according to an embodiment of the disclosure. The process of FIG. 8 may be performed when the process of FIG. 3 or FIG. 4 has been performed. At block 801, the administration device sends, to the privacy management system, a seventh request for removing a second terminal device from the group. The seventh request comprises the group ID and a second device ID identifying the second terminal device. Note that the number of the second terminal device and thus the number of the second device ID may be more than one depending on the specific application scenario. At block 806, the privacy management system sends a seventh response to the administration device. The seventh response may indicate a successful removal of the second terminal device.

At block 802, the privacy management system sends, to the identity management system, an eighth request for removing the second terminal device from the group. The eighth request comprises the group ID and the second device ID. At block 803, the identity management system retrieves one or more access tokens each of which comprises a claim indicating the second terminal device and a claim indicating the group. At block 804, the identity management system revokes the one or more access tokens. Note that the identity management system may also send, to the privacy management system, an eighth response indicating a successful removal of the second terminal device. The privacy management system may also send the seventh response to the administration device after receiving the eighth response.

With the process of FIG. 8, it can provide a better total cost of ownership and better efficiency of privacy management as well as less resource/storage utilization and less complexity of privacy management by managing the removal of terminal device (s) in group level.

FIG. 9 is a flowchart illustrating a method performed by a privacy management system according to an embodiment of the disclosure. At block 924, the privacy management system receives, from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request comprises a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application.

As a first option, the requesting entity may be an identity management system. For this first option, block 924 corresponds to block 508 of FIG. 5, or block 708 of FIG. 7A or FIG. 7B. As a second option, the requesting entity may be an API server. For this second option, block 924 corresponds to block 708’ of FIG. 7C.

At block 926, the privacy management system checks whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices. Note that there may be one or multiple common privacy management configurations maintained at the privacy management system depending on the specific application scenario. The common privacy management configuration may be granted by an administrator of an enterprise owning the group of terminal devices. The common privacy management configuration may comprise a group ID identifying the group, and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group.

For the above first option, block 926 corresponds to block 509 of FIG. 5, or block 709 of FIG. 7A or FIG. 7B. For the above second option, block 926 corresponds to block 709 of FIG. 7C.

At block 928, the privacy management system sends, to the requesting entity, a sixth response comprising a result of the checking. For the above first option, block 928 corresponds to block 510 of FIG. 5, or block 710 of FIG. 7A or FIG. 7B. For the above second option, block 928 corresponds to block 710’ of FIG. 7C. The effect described with respect to FIG. 5 and FIGs. 7A-7C also applies to the method of FIG. 9.

FIG. 10 is a flowchart illustrating a method performed by a privacy management system according to an embodiment of the disclosure. At block 1002, the privacy management system receives, from an administration device, a first request for creating the group of terminal devices to which the common privacy management configuration can be granted. Block 1002 corresponds to block 301 of FIG. 3. At block 1004, the privacy management system sends, to an identity management system, a second request for creating the group. Block 1004 corresponds to block 302 of FIG. 3. At block 1006, the privacy management system receives, from the identity management system, a second response comprising a group ID identifying the group. Block 1006 corresponds to block 304 of FIG. 3. At block 1008, the privacy management system sends, to the administration device, a first response comprising the group ID. Block 1008 corresponds to block 305 of FIG. 3.

With the method of FIG. 10, it is possible to improve the efficiency for the owner of the group of terminal devices (e.g. the administrator of an enterprise owning the group of terminal devices) by creating the group since the owner can avoid the need to register individual privacy management configuration for each terminal device the enterprise owns.

FIG. 11 is a flowchart illustrating a method performed by a privacy management system according to an embodiment of the disclosure. The method of FIG. 11 may be performed when the method of FIG. 10 has been performed. At block 1110, the privacy management system receives, from the administration device, a third request for indicating members of the group or adding a first terminal device into the group. The third request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device. Block 1110 corresponds to block 306 of FIG. 3. At block 1112, the privacy management system sends, to the identity management system, a fourth request for indicating the members of the group or adding the first terminal device into the group. The fourth request comprises the group ID, and the list of device IDs or the first device ID. Block 1112 corresponds to block 307 of FIG. 3. At block 1114, the privacy management system receives a fourth response from the identity management system. Block 1114 corresponds to block 309 of FIG. 3. At block 1116, the privacy management system sends a third response to the administration device based on the fourth response. Block 1116 corresponds to block 310 of FIG. 3. The effect described with respect to FIG. 3 also applies to the method of FIG. 11.

FIG. 12 is a flowchart illustrating a method performed by a privacy management system according to an embodiment of the disclosure. The method of FIG. 12 may be performed when the method of FIG. 11 has been performed. At block 1218, the privacy management system receives, from the administration device, a fifth request for providing a grant of the common privacy management configuration to the group. The common privacy management configuration comprises the group ID, and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. Block 1218 corresponds to block 401 of FIG. 4.

At block 1220, the privacy management system stores the common privacy management configuration for the group. Block 1220 corresponds to block 402 of FIG. 4. At block 1222, the privacy management system sends a fifth response to the administration device. Block 1222 corresponds to block 403 of FIG. 4. The effect described with respect to FIG. 4 also applies to the method of FIG. 12.

FIG. 13 is a flowchart illustrating a method performed by a privacy management system according to an embodiment of the disclosure. The method of FIG. 13 may be performed when the method of FIG. 11 or FIG. 12 has been performed. At block 1330, the privacy management system receives, from the administration device, a seventh request for removing a second terminal device from the group. The seventh request comprises the group ID and a second device ID identifying the second terminal device. Block 1330 corresponds to block 801 of FIG. 8. At block 1332, the privacy management system sends, to the identity management system, an eighth request for removing the second terminal device from the group. The eighth request comprises the group ID and the second device ID. Block 1332 corresponds to block 802 of FIG. 8. At block 1334, the privacy management system sends a seventh response to the administration device. Block 1334 corresponds to block 806 of FIG. 8. The effect described with respect to FIG. 8 also applies to the method of FIG. 13.

FIG. 14 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. At block 1422, the identity management system obtains a target device ID identifying a target terminal device and a target group ID identifying a target group that the target terminal device belongs to. For example, block 1422 may be implemented as blocks 1928-1930 of FIG. 19A or blocks 1932-1934 of FIG. 19B. At block 1928, the identity management system determines the target device ID. Block 1928 corresponds to block 504 of FIG. 5. At block 1930, the identity management system retrieves the target group ID. Block 1930 corresponds to block 506 of FIG. 5.

Alternatively, at block 1932, the identity management system sends, to a device ID server, a tenth request for obtaining the target device ID and the target group ID. The tenth request comprises an ID token of the target terminal device. Block 1932 corresponds to block 704 of FIG. 7A or FIG. 7B. At block 1934, the identity management system receives a tenth response comprising the target device ID and the target group ID from the device ID server. Block 1934 corresponds to block 706 of FIG. 7A or FIG. 7B.

At block 1424, the identity management system sends, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application. Block 1424 corresponds to block 508 of FIG. 5 or block 708 of FIG. 7A or FIG. 7B.

At block 1426, the identity management system receives, from the privacy management system, a sixth response comprising a result of the checking. Block 1426 corresponds to block 510 of FIG. 5 or block 710 of FIG. 7A or FIG. 7B. Thus, the method of FIG. 14 may be applicable to authentication code flow or CIBA flow. The effect described with respect to FIG. 5 and FIGs. 7A-7B also applies to the method of FIG. 14.

FIG. 15 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. At block 1502, the identity management system receives, from the privacy management system, a second request for creating a group of terminal devices to which a common privacy management configuration can be granted. Block 1502 corresponds to block 302 of FIG. 3. At block 1504, the identity management system determines a group ID identifying the group. Block 1504 corresponds to block 303 of FIG. 3. At block 1506, the identity management system sends, to the privacy management system, a second response comprising the group ID. Block 1506 corresponds to block 304 of FIG. 3. The effect described with respect to FIG. 10 also applies to the method of FIG. 15.

FIG. 16 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. The method of FIG. 16 may be performed when the method of FIG. 15 has been performed. At block 1608, the identity management system receives, from the privacy management system, a fourth request for indicating members of the group or adding a first terminal device into the group. The fourth request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device. Block 1608 corresponds to block 307 of FIG. 3. At block 1610, the identity management system stores or updates the members of the group. Block 1610 corresponds to block 308 of FIG. 3. At block 1612, the identity management system sends a fourth response to the privacy management system. Block 1612 corresponds to block 309 of FIG. 3. The effect described with respect to FIG. 11 also applies to the method of FIG. 16.

FIG. 17 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. At block 1608, the identity management system receives, from the privacy management system, a fourth request for indicating members of the group or adding a first terminal device into the group. The fourth request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device.

At block 1714, the identity management system determines whether the indicated members or the first terminal device is managed by an administrator of the group. For example, when the enterprise owning a plurality of terminal devices makes subscription for the plurality of terminal deivces, the provisioning system of the CSP may provision identity information and administrator information of the enterprise as well as a list of device IDs of the plurality of terminal deivces to the identity management system, so that such information can be maintained at the identity management system. Alternatively, since the provisioning system of the CSP may also provision such information to a subscription mangement system of the CSP, such information may also be obtained from the subscription mangement system. When making the determination at block 1714, the identity management system may retrieve the previously maintained information corresponding to the enterprise owning the group of terminal devices. If the list of device IDs or first device ID in the fourth request is in the list of device IDs in the previously maintained information, it may be determined that the indicated members or the first terminal device is managed by an administrator of the group. On the other hand, if the list of device IDs or first device ID in the fourth request is not in the list of device IDs in the previously maintained information, it may be determined that the indicated members or the first terminal device is not managed by the administrator of the group.

At block 1610, when determining that the indicated members or the first terminal device is managed by the administrator of the group, the identity management system stores or updates the members of the group. At block 1612, the identity management system sends a fourth response to the privacy management system.

With the method of FIG. 17, because the group is created after validating the authority of the administrator (e.g. with the subscription management system or the provisioning system) , the security of privacy management for the group can be ensured.

FIG. 18 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. At block 1816, the identity management system receives, from a device ID server, a ninth request for obtaining the target group that the target terminal device belongs to. The ninth request comprises the target device ID identifying the target terminal device. Block 1816 corresponds to block 603 of FIG. 6. At block 1818, the identity management system retrieves the target group ID identifying the target group. Block 1818 corresponds to block 604 of FIG. 6. At block 1820, the identity management system sends, to the device ID server, a ninth response comprising the target group ID. Block 1820 corresponds to block 605 of FIG. 6.

With the method of FIG. 18, it is possible for the device ID server to include the target group ID into the ID token of the target terminal device. Due to this, the effect described with respect to FIG. 6 can be achieved.

FIG. 20 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. At block 2036, when the result of the checking indicates that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, the identity management system generates an access token for the target terminal device. The access token comprises a claim indicating the target group. Block 2036 corresponds to block 512 of FIG. 5, or block 712 of FIG. 7A or FIG. 7B. At block 2038, the identity management system sends the access token to an application server for the target application. For example, the access token may be sent in response to a request from the application server for obtaining the access token.

With the method of FIG. 20, because the access token indicates the target group, whenever the access token is used for API invocation, the target group indicated in the access token can be recorded into a log so as to be used at a possible future time for auditing whether a historic API invocation is eligible.

FIG. 21 is a flowchart illustrating a method performed by an identity management system according to an embodiment of the disclosure. The method of FIG. 21 may be performed when the method of FIG. 16 has been performed. At block 2140, the identity management system receives, from the privacy management system, an eighth request for removing a second terminal device from the group. The eighth request comprises the group ID and a second device ID identifying the second terminal device. Block 2140 corresponds to block 802 of FIG. 8. At block 2142, the identity management system retrieves one or more access tokens each of which comprises a claim indicating the second terminal device and a claim indicating the group. Block 2142 corresponds to block 803 of FIG. 8. At block 2144, the identity management system revokes the one or more access tokens. Block 2142 corresponds to block 804 of FIG. 8. The effect described with respect to FIG. 8 also applies to the method of FIG. 21.

FIG. 22 is a flowchart illustrating a method performed by an administration device according to an embodiment of the disclosure. At block 2210, the administration device sends, to a privacy management system, a fifth request for providing a grant of a common privacy management configuration to a group of terminal devices. The common privacy management configuration comprises a group ID identifying the group and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. Block 2210 corresponds to block 401 of FIG. 4. At block 2212, the administration device receives a fifth response from the privacy management system. Block 2212 corresponds to block 403 of FIG. 4. The effect described with respect to FIG. 4 also applies to the method of FIG. 22.

FIG. 23 is a flowchart illustrating a method performed by an administration device according to an embodiment of the disclosure. At block 2302, the administration device sends, to the privacy management system, a first request for creating the group of terminal devices to which the common privacy management configuration can be granted. Block 2302 corresponds to block 301 of FIG. 3. At block 2304, the administration device receives, from the privacy management system, a first response comprising the group ID identifying the group. Block 2304 corresponds to block 305 of FIG. 3. The effect described with respect to FIG. 10 also applies to the method of FIG. 23.

FIG. 24 is a flowchart illustrating a method performed by an administration device according to an embodiment of the disclosure. The method of FIG. 24 may be performed when the method of FIG. 23 has been performed. At block 2406, the administration device sends, to the privacy management system, a third request for indicating members of the group or adding a first terminal device into the group. The third request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device. Block 2406 corresponds to block 306 of FIG. 3. At block 2408, the administration device receives a third response from the privacy management system. Block 2408 corresponds to block 310 of FIG. 3. The effect described with respect to FIG. 11 also applies to the method of FIG. 24.

FIG. 25 is a flowchart illustrating a method performed by an administration device according to an embodiment of the disclosure. The method of FIG. 25 may be performed when the method of FIG. 22 or FIG. 24 has been performed. At block 2514, the administration device sends, to the privacy management system, a seventh request for removing a second terminal device from the group. The seventh request comprises the group ID and a second device ID identifying the second terminal device. Block 2514 corresponds to block 801 of FIG. 8. At block 2516, the administration device receives a seventh response from the privacy management system. Block 2516 corresponds to block 806 of FIG. 8. The effect described with respect to FIG. 8 also applies to the method of FIG. 25.

FIG. 26 is a flowchart illustrating a method performed by an application server for a target application according to an embodiment of the disclosure. At block 2602, the application server sends, to an identity management system, an eleventh request for obtaining an access token for a target terminal device. Block 2602 corresponds to block 514 of FIG. 5 or block 714 of FIG. 7A or FIG. 7B. At block 2604, the application server receives, from the identity management system, an eleventh response comprising the access token of the target terminal device. The access token of the target terminal device comprises a claim indicating a target group that the target terminal device belongs to. Block 2604 corresponds to block 516 of FIG. 5 or block 716 of FIG. 7A or FIG. 7B. Thus, the method of FIG. 26 may be applicable to authentication code flow or CIBA flow. The effect described with respect to FIG. 20 also applies to the method of FIG. 26.

FIG. 27 is a flowchart illustrating a method performed by a device ID server according to an embodiment of the disclosure. At block 2702, the device ID server receives, from a target terminal device, a twelfth request for obtaining an ID token of a target terminal device. Block 2702 corresponds to block 601 of FIG. 6. At block 2704, the device ID server sends, to an identity management system, a ninth request for obtaining a target group that the target terminal device belongs to. The ninth request comprises a target device ID identifying the target terminal device. Block 2704 corresponds to block 603 of FIG. 6. At block 2706, the device ID server receives, from the identity management system, a ninth response comprising a target group ID identifying the target group. Block 2706 corresponds to block 605 of FIG. 6. At block 2708, the device ID server generates an ID token for the target terminal device. The ID token comprises the target group ID. Block 2708 corresponds to block 606 of FIG. 6. At block 2710, the device ID server sends a twelfth response comprising the ID token of the target terminal device to the target terminal device. Block 2710 corresponds to block 607 of FIG. 6. The effect described with respect to FIG. 6 also applies to the method of FIG. 27.

FIG. 28 is a flowchart illustrating a method performed by a target terminal device according to an embodiment of the disclosure. At block 2802, the target terminal device sends, to a device ID server, a twelfth request for obtaining an ID token of the target terminal device. Block 2802 corresponds to block 601 of FIG. 6. At block 2804, the target terminal device receives, from the device ID server, a twelfth response comprising the ID token of the target terminal device. The ID token comprises a target group ID identifying a target group that the target terminal device belongs to. Block 2804 corresponds to block 607 of FIG. 6. The effect described with respect to FIG. 6 also applies to the method of FIG. 28.

FIG. 29 is a flowchart illustrating a method performed by an API server according to an embodiment of the disclosure. At block 2902, the API server sends, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request comprises a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. Block 2902 corresponds to block 708’ of FIG. 7C.At block 2904, the API server receives, from the privacy management system, a sixth response comprising a result of the checking. Block 2904 corresponds to block 710’ of FIG. 7C. Thus, the method of FIG. 29 may be applicable to client credentials flow. The effect described with respect to FIG. 7C also applies to the method of FIG. 29.

FIG. 30 is a flowchart illustrating a method performed by an API server according to an embodiment of the disclosure. At block 3006, the API server receives, from an application server for the target application, an ID token of the target terminal device. For example, the ID token of the target terminal device may be received in an API invocation request. Block 3006 may be a part of client credentials flow. The client credentials flow may be triggered in response to the target application requiring invocation of a service API exposed by an API server in CSP domain. At block 3008, the API server sends, to a device ID server, a tenth request for obtaining the target device ID and the target group ID. The tenth request comprises the ID token of the target terminal device. Block 3008 corresponds to block 704’ of FIG. 7. At block 3010, the API server receives, from the device ID server, a tenth response comprising the target device ID and the target group ID. Block 3010 corresponds to block 706’ of FIG. 7.

With the method of FIG. 30, it can allow the target group ID to be used for performing checking for the target application, thereby allowing a better total cost of ownership and better efficiency of privacy management as well as less resource/storage utilization and less complexity of privacy management.

FIGs. 31A and 31B are flowcharts illustrating an exemplary process according to an embodiment of the disclosure. As shown, the exemplary process involves five entities: an administrator of an enterprise, a consent management system, a provisioning system, a subscription management system, an IAM system. Thus, the privacy management system described above is implemented as the consent management system and the identity management system described above is implemented as the IAM system in the exemplary process. In addition, the privacy management configuration described above is implemented as consent and the group described above is implemented as consent group. In order to grant consent to a consent group which include multiple devices, the enterprise administrator shall create a consent group first.

At step 1, as prerequisite, the provisioning system provisions the enterprise subscription to the subscription management system. At the same time, at step 2, the provisioning system also provisions enterprise organization, enterprise Admin user and enterprise devices to the IAM system. For example, the enterprise may include multiple departments and every department may have its own administrator to manage terminal devices owned by the department. The enterprise organization mentioned here may refer to the department of the enterprise.

At step 3, the enterprise administrator logs in to a portal provided by the consent management system. At step 4, the consent management system triggers open ID connect (OIDC) procedure involving the IAM system and the enterprise administrator: 1) the consent management system redirects the enterprise administrator to the IAM login portal; 2) the enterprise administrator inputs username and password to the IAM login portal; 3) the IAM system authenticates the enterprise administrator and generates an access token and ID token; 4) the IAM system redirects the enterprise administrator to the consent management system; and 5) the consent management system obtains the access token and ID token.

At step 5, the consent management system extracts Enterprise ID from the ID token. At step 6, the consent management system prompts the enterprise administrator that the login is successful. At step 7, the enterprise administrator creates a consent group through the consent management system, where the request includes name and description. At step 8, the consent management system further requests the IAM system to create the consent group. At step 9, the IAM system returns a successful response back to the consent management system, where the response contains the Group ID. At step 10, the consent management system returns a successful response back to the enterprise administrator, where the response contains the Group ID.

At step 11, the enterprise administrator adds a Device into the consent group through the consent management system. The request includes Device ID and Group ID. At step 12, the consent management system requests the IAM system to add a Device into the consent group. The request includes Device ID and Group ID. At step 13, the IAM system retrieves Device list by Enterprise ID. If the requested Device is in the Device list, the IAM system returns a successful response to the consent management system at step 14. At step 15, the consent management system returns a successful response to the enterprise administrator. If the requested Device is not in the Device list, the IAM system returns a failed response to the consent management system at step 16. At step 17, the consent management system returns a failed response to the enterprise administrator. Note that the added Device may be one device or multiple devices.

Based on the above description about the process of FIGs. 31A-31B, the consent management system provides a portal for the enterprise administrator to manage the consents on behalf of the devices belonging to the enterprise, through a group-based approach. Note that to avoid latency issues related to look-up into the subscription management system at runtime, the enterprise administrator and their authorization information (enterprise department/group level access etc. ) can be provisioned into the CSP’s IAM system when the enterprise administrators are being provisioned in the system.

FIG. 32 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. As shown, the exemplary process involves two entities: an administrator of an enterprise and a consent management system. In this process, after the consent group is created, the enterprise administrator can grant consent to the consent group. At step 1, the enterprise administrator grants consent to a consent group. The request includes Group ID, App ID, scopes and purpose. At step 2, the consent management system returns a successful response.

With the process of FIG. 32, the need from the enterprise administrator can be satisfied to have possibility to register consent for a group of devices as part of a single consent registration. In addition to providing a better efficiency to the enterprise administrator, this group consent does have positive impact on the consent management system (or service) since it does not need to store individual consent records for hundreds or thousands of such devices. This will result in optimized storage needs. The group information including the devices included in that group is maintained by the consent management solution within the IAM system. The consent record is then attached to this group. In addition, the device group is created only after proper authorization by validating the authority of the administrator with the subscription management system, so that the security of consent management for the group can be ensured.

FIGs. 33A and 33B are flowcharts each illustrating an exemplary process according to an embodiment of the disclosure. As shown, the exemplary process involves four entities: a device, an application backend, an IAM system and a consent management system. Thus, the application server described above is implemented as the application backend, the identity management system described above is implemented as the IAM system, and the privacy management system described above is implemented as the consent management system in the exemplary process. According to CAMARA definition, two 3-legged OAuth 2.0 flows will be used in service API invocation: Authorization Code and CIBA. FIGs. 33A and 33B illustrate how these two flows work with group-based consent management, where FIG. 33A corresponds to Authorization Code flow and FIG. 33B corresponds to CIBA flow.

In the process of FIG. 33A, at step 1, the Device executes some logic requiring service API invocation. At step 2, the application backend redirects the Device to the IAM system to trigger OAuth 2.0 Authorization Code flow. The request includes client ID, Application callback uniform resource identifier (URI) , login hint, purpose and scopes. At step 3, the Device initiates OAuth 2.0 Authorization Code flow towards the IAM system. At step 4, the IAM system conducts device authentication. The device authentication may be based on IP address or username/password.

At step 5, the IAM system determines the Device ID after device authentication. At step 6, the IAM system determines the consent group (s) that the Device belongs to. At step 7, the IAM system checks consent towards the consent management system. The request includes App ID, Device ID, Group ID, purpose and scopes. At step 8, the consent management system returns consent check result back to the IAM system. At step 9, the IAM system generates Authorization Code and access token if relevant consent is available. There is an additional claim ‘group” introduced in the access token. At step 10, the IAM system redirects the Device to the application backend with the generated Authorization Code.

At step 11, the Device calls the application backend with the Authorization Code. At step 12, the application backend requests the access token by Authorization Code towards the IAM system. At step 13, the IAM system returns the access token to the application backend. There is an additional claim ‘group” in the access token. Then, the application backend can invoke service API using the access token.

In the process of FIG. 33B, at step 1, the Device executes some logic requiring service API invocation. At step 2, the application backend invokes Backchannel Authorization endpoint of the IAM system to trigger OAuth 2.0 CIBA flow towards the IAM system. At step 3, the IAM system returns Request ID to the application backend. At step 4, the IAM system conducts device authentication through backchannel.

At step 5, the IAM system determines the Device ID after device authentication. At step 6, the IAM system determines the consent group (s) that the device belongs to. At step 7, the IAM system checks consent towards the consent management system. The request includes App ID, Device ID, Group ID, purpose and scopes. At step 8, the consent management system returns consent check result back to the IAM system. At step 9, the IAM system generates access token if relevant consent is available. There is an additional claim ‘group’ introduced in the access token.

At step 10, the application backend requests the access token by Request ID towards the IAM system. At step 10, the IAM system returns the access token to the application backend. There is an additional claim ‘group” in the access token. Then, the application backend can invoke service API using the access token.

Based on the above description about the processes of FIGs. 33A-33B, consent is checked when the IAM system performs OAuth 2.0 authorization flow (e.g., Authorization Code or CIBA) . Only when consent is available, the IAM system will generate access token for the application backend.

FIG. 34 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. As shown, the exemplary process involves four entities: a device, an application backend, a UE ID server and an IAM system. A UE ID token is employed in the process. The UE ID token is an identification of the device generated by the UE ID server which can authenticate the device and retrieve associated information of the device. The UE ID token may be anonymized or encrypted so that when untrusted parties obtain or pass the UE ID token, they cannot resolve the real device ID or track the device. When a CSP network entity needs the real device ID for some network service, it can resolve the UE ID token from the UE ID server.

The process of FIG. 34 provides a UE ID token retrieval sub-procedure. In the procedure, the device retrieves a UE ID token from the UE ID server. The device can send the UE ID token to the application backend and then the application backend can use the UE ID token (in the request payload) for service API invocation where the UE ID token indicates the target device.

At step 1, the Device sends a request to the UE ID server to retrieve a UE ID token. At step 2, the UE ID server initiates a device authentication procedure to authenticate the Device. The authentication may be based on IP address or SIM information. At step 3, once the UE ID server determines the Device ID, the UE ID server sends a request towards the IAM system to retrieve consent group (s) of the Device. At step 4, the IAM system returns the consent group (s) to the UE ID server. At step 5, the UE ID server includes the consent group (s) in the UE ID token. At step 6, the UE ID server returns the UE ID token to the Device.

Based on the above description about the process of FIG. 34, the device may request a UE ID token from the UE ID server. The UE ID token includes the identity and other information of the device. At the time of the ID token generation, the UE ID server will contact the IAM system to retrieve the group ID of the device (if any) . This group ID (if available) is also included in the ID token. In this way, when a network/service API is invoked by the application, the application can include the UE ID token in the service API invocation to pass this UE ID token to allow the API service to retrieve the identity of the device. The group ID available in the ID token can be used by the consent management system to check the consent availability at group level.

FIGs. 35A-35C are flowcharts each illustrating an exemplary process according to an embodiment of the disclosure. The exemplary processes of FIGs. 35A-35C provide authorization flows with UE ID token, where FIG. 35A provides Authorization Code flow with UE ID token, FIG. 35B provides CIBA flow with UE ID token, and FIG. 35C provides Client Credentials flow with UE ID token. As shown, the process of FIG. 35A or FIG. 35B involves five entities: a device, an application backend, a UE ID server, an IAM system and a consent management system.

In the process of FIG. 35A, at step 1, the Device performs UE ID Retrieval sub-procedure of FIG. 34. At step 2, the Device executes some logic requiring service API invocation and sends UE ID token to the application backend. At step 3, the application backend redirects the Device to the IAM system to trigger OAuth 2.0 Authorization Code flow. The request includes client ID, Application callback URI, login hint token (the value is UE ID token) , purpose and scopes. At step 4, the Device initiates OAuth 2.0 Authorization Code flow towards the IAM system.

At step 5, the IAM system conducts device authentication by sending request to the UE ID server to resolve the UE ID token. At step 6, the UE ID server validates the UE ID token (e.g. by validating the signature of the access token) . At step 7, the UE ID server sends back the device ID and Group ID associated with the UE ID token to the IAM system. At step 8, the IAM system checks consent towards the consent management system. The request includes App ID, Device ID, Group ID, purpose and scopes. At step 9, the consent management system returns consent check result back to the IAM system. At step 10, the IAM system generates Authorization Code and access token if relevant consent is available. There is an additional claim ‘group” introduced in the access token. At step 11, the IAM system redirects the Device to the application backend with the generated Authorization Code.

At step 12, the Device calls the application backend with the Authorization Code. At step 13, the application backend requests the access token by Authorization Code towards the IAM system. At step 14, the IAM system returns the access token to the application backend. There is an additional claim ‘group” in the access token. Then, the application backend can invoke service API using the access token.

In the process of FIG. 35B, at step 1, the Device performs UE ID Retrieval sub-procedure of FIG. 34. At step 2, the Device executes some logic requiring service API invocation. At step 3, the application backend invokes Backchannel Authorization endpoint of the IAM system to trigger OAuth 2.0 CIBA flow towards the IAM system. The request includes log in hint toke, whose value is UE ID token. At step 4, the IAM system returns Request ID to the application backend.

At step 5, the IAM system conducts device authentication by sending request to the UE ID server to resolve the UE ID token. At step 6, the UE ID server validates the UE ID token. At step 7, the UE ID server sends back the device ID and Group ID associated with the UE ID token to the IAM system. At step 8, the IAM system checks consent towards the consent management system. The request includes App ID, Device ID, Group ID, purpose and scopes. At step 9, the consent management system returns consent check result back to the IAM system. At step 10, the IAM system generates access token if relevant consent is available. There is an additional claim ‘group” introduced in the access token.

At step 11, the application backend requests the access token by Request ID towards the IAM system. At step 12, the IAM system returns the access token to the application backend. There is an additional claim ‘group” in the access token. Then, the application backend can invoke service API using the access token.

As shown, the process of FIG. 35C involves seven entities: a device, an application backend, a UE ID server, an IAM system, an API gateway, an API server, and a consent management system. Since the process of FIG. 35C provides Client Credentials flow which is a 2-legged authorization flow, the IAM system cannot conduct consent check due to lack of target device information. The API server (exposing Service API) will conduct consent check instead.

In the process of FIG. 35C, at step 1, the Device performs UE ID Retrieval sub-procedure of FIG. 34. At step 2, the Device executes some logic requiring service API invocation and sends UE ID token to the application backend. At step 3, the application backend sends a request to the token endpoint of the IAM system to trigger Client Credentials flow. The request includes Application Client ID, Application Client Secret, scopes and purpose. At step 4, the IAM system returns the access token to the application backend.

At step 5, the application backend sends Service API innovation request to the API server. The request includes access token as header, and payload including UE ID token. At step 6, the API Server sends a request to the UE ID server to resolve the UE ID token. At step 7, the UE ID server validates the UE ID token. At step 8, the UE ID server sends back the device ID and Group ID associated with the UE ID token to the API server.

At step 9, the API server checks consent towards the consent management system. The request includes App ID, Device ID, Group ID, purpose and scopes. At step 10, the consent management system returns consent check result back to the API server. At step 11, the API server returns the response to the application backend if relevant consent is available.

FIG. 36 is a flowchart illustrating an exemplary process according to an embodiment of the disclosure. As shown, the exemplary process involves three entities: an administrator of an enterprise, a consent management system and an IAM system. In the process of FIG. 36, the enterprise administrator may revoke the consent for a device by removing the device from consent group. At step 1, the enterprise administrator requests the consent management system to remove a Device from a consent group. The request includes Device ID and Group ID. At step 2, the consent management system returns a successful response to enterprise administrator. At step 3, the consent management system requests the IAM system to remove a Device from a consent group. The request includes Device ID and Group ID. At step 4, the IAM system looks up access tokens associated with the Device and the consent group. At step 5, the IAM system revokes the access tokens.

Based on the above description about FIGs. 31A-36, the group of devices is created by the enterprise administrator using the consent management system. Before adding a device to a group created by the administrator, it is important for the consent management system to authorize the enterprise administrator for the device. For this purpose, the consent management system needs to integrate with the subscription management system to retrieve if the admin user has authority for the device being added to the consent group. Once the authorization is completed, the consent management system will maintain the group information along with the devices belonging to the group in the IAM system. Once the group has been created, the consents can be registered and maintained for this group.

At the time of UE ID token generation, the UE ID server will connect to the IAM system to retrieve the group the device belongs to. It will enrich the UE ID token with that group information. That group information in the UE ID token will be later used to evaluate the consent for that group by the consent management system. For accessing the APIs, the application first requests for an access token from the CSP’s IAM system by specifying the UE ID token (which contains the device ID information) as well as other parameters like data scope etc. Before the access token is generated, the IAM system uses the group information included in the UE ID token to check for consent by contacting the consent management system. Once the consent is determined to be valid, an access token is generated and sent back to the application. The application can then use the access token to invoke the APIs.

It is also possible that the group may be created by one of the provisioning system and the subscription management system, so that the group ID and corresponding list of device IDs may be directly or indirectly sent to the IAM system and the privacy management configuration such as consent information (including e.g. the group ID, corresponding list of device IDs, application ID, and optionally scope and/or purpose) may be directly or indirectly sent to the privacy management system (e.g. the consent management system) . As an exemplary example, the group may be created first in the external subscription management system and then replicated to the consent management system by the provisioning system.

It is also possible that the addition of terminal device (s) into the group and/or removal of terminal device (s) from the group may also be performed by one of the provisioning system and the subscription management system, so that the updated information may be directly or indirectly sent to the IAM system and the consent management system.

Therefore, an aspect of the present disclosure provides a method at a provisioning system. The method may comprise creating a group of terminal devices to which a common privacy management configuration can be granted. The group may be created when the owner of the group makes subscriptions for the group to services. For example, a group ID identifying the group may be generated. A list of device IDs identifying the group of terminal devices may also be determined. The method may further comprise sending the group to an identity management system. For example, the group ID and the list of device IDs may be sent to the identity management system.

Another aspect of the present disclosure provides a method at a subscription management system. The method may comprise creating a group of terminal devices to which a common privacy management configuration can be granted. The group may be created when the owner of the group makes subscriptions for the group to services. For example, a group ID identifying the group may be generated. A list of device IDs identifying the group of terminal devices may also be determined. The method may further comprise sending the group to an identity management system. For example, the group ID and the list of device IDs may be sent to the identity management system.

In an embodiment of any of the above two aspects, the method may further comprise creating the common privacy management configuration granted to the group. The common privacy management configuration may comprise the group ID and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. The common privacy management configuration may further comprise the list of device IDs. The method may further comprise sending the common privacy management configuration to a privacy management system.

In an embodiment of any of the above two aspects, the method may further comprise updating members of the group. For example, a first terminal device may be added into the group, or a second terminal device may be removed from the group. The method may further comprise sending the updated group to the identity management system.

In an embodiment of any of the above two aspects, the method may further comprise updating the common privacy management configuration for the group. The method may further comprise sending the updated common privacy management configuration to the privacy management system.

FIG. 37 is a block diagram illustrating an apparatus suitable for use in practicing some embodiments of the disclosure. For example, any one of the privacy management system, the identity management system, the administration device, the application server, the device ID server, the target terminal device, the API server, the provisioning system and the subscription management system described above may be implemented through the apparatus 3700. As shown, the apparatus 3700 may include a processor 3710, a memory 3720 that stores a program, and optionally a communication interface 3730 for communicating data with other external devices through wired and/or wireless communication.

The program includes program instructions that, when executed by the processor 3710, enable the apparatus 3700 to operate in accordance with the embodiments of the present disclosure, as discussed above. That is, the embodiments of the present disclosure may be implemented at least in part by computer software executable by the processor 3710, or by hardware, or by a combination of software and hardware.

The memory 3720 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memories, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories. The processor 3710 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multi-core processor architectures, as non-limiting examples.

Based on the above description, the present disclosure also provides a computer program product. The computer program product may comprise instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above method embodiments.

In addition, the present disclosure also provides a computer readable storage medium. The computer readable storage medium may store thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of the above method embodiments.

FIG. 38 is a block diagram illustrating a privacy management system according to an embodiment of the disclosure. As shown in FIG. 38, the privacy management system 3800 may comprise a reception module 3802, a checking module 3804 and a sending module 3806. The reception module 3802 may be configured to receive, from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. The checking module 3804 may be configured to check whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices. The sending module 3806 may be configured to send, to the requesting entity, a sixth response comprising a result of the checking.

FIG. 39 is a block diagram illustrating an identity management system according to an embodiment of the disclosure. As shown in FIG. 39, the identity management system 3900 may comprise an obtaining module 3902, a sending module 3904 and a reception module 3906. The obtaining module 3902 may be configured to obtain a target device ID identifying a target terminal device and a target group ID identifying a target group that the target terminal device belongs to. The sending module 3904 may be configured to send, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise the target device ID, the target group ID, and a target application ID identifying the target application. The reception module 3906 may be configured to receive, from the privacy management system, a sixth response comprising a result of the checking.

FIG. 40 is a block diagram illustrating an administration device according to an embodiment of the disclosure. As shown in FIG. 40, the administration device 4000 may comprise a sending module 4002 and a reception module 4004. The sending module 4002 may be configured to send, to a privacy management system, a fifth request for providing a grant of a common privacy management configuration to a group of terminal devices. The common privacy management configuration may comprise a group ID identifying the group and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group. The reception module 4004 may be configured to receive a fifth response from the privacy management system.

FIG. 41 is a block diagram illustrating an application server according to an embodiment of the disclosure. As shown in FIG. 41, the application server 4100 may comprise a sending module 4102 and a reception module 4104. The sending module 4102 may be configured to send, to an identity management system, an eleventh request for obtaining an access token for a target terminal device. The reception module 4104 may be configured to receive, from the identity management system, an eleventh response comprising the access token of the target terminal device. The access token of the target terminal device may comprise a claim indicating a target group that the target terminal device belongs to.

FIG. 42 is a block diagram illustrating a device ID server according to an embodiment of the disclosure. As shown in FIG. 42, the device ID server 4200 may comprise a first reception module 4202, a first sending module 4204, a second reception module 4206, a generation module 4208 and a second sending module 4210. The first reception module 4202 may be configured to receive, from a target terminal device, a twelfth request for obtaining an ID token of a target terminal device. The first sending module 4204 may be configured to send, to an identity management system, a ninth request for obtaining a target group that the target terminal device belongs to. The ninth request may comprise a target device ID identifying the target terminal device. The second reception module 4206 may be configured to receive, from the identity management system, a ninth response comprising a target group ID identifying the target group. The generation module 4208 may be configured to generate an ID token for the target terminal device. The ID token may comprise the target group ID. The second sending module 4210 may be configured to send a twelfth response comprising the ID token of the target terminal device to the target terminal device.

FIG. 43 is a block diagram illustrating a target terminal device according to an embodiment of the disclosure. As shown in FIG. 43, the target terminal device 4300 may comprise a sending module 4302 and a reception module 4304. The sending module 4302 may be configured to send, to a device ID server, a twelfth request for obtaining an ID token of the target terminal device. The reception module 4304 may be configured to receive, from the device ID server, a twelfth response comprising the ID token of the target terminal device. The ID token may comprise a target group ID identifying a target group that the target terminal device belongs to.

FIG. 44 is a block diagram illustrating an API server according to an embodiment of the disclosure. As shown in FIG. 44, the API server 4400 may comprise a sending module 4402 and a reception module 4404. The sending module 4402 may be configured to send, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device. The sixth request may comprise a target device ID identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application. The reception module 4404 may be configured to receive, from the privacy management system, a sixth response comprising a result of the checking. The modules described above may be implemented by hardware, or software, or a combination of both.

As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one skilled in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA) , and the like.

References in the present disclosure to “one embodiment” , “an embodiment” and so on, 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 implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It should be understood that, although the terms “first” , “second” and so on 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. 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 the disclosure. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. 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, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. The terms “connect” , “connects” , “connecting” and/or “connected” used herein cover the direct and/or indirect connection between two elements. It should be noted that two blocks shown in succession in the above figures may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-Limiting and exemplary embodiments of this disclosure.

Claims

A method at a privacy management system, the method comprising:

receiving (924) , from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises a target device identifier, ID, identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application;

checking (926) whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices; and

sending (928) , to the requesting entity, a sixth response comprising a result of the checking.
The method according to claim 1, further comprising:

receiving (1002) , from an administration device, a first request for creating the group of terminal devices to which the common privacy management configuration can be granted;

sending (1004) , to an identity management system, a second request for creating the group;

receiving (1006) , from the identity management system, a second response comprising a group ID identifying the group; and

sending (1008) , to the administration device, a first response comprising the group ID.
The method according to claim 2, further comprising:

receiving (1110) , from the administration device, a third request for indicating members of the group or adding a first terminal device into the group, wherein the third request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device;

sending (1112) , to the identity management system, a fourth request for indicating the members of the group or adding the first terminal device into the group, wherein the fourth request comprises the group ID, and the list of device IDs or the first device ID;

receiving (1114) a fourth response from the identity management system; and

sending (1116) a third response to the administration device based on the fourth response.
The method according to claims 2 or 3, further comprising:

receiving (1218) , from the administration device, a fifth request for providing a grant of the common privacy management configuration to the group, wherein the common privacy management configuration comprises the group ID and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group;

storing (1220) the common privacy management configuration for the group; and

sending (1222) a fifth response to the administration device.
The method according to claim 4, wherein the common privacy management configuration further comprises one or more of:

a scope indicating which resource or resources associated with the group are allowed to be accessed by the application; and

a purpose indicating a reason why the application needs to access resources associated with the group.
The method according to claim 4, wherein the common privacy management configuration further comprises one or more of:

a scope indicating a scope of service adjustment; and

a purpose indicating a reason why the application needs to perform service adjustment for the group.
The method according to any of claims 1 to 6, wherein the sixth request further comprises one or more of:

a target scope indicating which resource or resources associated with the target terminal device are desired to be accessed by the target application; and

a target purpose indicating a reason why the target application needs to access resources associated with the target terminal device.
The method according to any of claims 1 to 6, wherein the sixth request further comprises one or more of:

a target scope indicating a desired scope of service adjustment; and

a target purpose indicating a reason why the target application needs to perform service adjustment for the target terminal device.
The method according to any of claims 1 to 8, wherein the requesting entity is one of: an identity management system; and an application programming interface, API, server.
The method according to any of claims 2 to 9, further comprising:

receiving (1330) , from the administration device, a seventh request for removing a second terminal device from the group, wherein the seventh request comprises the group ID and a second device ID identifying the second terminal device;

sending (1332) , to the identity management system, an eighth request for removing the second terminal device from the group, wherein the eighth request comprises the group ID and the second device ID; and

sending (1334) a seventh response to the administration device.
A method at an identity management system, the method comprising:

obtaining (1422) a target device identifier, ID, identifying a target terminal device and a target group ID identifying a target group that the target terminal device belongs to;

sending (1424) , to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application; and

receiving (1426) , from the privacy management system, a sixth response comprising a result of the checking.
The method according to claim 11, further comprising:

receiving (1502) , from the privacy management system, a second request for creating a group of terminal devices to which a common privacy management configuration can be granted;

determining (1504) a group ID identifying the group; and

sending (1506) , to the privacy management system, a second response comprising the group ID.
The method according to claim 12, further comprising:

receiving (1608) , from the privacy management system, a fourth request for indicating members of the group or adding a first terminal device into the group, wherein the fourth request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device;

storing or updating (1610) the members of the group; and

sending (1612) a fourth response to the privacy management system.
The method according to claim 13, further comprising: determining (1714) whether the indicated members or the first terminal device is managed by an administrator of the group; and

wherein the members of the group are stored or updated when determining that the indicated members or the first terminal device is managed by the administrator of the group.
The method according to any of claims 11 to 14, further comprising:

receiving (1816) , from a device ID server, a ninth request for obtaining the target group that the target terminal device belongs to, wherein the ninth request comprises the target device ID identifying the target terminal device;

retrieving (1818) the target group ID identifying the target group; and

sending (1820) , to the device ID server, a ninth response comprising the target group ID.
The method according to any of claims 11 to 15, wherein obtaining (1422) the target device ID and the target group ID comprises: determining (1928) the target device ID and retrieving (1930) the target group ID; or

wherein obtaining (1422) the target device ID and the target group ID comprises: sending (1932) , to a device ID server, a tenth request for obtaining the target device ID and the target group ID, wherein the tenth request comprises an ID token of the target terminal device; and receiving (1934) a tenth response comprising the target device ID and the target group ID from the device ID server.
The method according to any of claims 11 to 16, wherein the sixth request further comprises one or more of:

a target scope indicating which resource or resources associated with the target terminal device are desired to be accessed by the target application; and

a target purpose indicating a reason why the target application needs to access resources associated with the target terminal device.
The method according to any of claims 11 to 16, wherein the sixth request further comprises one or more of:

a target scope indicating a desired scope of service adjustment; and

a target purpose indicating a reason why the target application needs to perform service adjustment for the target terminal device.
The method according to any of claims 11 to 18, further comprising:

when the result of the checking indicates that the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, generating (2036) an access token for the target terminal device, wherein the access token comprises a claim indicating the target group; and

sending (2038) the access token to an application server for the target application.
The method according to any of claims 11 to 19, wherein the obtaining (1422) of the target device ID and the target group ID, the sending (1424) of the sixth request, and the receiving (1426) of the sixth response are performed in authentication code flow or client initiated backchannel authentication, CIBA, flow.
The method according to any of claims 12 to 20, further comprising:

receiving (2140) , from the privacy management system, an eighth request for removing a second terminal device from the group, wherein the eighth request comprises the group ID and a second device ID identifying the second terminal device;

retrieving (2142) one or more access tokens each of which comprises a claim indicating the second terminal device and a claim indicating the group; and

revoking (2144) the one or more access tokens.
A method at an administration device, the method comprising:

sending (2210) , to a privacy management system, a fifth request for providing a grant of a common privacy management configuration to a group of terminal devices, wherein the common privacy management configuration comprises a group identifier, ID, identifying the group and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group; and

receiving (2212) a fifth response from the privacy management system.
The method according to claim 22, further comprising:

sending (2302) , to the privacy management system, a first request for creating the group of terminal devices to which the common privacy management configuration can be granted; and

receiving (2304) , from the privacy management system, a first response comprising the group ID.
The method according to claim 22 or 23, further comprising:

sending (2406) , to the privacy management system, a third request for indicating members of the group or adding a first terminal device into the group, wherein the third request comprises the group ID, and a list of device IDs identifying the members of the group or a first device ID identifying the first terminal device; and

receiving (2408) a third response from the privacy management system.
The method according to any of claims 22 to 24, wherein the common privacy management configuration further comprises one or more of:

a scope indicating which resource or resources associated with the group are allowed to be accessed by the application; and

a purpose indicating a reason why the application needs to access resources associated with the group.
The method according to any of claims 22 to 24, wherein the common privacy management configuration further comprises one or more of:

a scope indicating a scope of service adjustment; and

a purpose indicating a reason why the application needs to perform service adjustment for the group.
The method according to any of claims 22 to 26, further comprising:

sending (2514) , to the privacy management system, a seventh request for removing a second terminal device from the group, wherein the seventh request comprises the group ID and a second device ID identifying the second terminal device; and

receiving (2516) a seventh response from the privacy management system.
A method at an application server for a target application, the method comprising:

sending (2602) , to an identity management system, an eleventh request for obtaining an access token for a target terminal device; and

receiving (2604) , from the identity management system, an eleventh response comprising the access token of the target terminal device, wherein the access token of the target terminal device comprises a claim indicating a target group that the target terminal device belongs to.
The method according to claim 28, wherein the sending (2602) of the eleventh request and the receiving (2604) of the eleventh response are performed in authentication code flow or client initiated backchannel authentication, CIBA, flow.
A method at a device identifier, ID, server, the method comprising:

receiving (2702) , from a target terminal device, a twelfth request for obtaining an identifier, ID, token of a target terminal device;

sending (2704) , to an identity management system, a ninth request for obtaining a target group that the target terminal device belongs to, wherein the ninth request comprises a target device ID identifying the target terminal device;

receiving (2706) , from the identity management system, a ninth response comprising a target group ID identifying the target group;

generating (2708) an ID token for the target terminal device, wherein the ID token comprises the target group ID; and

sending (2710) a twelfth response comprising the ID token of the target terminal device to the target terminal device.
A method at a target terminal device, the method comprising:

sending (2802) , to a device identifier, ID, server, a twelfth request for obtaining an ID token of the target terminal device; and

receiving (2804) , from the device ID server, a twelfth response comprising the ID token of the target terminal device, wherein the ID token comprises a target group ID identifying a target group that the target terminal device belongs to.
A method at an application programming interface, API, server, the method comprising:

sending (2902) , to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises a target device identifier, ID, identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application; and

receiving (2904) , from the privacy management system, a sixth response comprising a result of the checking.
The method according to claim 32, wherein the sixth request further comprises one or more of:

a target scope indicating which resource or resources associated with the target terminal device are desired to be accessed by the target application; and

a target purpose indicating a reason why the target application needs to access resources associated with the target terminal device.
The method according to claim 32, wherein the sixth request further comprises one or more of:

a target scope indicating a desired scope of service adjustment; and

a target purpose indicating a reason why the target application needs to perform service adjustment for the target terminal device.
The method according to any of claims 32 to 34, further comprising:

receiving (3006) , from an application server for the target application, an ID token of the target terminal device;

sending (3008) , to a device ID server, a tenth request for obtaining the target device ID and the target group ID, wherein the tenth request comprises the ID token of the target terminal device; and

receiving (3010) , from the device ID server, a tenth response comprising the target device ID and the target group ID.
The method according to any of claims 32 to 35, wherein the sending (2902) of the sixth request and the receiving (2904) of the sixth response are performed in client credentials flow.
A privacy management system (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the privacy management system (3700) is operative to:

receive, from a requesting entity, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises a target device identifier, ID, identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application;

check whether the target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, based on a common privacy management configuration granted to a group of terminal devices; and

send, to the requesting entity, a sixth response comprising a result of the checking.
The privacy management system (3700) according to claim 37, wherein the privacy management system (3700) is operative to perform the method according to any of claims 2 to 10.
An identity management system (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the identity management system (3700) is operative to:

obtain a target device identifier, ID, identifying a target terminal device and a target group ID identifying a target group that the target terminal device belongs to;

send, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with the target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises the target device ID, the target group ID, and a target application ID identifying the target application; and

receive, from the privacy management system, a sixth response comprising a result of the checking.
The identity management system (3700) according to claim 39, wherein the identity management system (3700) is operative to perform the method according to any of claims 12 to 21.
An administration device (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the administration device (3700) is operative to:

send, to a privacy management system, a fifth request for providing a grant of a common privacy management configuration to a group of terminal devices, wherein the common privacy management configuration comprises a group identifier, ID, identifying the group and an application ID identifying an application allowed to access resources associated with the group or perform service adjustment for the group; and

receive a fifth response from the privacy management system.
The administration device (3700) according to claim 41, wherein the administration device (3700) is operative to perform the method according to any of claims 23 to 27.
An application server (3700) for a target application, the application server (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the application server (3700) is operative to:

send, to an identity management system, an eleventh request for obtaining an access token for a target terminal device; and

receive, from the identity management system, an eleventh response comprising the access token of the target terminal device, wherein the access token of the target terminal device comprises a claim indicating a target group that the target terminal device belongs to.
The application server (3700) according to claim 43, wherein the application server (3700) is operative to perform the method according to claim 29.
A device identifier, ID, server (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the device ID server (3700) is operative to:

receive, from a target terminal device, a twelfth request for obtaining an identifier, ID, token of a target terminal device;

send, to an identity management system, a ninth request for obtaining a target group that the target terminal device belongs to, wherein the ninth request comprises a target device ID identifying the target terminal device;

receive, from the identity management system, a ninth response comprising a target group ID identifying the target group;

generate an ID token for the target terminal device, wherein the ID token comprises the target group ID; and

send a twelfth response comprising the ID token of the target terminal device to the target terminal device.
A target terminal device (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the target terminal device (3700) is operative to:

send, to a device identifier, ID, server, a twelfth request for obtaining an ID token of the target terminal device; and

receive, from the device ID server, a twelfth response comprising the ID token of the target terminal device, wherein the ID token comprises a target group ID identifying a target group that the target terminal device belongs to.
An application programming interface, API, server (3700) comprising:

at least one processor (3710) ; and

at least one memory (3720) , the at least one memory (3720) containing instructions executable by the at least one processor (3710) , whereby the API server (3700) is operative to:

send, to a privacy management system, a sixth request for checking whether a target application is allowed to access resources associated with a target terminal device or perform service adjustment for the target terminal device, wherein the sixth request comprises a target device identifier, ID, identifying the target terminal device, a target group ID identifying a target group that the target terminal device belongs to, and a target application ID identifying the target application; and

receive, from the privacy management system, a sixth response comprising a result of the checking.
The API server (3700) according to claim 47, wherein the API server (3700) is operative to perform the method according to any of claims 33 to 36.
A computer readable storage medium storing thereon instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 36.