Methods and apparatuses for managing a subscription to at least a first application programming interface

Abstract

Embodiments described herein relate to methods and apparatuses for managing subscription to at least a first API dealing with privacy sensitive data provided by the API service provider, the API service provider having access to a plurality of privacy policy templates, wherein each privacy policy template comprises one or more values for a plurality of parameters comprising: an application context parameter, a purpose parameter, a data scope parameter a legal basis parameter. A method performed by an API service provider may comprise: receiving a subscription request to subscribe an application to a first API provided by the API service provider, wherein the application is associated with at least one first application context at the API service provider; and obtaining one or more suitable privacy policy templates from the plurality of privacy policy templates, wherein the one or more suitable privacy policy templates each comprise values for the plurality of parameters that correspond to the at least one first application context, one or more first data scopes and one or more first purposes; and selecting a first privacy policy template from the one or more suitable privacy policy templates; creating a first privacy policy from the first privacy policy template for use with the application, wherein the first privacy policy is associated with a first legal basis.

Description

[0001]METHODS AND APPARATUSES FOR A SUBSCRIPTION TO AT LEAST A FIRST APPLICATION PROGRAMMING INTERFACE TECHNICAL FIELD Embodiments described herein relate to methods and embodiments for managing subscriptions to and enabling access to information over one or more Application Programming Interfaces (APIs). BACKGROUND Service providers engage in making network information as well as subscriber and / or device information available via APIs for consumption in applications. Applications use this information to implement different use cases, e.g. fraud prevention.When service providers expose personal data via APIs, in Europe (EU) they fall underthe regulations of General Data Protection Regulation (GDPR). In other jurisdictions, other legal frameworks apply. GDPR introduces a legal framework for managing privacy sensitive data in general. This framework is especially applicable for the privacy sensitive data about users and their subscriptions with service providers. GDPR introduces, amongst many others, the terminologies like -Controller- Processor- Data subject- Processing justification (called legal basis in the subsequent document)Extracted from GDPR art 4 GDPR – Definitions:- ‘controller’ means the natural or legal person, public authority, agency or otherbody which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law- ‘processor’ means a natural or legal person, public authority, agency or otherbody which processes personal data on behalf of the controller -processing justification - means for any processing activity of personal data, itis required to identify one or more valid ground(s) under the GDPR – known as a'lawful Basis / legal basis’ – to justify the collection, use and other forms ofprocessing of personal data Service providers act as controllers of privacy sensitive data, which is owned by theirsubscribers (for example, a data subject in the subsequent document). An example forthe privacy sensitive data is name and address of the user, device location or even the device roaming status.Consent management is the collection of all processes related to the obligations of thedata controller with regards to managing personal data.Camara (A Telco Global API Alliance) as well as GSMA OPG (Operator Platform Group)are discussing the need for a central consent management function, eventually provided on the service exposure platform of the service provider. 3GPP has addressed storage of consent data related to 3GPP network services anddescribed this in TS 33.501, Annex V, but has not addressed the needs for privacysensitive data management in general.The owner of the personal data may be required to give consent to the data controllerallowing him to make privacy sensitive data available for external processing, which inturn means that the data controller may be required to collect the user’s (e.g. datasubject’s) permission for making data available and evaluate the permission beforemaking the data available to a data processor. This processing may be required to havea clearly specified context (e.g., indicated by the application), a purpose and a confineddata scope. In addition, the controller may be required to be able to report on the consentapplied when granting access to the data to a data processor. 3GPP Initiated by GSMA Open Gateway, TM Forum is engaging in defining a suite of APIS (TMF 931, a.k.a. Operate APIs), which allow to register purpose and data scope, when an application registers as API consumer of a certain API. The terminology of Attribute Based Access Control (ABAC) is applied to describe and illustrate the mechanisms of implementing consent constraint support. Policy Information Point (PIP) term denotes a logical function which is called to derive comparison input for consent constraint from the API invocation context. Policy Enforcement Point (PEP) term denotes a logical function, which is called to evaluate consent constraints by comparing them against the context specific input data. SUMMARY As envisioned in the TM Forum 931 Open Gateway Onboarding and Ordering Component suite, Applications will subscribe to APIs via ordering API products. As part of this order a list of data scopes and a purpose for accessing the data scopes can bespecified. If the data scope refers to privacy sensitive data, consent managementbecomes applicable, sometimes mandatory.However, it is not possible to specify the correct legal basis from outside. It is also notpossible to correctly derive the legal basis just out of purpose and data scope informationduring or after the registration process. Only option today is to have a manual process executed by a legal responsible and configure the applicable legal basis. No proper automation is possible. There is no mechanism defined to allow configuring legal basis and consent mode (opt- in or opt-out) upfront, which is applicable to the triplet of application context, purpose, and data scope. This information is needed, since a data controller may be required to secure consent evaluation before exposing PII (Personally Identifiable Information) toprocessor and may be required to be able to explain the subject-matter of processing(given by the application context), the purpose of the processing as well as the type of personal data and categories of data subjects. It is not clear how the consent management processes should identify and handle theright to object (a.k.a. opt-out) for legal basis “legitimate interest” and “public interest”.Capturing user consent is an unspecified process, most of the time driven by applications and only rarely driven by the service providers acting as data controllers. Prerequisite for an efficient and user-friendly consent collection process is awareness of which data scopes (especially privacy sensitive data scope) for which reason is intended to be accessed by and application. This information is not maintained by service providers acting as data controllers yet. With regards to more specific consent management:Today a user (e.g. a data subject) is asked to give his consent to a data controller forexposing a certain data scope for a certain purpose to a data processor for being usedinside application logic. It is not possible to give further restrictions / constraints, e.g., thatthe data exposure may be required to only happen during office hours or that the dataexposure may be required to only happen if the data subject is in a certain country.As a consequence, it is almost impossible to support use cases, where the consent by the target device owner ( / device whose privacy data is being accessed) is given to a subset of users of an application in case multiple users have access to this application. There is currently no mechanism available for defining the possible deviations of data privacy handling rules applicable to a “home” service provider providing API exposure to applications and the data privacy rules applicable to the potential visiting service provider where a user might be roaming. According to some embodiments there is provided a method, performed by an API service provider, for managing subscription to at least a first API dealing with privacy sensitive data provided by the API service provider, the API service provider having access to a plurality of privacy policy templates, wherein each privacy policy template comprises one or more values for a plurality of parameters comprising: an application context parameter, a purpose parameter, a data scope parameter a legal basis parameter. The method comprises receiving a subscription request to subscribe an application to a first API provided by the API service provider, wherein the application is associated with at least one first application context at the API service provider; and obtaining one or more suitable privacy policy templates from the plurality of privacy policy templates, wherein the one or more suitable privacy policy templates each comprise values for the plurality of parameters that correspond to the at least one first application context, one or more first data scopes and one or more first purposes; and selecting a first privacy policy template from the one or more suitable privacy policy templates; creating a first privacy policy from the first privacy policy template for use with the application, wherein the first privacy policy is associated with a first legal basis. According to some embodiments there is provided a method, performed by an API service provider, for enabling an application to expose information over at least a first API provided by the API service provider. The method comprises obtaining consent from the first user to allow the application to access information over the first API, wherein the consent is associated with at least one consent constraint attributes; responsive to receiving a request from the application to access the first API for a first user, obtaining constraint context information corresponding to the at least one consent constraint attributes; comparing the constraint context information to the at least one consent constraint attributes; and responsive to the constraint context information complying with one or more consent rules, allowing the application access to the first API for the first user. According to some embodiments there is provided an API service provider comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the API service provider is operable to perform any of the methods described above. According to some embodiments there is provided a computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any of the methods described above. According to some embodiments there is provided a carrier containing the computer program as described above, wherein the carrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.According to some embodiments there is provided a computer-readable mediumcomprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any of the methods described above. According to some embodiments there is provided a computer program product comprising non transitory computer readable media having stored thereon a computer program as described above. BRIEF DESCRIPTION OF THE DRAWINGS For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which: Figure 1 illustrates an API service provider according to some embodiments;Figure 2 is a signalling diagram illustrating a possible process for configuring the pluralityof policy templates at the API service provider; Figure 3 is a flowchart illustrating a method performed by an API service provider, for managing subscription to at least a first API provided by the API service provider;Figure 4 is a flow chart illustrating an example of how to select the respective first privacypolicy templates when an application registers for an API; Figure 5 is a signalling diagram illustrated an example implementation of the method of Figure 3; Figure 6 is signalling diagram illustrating an example of how an application may be registered with a API service provider; Figure 7 illustrates an example of a consent capture process; Figure 8 illustrates an example implementation of one or more steps relating to consent capture;Figure 9 illustrates a method, performed by an API service provider, for enabling anapplication to expose information over at least a first API provided by the API service provider;Figure 10 illustrates a final constraint policy enforcement in the API server, with anoptional prior partial policy enforcement in the API Gateway, mainly applicable to time constraints; Figure 11 illustrates a final constraint policy enforcement in Consent Management, with an optional prior partial policy enforcement in the API Gateway, mainly applicable to time constraints; Figure 12 is a signalling diagram illustrating an example of API Invocation involving consent constraints; Figure 13 illustrates an example of how evaluation of consent constraints may be performed; Figure 14 is a flow chart illustrating an example of how consent constraints and related consent rules may be configured. Figure 15 illustrates an API service provider 1500 comprising processing circuitry (or logic) 1501. DETAILED DESCRIPTION Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description. The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well- methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and / or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface may have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as (ROM, EEPROM, Flash memory, a memory disc, RAM etc.) solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and / or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. Particular embodiments are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Embodiments described herein address the needs of applications to interacting with acentral consent management function which may supervise access to privacy sensitivedata that the application is interested in. The privacy sensitive data may be owned by anindividual and controlled by a service provider operator, who needs to acquire the user’s permission for making this data available to an external application. The interaction regarding the privacy data may occur via an API. Before an interaction via an API, the application service provider may be required to check whether the owner of the data has given permission. Some embodiments described herein address the needs of a more detailed user consent management for allowing a service provider (e.g., a telecommunications service provider) to expose personal data or allow operations on personal data, which is owned by the user and controlled by the service provider, to a data processor, e.g., an application service provider running an application function. Some aspects of some embodiments described herein are listed below: 1) Policy templates allow to configure legal aspects, which drive the consentmanagement functionality. 2) Policy templates relate application contexts, data scopes, purpose for processingwith a consent mode and a legal basis giving the processing justification. a. Privacy Policy templates may be extended with configuration of consentconstraints, now allowing for much more specific consent handling. b. Privacy policy templates may also be configured with different networkcontexts (e.g. home or visitor service providers).3) An application context can be a specific application, a group of applications,applications of a certain type, applications provided by a certain business (e.g. application service provider or vertical industry), any other grouping mechanism suitable for generic application classification or wildcard for all applications. 4) Policy templates can be related to contract contexts represented by contracttypes or contract groups. 5) Multiple policy templates can be configured for a contract type, data scope andpurpose combination and prioritized for different application contexts. 6) Policy templates may be related to network contexts represented by lists ofservice provider / Network identifications, for example, identified by Public LandMobile Network (PLMN)-Ids (e.g. as specified in 3GPP TS 23.003) 7) When an application subscribes for an API usage, one or more policy templatesmatching the data scope and purpose combinations (and optionally the network context) will be picked, 8) The “legal basis” and “consent mode” settings inherited or overwritten from thepolicy template will drive consent management processes.9) The applicable consent constraints can be overridden in the application specificprivacy policy instances. 10) Consent constraints are populated during the explicit consent collection from auser / data subject / legal responsible of the data subject, or can also be populated by means of contract or pre-configuration. 11) Whenever a consent check may be required to happen, the applicable applicationprivacy profile may be determined based on the consent context (determined from the target resource of the API call) and the network context (determined from the current network the user is located in). 12) Context specific comparison input is retrieved from API implementation or fromconsent management, acting as policy information points (PIPs). 13) Consent constraints are enforced from API gateway for very generic constraints,from API implementation or from consent management service implementation, acting as policy enforcement points (PEPs). 14) When the API implementation acts as policy enforcement point, it may berequired to collect all input data from the different policy information pointsconfigured for the various consent constraints. This could be the API itself for API related constraint data or a generic PIP for non API related data. 15) When consent management acts as policy enforcement point, it will be triggeredfrom the API implementation. The API will collect all API related input data for constraint comparison and send this to consent management. The consent management function will collect the input from generic PIP for non API related data.Figure 1 illustrates an API service provider 100 according to some embodiments. In thisexample, the API service provider comprises an application registration function 102, a privacy policy function 104 and a consent management function 106. Figure 1 further illustrates the interaction of the logical entities of the API service provider 100 with external functions during consent management related processes.Prior to an application 108 (which is operated by an application service provider 110)subscribing to an API 112, a plurality of policy templates may be prepared and configuredat the API service provider 100. The plurality of policy templates may be stored at theprivacy policy function 104 of the API service provider 100.The plurality of policy templates may the legal basis (for processing accordingto a legal framework, e.g., GDPR) and, in some examples, the consent mode (opt-in,opt-out, automatic) against one or more of the following criteria: application context, datascope (eventually exposed by APIs), purpose for processing the data and an optional contract context. The application context can be a specific application, but also a group of applications e.g., applications of a certain type, applications provided by a certain application provider or an enterprise or any other grouping mechanism suitable for generic application classification. The contract context can be a contract type (like consumer contract or enterprise contract) or a contract grouping, e.g., all contracts owned by an enterprise. It will be appreciated that the plurality of privacy policy templates may be configured to comply to the legal regulations of a jurisdiction which is applicable for the data controllerand data processor. It will also be appreciated that different privacy policy templates maybe configured to apply to different jurisdictions.In addition, the privacy policy templates allow for specifying if certain consent constraintsare required in the API / data scope for a certain purpose. The concept of consent constraint will be described in more detail later with reference to Figures 9 to 14. In some embodiments one or more of the privacy policy templates may be configured for a home service provider, and one or more other privacy policy templates may be configured for one or more visitor service providers, in order to address roaming scenarios. This may be beneficial if the legal rules (e.g. the policies) applicable to the visitor service provider deviate from the rules (e.g. policies) of the home service provider. The plurality of privacy policy templates may be utilised to support the automateddetermination of consent management relevant information, for example, during theregistration of applications for API consumption. Each privacy policy template may comprise one or more values for a plurality of parameters comprising: an application context parameter, a purpose parameter, a data scope parameter and a legal basis parameter.The triplet of the values for the context parameter, the purpose parameterand the data scope parameter, once applied, may be used to drive various consentmanagement processes according to the associated legal basis parameter in the privacypolicy template, from which a consent mode may be derived. In some examples, aconsent mode parameter may also be included within the privacy policy template. In some embodiments, each privacy policy template may further comprise a contract context parameter. When leveraging this contract context parameter, e.g., contract typeas one incarnation of a contract context parameter, it may be required that a policytemplate can be found for each contract context type defined in the system which is a linked to a potential target resource of privacy data exposure.To achieve this, it may be useful to configure a catch all entry (without specifying acontract context) and then provide privacy policy template for explicit contract contextswhere needed. In other words, a catch-all privacy policy template may comprise wildcardvalue for the contract context parameter.The table below indicates an example of possible parameters comprised within a privacypolicy template. It will be appreciated that not all of the listed parameters are required. Property DescriptionApplicationContextType An individual application or combination of the different grouping mechanisms listed below: –“wildcard” – all applications– application type (e.g. generic, self service, banking,etc.) –applications for an enterprise,– applications from an ASP– applications from the service provider– individual grouping of applicationsApplicationContext Identifier of application context, e.g. application ID orapplicationProviderID etc ContractContextType One of the grouping mechanisms listed below:– <Empty>– contractType– contractOwnerReferenceCaveat: It may be required to be assured that anapplicable entry can be found for a “data subject / target resource” of an API invocation.ContractContext Identifier of context, e.g. “consumer” ascontract type or customerID as contractOwnerReference; is <empty> in case of unspecified contract context typeNetworkContextType Type of network context,Permitted values: -ALL – all networks- HOME – home network or home country / homeregion OTHER – list of other countries or networksNetworkContext List of Country Identifiers or Network Identifiers (e.g. as listof pairs MCC+MNC as specified in TS 23.003) if NetworkContextType is not “ALL”Purpose Purpose for accessing a certain data scopeData scope / data scope Indicates a set of information elements and / or operations group on it to limit an application’s access to resourcesLegal Basis Processing justification, e.g. according to GDPR “Explicitconsent”, “Legal obligation”, “Contractual obligation”, “Legitimate interest of the organisation”, “a public interest”, “a vital interest” For supporting further generic treatment in case of user roaming while using applications in certain networks, an additional value “NO_ACCESS” to avoid API invocation isadded.Consent Mode Opt-in: user required give explicit consent, Opt-out: userhas right to object, automatic: consent by default, cannot be revokedConsent Constraints Json schema (or reference to Json schema) for potentialconsent constraints, to be pre-configured or collected from user, e.g., limiting the user consent to a certain time of day or countryValid From Validity date of templateState draft, active, inactiveState_date Date of state changePriority Optional; either priority-based sorting or hierarchy basedIf priority-based sorting is used, the Priority number may be unique amongst all entries for same purpose and data scope / data scope group pairThe plurality of privacy policy templates be pre-configured for generic applicationcontexts (such as catch all context or, an app type or app group) by a service provider and may provide the default legal basis and default consent mode as well as a potential consent constraint definition for a triplet of application context, purpose, data scope / data scope group. For example, a catch-all privacy policy template may comprise a wildcard value for the application context parameter. Role of contract context parameter The value of the contract context parameter comprises information, which will be used at consent capture and API invocation time. The subject identifier (e.g. the MSISDN), isused to locate the data subject (resource owner) of a resource, subject to an API call, isalso used to determine the contract context. In other words, it will be understood whichcontract (e.g. individual, enterprise etc) applies to a particular subject.The value of the contract context parameter may be used as input in the followingscenarios: -for finding the applicable application privacy policies during consent capture (seealso Figures 7 and 8 and the associated description) -at API invocation time, allowing consent management to determine the legalbasis and consent mode for the triplet of (application, purpose and scope). Consent management may then perform a lookup into the consent registry using this the contract context parameter.Role of application context parameterFor one individual application, multiple application context parameter values may be validwhich in turn means that multiple privacy policy templates could be applicable.In this case, a selection logic amongst the different privacy policy templates may be usedwhen an application subscribes to an API (for example as described with reference to Figures 3 to 5). The selection will happen within the list of suitable privacy policytemplates associated with a particular contract context parameter value. The aim maybe to find the most suitable privacy policy templates for the different values of the contractcontext parameter that are configured. One option is to implement an explicit based on a configured priority. Another option is to implement a hierarchy-based sorting on the different application contexts (application, applications groups etc.). Role of network contextFor one individual application, multiple network context parameter values may be validwhich in turn means that multiple privacy policy templates could be applicable.In this case privacy policy templates for the different network contexts may be selectedand instantiated at application level. It may be assured that a catch-all configuration is available in addition to more specific configurations for certain countries, regions or networks. At API invocation time, consent management may determine the legal basis and consent mode for the triplet of (application, purpose and scope). If multiple configurations for different network contexts are available, Consent management may then check whether the user is roaming and pick the applicable configuration if there is a specific configuration for the visited network. If there are multiple privacy configuration for an application for different network contextsas well as different contract contexts the selection logic may consider the legal demandsfirst. Thus, selecting the configuration for the current network context may occur prior to selecting the contract context. Multiple Privacy Policy Templates Supporting multiple privacy policy templates for an application by means of multiple application contexts and contract contexts allows to configure catch all settings, which may, for example, apply the most secure privacy data handling (e.g. may require opt-in in the consent mode) and overwrite them by more specific settings for certain applications and application groups. In parallel, it is possible to support different configurations for different values of contract context parameter for the same triplet of application context, purpose, and data scope. This will allow to adjust the consent application configuration for different customer types or even individual customers. An example is given in the table below: Privac App App Contrac Contract Netwo Netwo purpos Data Legal Cons … y conte contex t Context rk rk e scope base ent Policy xt t type Context type Conte Conte mode templ xt xt ate id Refere type nce 1geneappTy Consum ContractALL purposdataScoConsent optInric pe er type e1 pe1 2asp1 aspReEnterpri ContractALL purposdataScoConsent optInf se type e1 pe1 3app1 appReConsum ContractALL purposdataSco Legitim optO f er type e1 pe1 ate ut Interest 4geneappTy12345 Customer ALL purposdataSco Contrac optIn ric pe ID e1 pe1 t 5geneappTygeneric 26201 OTHEpurpos dataSco Legitim optO ric pe R e1 pe1 ate ut Interest 6app1 appRe generic 26201 OTHEpurpos dataScoConsent optInf R e1 pe1 … Privacy Policy Template configuration sequenceFigure 2 is a signalling diagram illustrating a possible process for configuring the pluralityof policy templates at the API service provider 100.The system illustrated in Figure 2 comprises an API developer 240, a product manager250, a legal responsible 260, and an API service provider 100. The API service provider100 comprises an API management 270, an application management 280 and a privacypolicy template management 290.In step 200, the API developer 240 an API with the API service provider 100(e.g. the API management 270).In step 202, the API developer 240 defines API data scopes with the API service provider100 (e.g. the API management 270).In step 204, the product manager 250 defines supported purpose and data scopecombinations per API with the API service provider 100 (e.g. the API management 270).As illustrated by block 206, the product manager 250 defines a subset of supportedpurposes for data scopes on API invocation.In step 208, the legal responsible 260 sends a getNewAPIs(registrationDate<inputDate)message to the API service provider 100 (e.g. the API management 270).In step 210, the API service provider 100 (e.g. the API management 270) returns a listof APIs to the legal responsible 260.In step 212, the legal responsible 260 sends a generateDefaultPrivacyPolicyTemplates(apiList) message to the API service provider 100 (e.g. the privacy policy template management 290).In step 214, the privacy policy template management 290 executes a create defaulttemplate function, createDefaultTemplate(AppType=”generic”, appGroup=<empty>, contractContextType=<empty>, purpose=”purpose”, data_scope, legalBasis=consent, consentMode=”optIn”, consentconstraints=<empty>, status=”draft”. Step 214 is carried out in a loop over all APIs in a list (e.g. apiList). In step 216, the API service provider 100 (e.g. the privacy policy template management290) presents a default template list message to the legal responsible 260.In step 218, the legal responsible 260 sends a selectTemplate (template 1) message tothe API service provider 100 (e.g. the privacy policy template management 290).In step 220, the legal responsible 260 sends a copyTemplate (template 1) message tothe API service provider 100 (e.g. the privacy policy template management 290).In step 222, the legal responsible 260 sends an updateTemplate(template1, appType,purposeValue, legalBasis, consentMode, consentConstraints) message to the APIservice provider 100 (e.g. the privacy policy template management 290).As illustrated in block 224, the API name, API version and data scope is inherited from the API registration and may not be changed. The purposeValues are provided byProduct Management team as well as consent constraints (and optionally networkcontexts), if these are to be supported. The possible contract types are provided by Product Management and / or Customer Management staff. The legal responsible may configure the applicable legal basis for the purpose and data_scope combinations. The possible consent mode (opt-In, opt-Out, automatic) depends on the legal basis. Thepossible consent constraints may be supported by consent management or therespective services. Whether consent constraints should be used may be decidedbetween product Management and legal responsible. Example: Employee gives consent to locate his device only during work hours.In step 226, the legal responsible 260 sends a changeStatus (“active”) message to theAPI service provider 100 (e.g. the privacy policy template management 290).Steps 216, 218, 220, 222, 224 and 226 are performed in a loop to configure templates. Steps 220, 222, 224 and 226 are performed in a (nested) loop for each purpose and contract context to be supported. It will be appreciated that further nested loops may be included for network contexts to be supported. In this example, a legal responsible may use information from an API developer aboutthe API to be registered together with a received input relating to purposes (E.g. from aproduct manager), contract types and eventual consent constraints to configure the plurality of privacy policy templates.The legal responsible may trigger the of a set of default privacy policy templatesfrom the APIs, which are then copied and adjusted (step 212 of Figure 2) to generateother privacy policy templates (steps 218 to 226 of Figure 2).Different privacy policy templates may be configured for each purpose and scope combination, which may then be supported for API registration. Legal basis and consentmode may be configured within each privacy policy template. A default configuration maybe provided for each purpose and scope pair realized by configuring a privacy policy template for purpose and scope pair, “catch-all” application context, “catch-all” networkcontext, and “catch-all” contract context settings.Furthermore, specific policy templates may then be configured for specific application contexts (e.g. application type, application group) or contract contexts (e.g. contract type) In addition, the configuration of different privacy treatment for different networks contextscan be provided. However, this may only be required if stronger, more restricted privacytreatment, deviating from the privacy handing of the home network is required by thevisitor network.The steps 218 to 226in Figure 2 illustrate a potential configuration sequence for pre-configuring the plurality of privacy policy templates at the API service provider. It will beappreciated that in some examples network context may also be taken into account (e.g.by utilizing a further nested loop) when configuring the plurality of privacy policytemplates. Network context considerations have not been included in Figure 2. When an application subscribes to an API (after having been registered with the API service provider, as will be described in more detail with reference to Figure 6), it may be required to specify a data scope or a subset of data scopes exposed by the API, which the application is interested in exposing. In addition, the application may be required to convey the purpose for processing these data scopes which deal with personally identifiable information (PII).During this subscription process all suitable policy templates are picked, which matchthe application context (derived from the application), the data scope and purpose combinations. As previously mentioned there may be multiple matching policy templatesfor different contract contexts and / or network contexts. The policy templates will specifythe legal basis applicable by default for this combination of contract context, (optionally network context), application context, purpose and data scope. There is the option to override the legal basis on application subscription level. Once the plurality of privacy policy templates are configured at the API service provider, the system may be able to drive consent management processes for consent capture and consent evaluation in line with the legal framework appliable for the respective jurisdiction: ^Consent reference data APIs may expose the application specific consent relatedconfiguration and can be used to build consent capture functionality, which is application specific or addresses all applications, which have registered. ^When the application / API invoker requests an access token for a purpose and alist of data scopes related to a resource identified by a UE identifier, the contract context may be determined out of the UE identifier and used to select the applicable privacy policy. If multiple privacy policies exist due to configurationsfor additional network contexts on top of the home network, the system may check whether the user is roaming (and in which network) to determine the correct application privacy policy. ^Depending on the legal basis and consent mode stated in the privacy policy andthe existence or not existence of entries in the consent registry, the consent evaluation process will be able to decide on whether it is necessary to trigger a consent capture process.Figure 3 is a flowchart illustrating a method performed by an API service provider, formanaging subscription to at least a first API provided by the API service provider. As described above, the API service provider may have access to a plurality of privacy policy templates, wherein each privacy policy template comprises one or more values for a plurality of parameters comprising: (optionally, a network context parameter), an application context parameter, a purpose parameter, a data scope parameter and a legalbasis parameter. For example, the plurality of privacy policy templates may have beenconfigured at the API service provider as described in Figure 2.The method of Figure 2 may be performed by an API service provider, for example, theAPI service provider 100 illustrated in Figure 1. The API service provider a physical node, and may be implemented in a computing device or server apparatus and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. It will be appreciated that various steps of the method of Figure 1 may be implemented by the different logical functions of the API service provider, e.g. as illustrated in Figure 1. It will also be appreciated that the different logical functions of the API service provider may be implemented in a distributed computing environment. The suitable privacy policy templates (e.g. as described below with reference to step 302) may be determined when an application subscribes to using a first API with all or a subset of data scopes of the API for a certain purpose.A prerequisite for performing the method of Figure 3 may, in some examples, be that theapplication has been registered and the possible “application contexts” have been determined during this registration process.In step 301, the API service provider receives a subscription request to subscribe anapplication to a first API provided by the API service provider, wherein the application is associated with at least one first application context at the API service provider. In some examples, the at least one first application context may have been received by the API service provider during registration of the application with the API service provider (see for example Figure 6).In step 302, the API service provider obtains one or more suitable privacy policytemplates from the plurality of privacy policy templates, wherein the one or more suitable privacy policy templates each comprise values for the plurality of parameters that correspond to the at least one first application context, one or more first data scopes andone or more first purposes (and optionally network context).For example, a suitable privacy policy template may be a template for which at least one of the values of the application context parameter matches with at least one of the values of the first application context, at least one of the values of the data scope parametermatches with at least one of the one or more first data scopes, and at least one of thevalues for the purpose parameter matches with at least one of the one or more first purposes. Examples illustrating how a privacy policy template may correspond to the at least one first application context, one or more first data scopes and one or more first purposes are given below in the examples section. It will be appreciated that a wildcard value may be considered to match to any other possible value for the associated parameter. In step 301, the application may be considered to be subscribing to the first API for later API invocation by specifying a list of data scopes (provided by the API) and purposes. In some examples, therefore, the subscription request of step 301 further comprises an indication of one or more of: the one or more first data scopes and the one or more first purposes. In some examples, responsive to the subscription request comprising no indication of the one or more first data scopes, the one or more first data scopes comprises a wildcard value. In some examples, responsive to the subscription request comprising no indication of the one or more first purposes, the one or more first purposes comprises a wildcard value. In step 303, the API service provider selects a first privacy policy template from the one or more suitable privacy policy templates. In step 304, the API service provider creates a first privacy policy from the first privacy policy template for use with the application, wherein the first privacy policy is associatedwith a first legal basis taken from the first privacy policy template. For example, the firstprivacy policy template may have the first legal basis as the value for the legal basis parameter. In some examples, the method may then further comprise ensuring that a first consent mode derived from (at least in part) the first legal basis is used by the API service provider when the application calls the first API for a particular data scope in the one or more first data scopes and a particular purpose in the one or more purposes. In some examples, the first privacy policy template may comprise the first consent mode(e.g. opt-in, opt-out or automatic) as the value for a consent mode parameter. As described above, the plurality of of each privacy policy template may further comprises a contract context parameter. In this example, step 303 may comprise for each value of the contract context parameter in the one or more suitable privacy policy templates, allocating a respective first privacy policy template comprising the value of the contract context parameter. In other words, a privacy policy template is allocated to each possible value of the contract context parameter. In order to ensure all potential users (or user types) are covered, it will be appreciated that a catch-all privacy policy (e.g. with the wildcard contract context parameter) may be used for each pair of possible values of the purpose and data scope parameters. This means that this catch-all privacy policy can be used as a default if the user in question does not fall within the contract context scope of any of the other suitable privacy policy templates. In some examples, the step 303 may comprise selecting the first privacy policy template from the one or more suitable privacy policy templates based on a priority process. For example, the selecting of the first privacy policy template, (or selecting the respective first privacy policy template for a respective contract context value), may comprise for each contract context value, the list of suitable privacy policy templates is sorted either using an explicit priority or an implicit priority defined amongst the application context types. In order to search through the suitable privacy policy templates for each contract context value, the suitable privacy policy template may first be ordered by contract context value. Similarly, within each network context, the list of privacy policy templates may be sorted by contract context. Once the suitable privacy policy templates are sorted by network context, contract context value and then within that by priority, the respective first privacy policy templates may be selected as those having the highest priority for each contract context value.Step 304 may be considered to comprise creating an application subscription for theapplication to the first API, and linking the application subscription to the respective first privacy policies created by using the information from the respective first privacy policy templates, especially purpose, data scope, legal basis, and optionally consent mode. In addition, creation date, valid from, valid-to may be added. In some examples, the API service provider may override the legal basis (and consent mode) setting on the application specific privacy policies.In some examples therefore, as a result of the API subscription flow (e,g. as a result ofthe method of Figure 3), one privacy policy template will be selected for an application, a contract context, a purpose and a data scope, indicating the legal basis, the consent mode and eventual consent constraints driving the consent management processes. Privacy Policy Template Selection logic Figure 4 is a flow chart illustrating an example of how to select the respective first privacy policy templates when an application registers for an API.Step 400 is the start of the flow chart. Step 402 is a registration request for API (datascopes, purpose). In step 404, application registration is validated. If not registered, themethod proceeds to step 406. If registered, the method proceeds to step 410.In step 406, the request is rejected. The method then stops in step 408.In step 410, applicable application contexts are retrieved. In step 412, a list of datascopes is determined. In step 414, the following steps are looped over data scopes.Step 416 is a decision as to whether there is a “next data scope”. If the decision is “no”,the method stops in step 418. If the decision is “yes”, the method proceeds to step 420.Step 420 is a decision as to whether the “purpose is wildcard”. If the decision is “yes”, the method proceeds to step 422. If the decision is “no”, the method proceeds to step 438.In step 422, comprises getting a privacy policy having a data scope and a purpose =”*”and all application contexts. Step 424 is a decision relating to whether a “privacy policy templates found”. If the decision is “no”, (i.e. privacy policy templates are not found) the method proceeds to step 426. If the decision is “yes”, (i.e. policy templates are found), the method proceeds to step 430.In step 426, the request is rejected. The method then ends in step 428.Step 430, comprises sorting according to contract context. In step 432, steps 434 and436 are looped over contract contexts. Step 434, comprises sorting privacy policiestemplate for current contract context according to priority of application contexts (default is application used by enterprise, applications provided by ASP, application group,application type). Step 436, comprises allocating privacy policy template with highestpriority for this contract context and return to step 432. After step 432, the method returns to step 414.Step 438, comprises getting a privacy policy for data scope and purpose = “purpose” andall application contexts. Step 440 is a decision on whether such a “privacy policy templateis found. If the decision is “no” (i.e. if such a privacy policy template is not found), themethod proceeds to step 442. If the decision is “yes” (i.e. if such a privacy policy template is found), the method proceeds to step 446.In step 442, the request is rejected. The method then ends in step 444.Step 446, comprises sorting privacy policies templates according to contract context. Instep 448, loop steps 450 and 452 over contract contexts. Step 450, comprises sortingprivacy policies templates for current contract context according to priority of applicationcontexts (default used by enterprise, applications provided by ASP, application type) orconfigured priority. Step 452, comprises allocating privacy policy templates with highestpriority for this contract context and return to step 448. After step 448, the method returns to step 414. It will be appreciated that Figure 4 does not consider network contexts. However, the privacy policy templates may first be sorted by network context, e.g. before sorting bycontract context (in step 446), in case there are matching privacy policy templates fordifferent network context available, and selecting suitable privacy policy templates for each network context available according to the steps 430 to 436 respectively 446 to 452. Figure 5 is a signalling diagram illustrated an example implementation of the method of Figure 3. Figure 5 may be considered to illustrate a process for an application tosubscribe to use an API with a focus on determination of the privacy policy templates,which are applicable to the combination of application, API, selected data scopes andpurpose (e.g. the suitable privacy policy templates).The system illustrated in Figure 5 comprises an App developer 550 and an API service producer 100. The API service provider 100 comprises an API subscription management 560, an ASP management 570, an application management 580 and a privacy policy template management 590. As illustrated in block 500 of Figure 5, an application service provider (ASP) is registered and approved, an application is registered and approved, and required privacy policy templates are created for onboarded / published API service(s).In step 502 of Figure 5, the application developer 550 transmits a request for anindication of APIs available for subscription to the API service provider 100 (e.g. the APIsubscription management function 560). In other words, the application developer 550queries the APIs available for subscription.In step 504 of Figure 5, the API service provider 100 (e.g. the API subscriptionmanagement function 560) transmits an indication of one or more available APIsprovided by the API service provider 100 including (E.g.. at least the first API) to theapplication developer 550. For example, the API service provider 100 (e.g. the APIsubscription management function 560) returns a list of APIs (and their characteristics) available for subscription.In step 504, the application developer 550 subscribes to an API (for example, applicationdeveloper 550 transmits a subscription request to subscribe to the first API). Step 504 ofFigure 5 may be considered to correspond to step 301 of Figure 3. The subscription request comprises an application reference (applicationRef) of the application. As illustrated in Figure 5, the subscription request may include ApiName, [opt]purpose and / or [opt]dataScopes. As illustrated in block 506, while to an API which has data scopes that handle personal data, if no purpose is provided then the API subscription management function 560 will look for a privacy policy template which has wildcard (*) against the purpose,and if no data scopes are provided then privacy policy may be locked for each of thedata scopes handled by the API service.In steps 508 and 510, the API service provider 100 obtains the at least one applicationcontext utilising the application reference (in this example by retrieving the applicationcontext from the Application Management Function 580). For example, API subscriptionmanagement 560 may send a validate application message comprising an application reference (applicationRef) of the application to the application management 580. Application management 580 may return an ApplicationContex comprising applicationServiceProviderRef, appType, appGroup and appApprovalStatus to the APIsubscription management 560. It will be appreciated that the application may have beenregistered with the at least one application context in a previous registering step (see for example Figure 6). As illustrated in block 512, based on application validation, the API service provider 100 can reject subscription for certain APIs by specific applications.Step 514 illustrates how in some circumstances the subscription request may berejected. For example, the API service provider 100 (e.g. the API subscription management 560) may send an API subscription rejected message to the app developer 550. In step 516, the API service provider determines the one or more data scopes (e.g. if they are not provided in the subscription request). For example, the API subscription management 560 determines a list of personal information data scopes if not included in the subscription request.Steps 518 to 524 then indicate how the suitable privacy policies are retrieved, orderedand selected from. For example, as illustrated in Figure 5, step 518 may comprise the API subscription management 560 retrieving a privacy policy (comprising dataScope=”dataScope”, purpose=”*”, and applicationRef=”applicationRef”; or dataScope=”dataScope”, purpose=”*”, and appGroup=”appGroup”; or dataScope=”dataScope”, purpose=”purpose”, appGroup=”appGroup” and so on) to the privacy policy template management 590. Step 520 may comprise the privacy policy template management 590 sending a “privacy policy found” message to the API subscription management 560. Step 522 may comprise the API subscription management 560 sorting a list of privacy policies obtained in a previous step according to contract context. Step 524 may comprise the API subscription management 560 determining, from a list of privacy policies, the privacy policies to be allocated / used for current contract context based on assigned priority or configured hierarchy.Step 526 may comprise the API subscription management 560 allocating the selectedprivacy policy against the dataScope and API subscription for the application. As illustrated in Figure 5, steps 518 and 520 may be looped / repeated for each dataScope, purpose & applicationContext combination. As illustrated in Figure 5, steps 524 and 526 may be looped over contract context. As illustrated in Figure 5, steps 518-526 may be looped / repeated for each dataScope. In step 528, the API service provider 100 (e.g. the API subscription management 560) notifies app developer 550 on application subscription status. It will be appreciated that Figure 5 does not consider network context. However, the loop over contract context may be nested within a loop over each applicable network context in which the list of privacy policies is sorted according to network context and then sorted according to contract context.Example 1 – Illustration of suitable privacy policy templates A banking application MyBankApp to the application group “banking)subscribes for invoking the Device Location, for the data scope “device-location-read”and the purpose “ FraudPrevention”. When the application MyBankApp registers (prerequisite to API subscription), the array of suitable application contexts has been determined (and eventually approved by the service provider), which is {appType,generic}, {applGroup, banking}, {appRef, MyBankApp}.The available privacy policy templates are as below:Privacy App App Contract Contractpurpose DataLegal Conse … Policy context context Context Context scope base nt templat type type mode e id 1generic appTyp * ContractFraudPre device-Consent optIne type vention location- read 2banking applGro Enterprise ContractFraudPre device-Consent optInup type vention location- read 3banking applGro Consumer ContractFraudPre device-Consent optInup type vention location- read 4MyBank appRef Enterprise ContractFraudPre device-Contract optOutApp type vention location- read 5alarm appTyp * ContractProtectio device- legitimateI optOut e type nOfPubli location- nterest cSecurity read … In this example there are three possible contract context values, so three privacy policy templates are selected. Out of the privacy policy templates available (see list below), the templates 1 (for catchall), 3 (for contract context = consumer) and 4 (for contract context = enterprise) will bedetermined as suitable and assigned to the application subscription. In this example, privacy policy template selected over privacy policy template 2 as the application context type of application reference (appRef) is higher priority than the application context type application group (applGroup). Privacy policy template 1 is selected, as the policy template 5 applies for a different purpose to the one being invoked. Application registration Application registration enables an Application Service Provider (ASP) (or an Aggregator on behalf of ASP), to register their Application with an API Service Provider (frequently being a communication service provider (CSP), also operating a communication network) for the purpose of accessing service APIs (such as Quality-on-Demand, Location-Verification) exposed by API Service Providers. Access to APIs may be granted towards individual Application instances and not directly to the ASPs.Hence, once an application is registered with API Service Provider, it may be approvedby Service Provider Administrator (either manually or automatically) before an ASP (or Aggregator on behalf of ASP) can order API Subscriptions for the Applications. An API Service Provider can decide to reject an application based on their internal decision-making process while adhering to local laws and regulations. Example: Gambling applications could be rejected by an API Service Provider in certain countries, there-by effectively ensuring gambling apps can neither order nor access any APIs exposed by that Service Provider. For simplicity Example 1 does not consider network contexts. Application Context handling While approving an application, an API Service Provider may determine the applicable application contexts based on several criteria, such as, 1) Provider of the Application, which could be,^ An Application Service Provider (ASP)^ API Service Provider themselves^ An enterprise, who is also the owner of the devices2) Application type^ Default: generic application,^ Could be provided as input^ Optionally, if required can be overwritten by the API Service Providerduring approval process of app 3) Application Group^ Default: Not assigned^ Example: “Banking”^ Could be provided as input^ Optionally, if required can be assigned or overwritten by the API ServiceProvider during approval process of app 4) Application ID or Application Name (E.g., Applicable for application that issupplied by service provider) 5) Description of the ApplicationThe API Service Provider my allocate all appliable application contexts to the application in the application registry and may define a priority between the applicable application contexts to drive the privacy policy selection (e.g. to drive step 303) at API subscription point in time. The default priority, given by application, application provider, application group, application type, may be overridden on application instance level. Example 2: Configuration of application context priorities An application is onboarded to API service Provider’s platform according to the following information App Name AppASP App Approval App Type Name Group Status Contexts with Priority MyBankApp Generic MyBank PendingApproval When an API Service provider approves this application, as shown in the table below is may optionally set or update the various App Contexts (along with the priority), to steer the selection of a relevant privacy policy when an API subscription is made for this Application. In this example, an additional App Context “App group” was set and then priorities assigned. App Name App Type ASP Name App Group ApprovalApp Status Contexts with Priority (1-Highest) MyBankApp Generic MyBank Banking Approved App Ref(Priority=1), App Group (Priority=2), App Type (Priority=3), ASP Ref (Priority=4) In the example above, while approving the “MyBankApp”, the API Service Provider also groups this application with the “Banking” Application group and sets the various application contexts along with the priority. ^App Ref (Priority=1),^ App Group (Priority=2),^ App Type (Priority=3)^ ASP Ref (Priority=4)This means, when the “MyBankApp” subscribes to an API, while selecting the applicable privacy policies for a certain contract context from the overall list of privacy policy templates, if there are more than 1 privacy policy templates found, then highest priority will be given to the template that has Application Context as AppRef (along with purpose and data scope). Network context has not been considered in this example for simplicity.Example 3: Using application context prioritiesIf “MyBankApp” subscribes to “Device-Location” API and the data scope “Device- Location-READ” for purpose “FraudPrevention”. Then amongst the different privacy policy templates configured for the data scope “Device-Location-READ” and a certain contract context, as described in the table below, it will select the privacy policy template having the higher “AppContext” priority.Note: Not all possible privacy policy template fields (e.g. parameters) are shown belowId App^App^ Contract^ Contract^Purpose Data^Legal^ Context^ Context^ Context Context^ Scope base Value Type Type 1Generic App N / A N / A FraudPrevention Device-Consent Type Location- READ 2MyBank ASP N / A N / A FraudPrevention Device-Consent Ref Location- READ 3Banking App N / A N / A FraudPrevention Device-Consent Group Location- READ 4MyBankApp App Enterprise Contract FraudPrevention Device-Contract Ref type Location- READ 5Alarm App N / A N / A ProtectionOfPublicSecurity Device-Legitimate Type Location- Interest READ In this example, when MyBankApp subscribes to the API Device-Location (for purpose = FraudPrevention and scope Device-Location-READ ) the 2 privacy policies highlighted in grey in the table will get selected. 1. Privacy Policy Template with ID=4, that applies to Enterprise contracts. As thereis an explicit entry for contractType=Enterprise, no other templates apply to Enterprise contracts2. Privacy Policy Template with ID=3, that applies to all other devices with othercontract types. This will be chosen because amongst templates 1, 2, and 3, the template with ID=3 is for appContext=AppRef which was assigned with higher priority when the Application was approved. Note, for ease of representation, only single application context is used in the representation.It is possible to have multiple pairs of {application context type, application context value}defined for a single privacy policy template, like in the table below.Id App^App^ ASP / Ent^ App^ App^Purpose Data^Scope Legal^…. Context^ Name Name Group Type Basis Types Application Context Values1 AppPhysicalBanking FraudPrevention Device-Contract Group + Banks Location- App READ Type2 AppDigitalBanking FraudPrevention Device-Consent Group + Banks Location- App READ Type3 ASP Ref + MyBank Banking FraudPrevention Device-Contract App Location- Type READ4 App Ref Alarm ProtectionOfPublicSecurity Device-Legitimate Location- Interest READ While defining privacy policy templates and specifying App Context Types, it may be beneficial for any App Context Type, which is referred to, to have its value set in the application privacy policy (instance). When for example App Group & App Type are specified (like in the table above), it may be ensured that values for these attributes are collected or configured during application onboarding and promoted to the applicationprivacy policy (instance). The ASP Reference may be available if, for example, this isconsidered the mandatory reference to the application provider. During the approval process at the API service provider, while checking and eventually overriding the privacy policy for that Application’s API subscription, also the priority applied to app contexts against an application can be set. Network context has not been considered in this example for simplicity. Example 4: Selecting Privacy policy template with multiple app contexts If the default App Context Types has following priorities against the application App Ref (Priority=1), App Group (Priority=2), App Type (Priority=3), ASP Ref (Priority=4), then theorder of privacy policy that may be picked in previous table will looks as follows:1. Template with Id=4, because AppRef has highest priority2. Template with Id=1 or Id=2, as App Group has higher priority than App Type(which is used in template with Id=3) and then depending on value for App Group, one of these (1 or 2) will be selected next 3. Template with id=3 will be last one as both App contexts specified in this policyhave least priority compared to App Ref or App Group.Note: It is possible that while approving an application, the API Service Admin does notassign priorities to App Contexts. In that case, while choosing the privacy policy duringAPI subscription, the priority that might be assigned to each individual policies may beconsidered. Network context has not been considered in this example for simplicity. Application registration sequenceFigure 6 is signalling diagram illustrating an example of how an application may beregistered with a API service provider. It will be appreciated that the registration of the application with the API service provider may be performed prior to the steps of themethod of Figure 3 or the sequence of Figure 4. The system illustrated in Figure 6 comprises an app developer 660 and an API service provider 100. The API service provider 100 comprises a service provider administrator 670, an ASP management 680 and an application management 690. In step 600, the app developer queries the application types supported by the API service provider with the API service provider (e.g. with the application management 690). In step 602, the app developer may optionally query the ApplicationGroups supported by the API service provider with the API service provider (e.g. with the applications management 690). In step 604, the app developer may register an application (applicationProviderRef, appName, [opt]appDescription, [opt]appType, [opt] appGroup) with the API service provider (e.g. with the applications management 690). In step 606, the application function validates the application service provider (in this example the ASP management 680 retrieves the application provider reference (applicationProviderRef) from the application management 690).As illustrated by block 608, based on ASP validation, API service provider 100 can rejectregistration of certain AppTypes by specific Application Providers. In step 610, the API service provider 100 (e.g. the application management 690) may send an “application registration rejected” message to the app developer 660. In step 612, the API service provider 100 (e.g. the application management 690) registers the application.In step 614, the application management 690 notifies the service provider administrator670 on new application registration waiting for approval.As illustrated by block 616, API Service Provider 100 can approve or reject an applicationbased on an ASP / AppProvider who owns the application, a description provided for the application, and / or an application type or group that has been selected for the application. While approving the application, the API service provider admin 670 could optionally update certain ApplicationContext(s) i.e., appType and / or appGroup (but not the application provider). In step 618, the service provider administrator 670 can approve the application (change appType / appGroup, assign appGroup if required) via the application management 690. In step 620, the API service provider 100 (e.g. the application management 690) updates application approvalStatus. In step 622, the API service provider 100 (e.g. the application management 690) can optionally update ApplicationContext (AppType / AppGroup). In step 624, the API service provider 100 (e.g. the application management 690) can notify app developer 660 approval of application (along with information of any ApplicationContext updates made). As illustrated by block 626, application developer 660 can now order ApiSubscriptions for the approved application. The sequence diagram below shows the different steps of application registration on a high level. As part of Step 3, the registration request may comprise the application reference. In some examples the registration request may further comprise on application type and application group. At least one application context (e.g. of step 301) may be provided to or determined by the API service provider on registration of the application with the API service provider.The at least one first application context may also be updated by the API service providerduring registration of the application with the API service provider.The API service provider may validate the application service provider (ASP) as well asthe application and assign application types and groups (to specify the at least oneapplication context, e.g., as referred to in step 301 of Figure 3) as well as priorities onthe application context types (see steps 8-10 of Figure 6).Consent Capture Consent capture may happen via channels. Either it is application specific or even application and API specific or rather generic, addressing consent scenarios for multiple applications and APIs at once. Consent capture may leverage consent reference data, which may be created when the application subscription has been created. Consent capture functionality may be application specific or applicable to multiple applications. Consent capture may be responsible for collecting user decisions for the home service provider (default) and in addition also consent information for other networks (if needed due to deviations on the privacy data handling in these networks). On a high level, the consent capture process may be as described in Figure 7. Figure 7 is a flow chart illustrating an example of a consent capture process. In step 700, consent capture starts (app / self service page / authZ server page). In step 702, start collecting consent reference data. In step 704, determine data subject / contract context. In step 706, read app consent needs from policy templates in API subscription including constraint definition. In step 708, read consent data from consent management (including already available consent constraint data). In step 710, render consent capture screen. In step 712, collect user input on application / purpose / data scope level. In step 714, collect user input on consent constraints (if user decides to specify). In step 716, persist consent data collected from user with consent management. In step 718, consent capture ends. In some examples, the method of Figure 3 may comprise responsive to receiving a request from the application to access the first API for a first user for the particular data scope and particular purpose, ensuring consent is or has been obtained for the first user according to the first consent mode. In some examples, the method of Figure 3 may further comprise determining whether consent has already been obtained for the first user, responsive to consent not having already been obtained for the first user, checking whether consent is required according to the first consent mode, and responsive to consent being required, enabling the datasubject to provide consent over the first API to access the particular data scope for theparticular purpose. In some examples, the method of Figure 3 may further comprise determining whether consent has already been obtained for the first user, responsive to consent not havingalready been obtained for the first user, determining the respective first privacy policythat applies to the first user according to the respective values of the contract context parameters, checking whether consent is required according to a first consent mode value of the respective first privacy policy, and responsive to consent being required,enabling the data subject to provide consent over the first API for the particular datascope for the particular purpose.Figure 8 illustrates an example implementation of the aforementioned steps optionalsteps relating to consent capture. In this figure it is illustrated how consent capture may interact with consent management and retrieve the consent reference data as well as consent information captured earlier from the data subject and render a consent capture page to display the information and collect (further) user input (steps 9 to 24 in Figure 8). The system illustrated in Figure 8 comprises an end user 860, an ASP app 862, an ASPapp backend 864 and a service provider 100. The service provider 100 comprises aconsent capture page / portal / app 870, a consent management 880, and an APP registry 890.The consent reference data describes the needs of an application for collecting consent.Consent reference data for a registered application may comprise one or more of:- Privacy sensitive data scope, the application wants to access- Purpose / reason for accessing the data scope- Legal basis, representing the processing justification (as described by GDPR)- Country / Service Provider / Network- Consent constraints, which may be required to be captured (e.g. country)- Consent validity (once captured)In step 800, the end user 860 uses the ASP app 862.In step 802, the ASP app 862 sends a login message (username, password, os-type)to the ASP app backend 864. In step 804, the ASP app backend 864 looks up an MSISDN. In step 806, the ASP app backend 864 looks up a service provider (MSISDN) In step 808, the ASP app backend 864 generates an identity token (MSISDN, cspdomain). In step 810, the ASP app backend 864 encrypts an identity token (CSPpublicKey). As illustrated in block 812, a consent capture dialog can be brought up in differentsituations, e.g. configuration of the app, or if the ASP app back end has asked for anaccess token to call an API and consent management detects that consent entries aremissing and authZserver is notified abouta this fact. The flow illustrated in Figure 8shows only the invocation of the consent capture application / page. The ASP app backend can ask to capture consent for the app in general or for a certain combination of app purpose and scope or scopelist. In step 814, the ASP app backend 864 sends a consent-url (identityToken, (opt)appID, (opt)scope, (opt) purpose) message to the ASP app 862.In step 816, the ASP app 862 sends an invoke consent-url (identityToken, appID, (opt)scope, (opt) purpose) message to the service provider 100 (e.g. the consent capture page / portal.app 870). In step 818, the service provider 100 current consent (in this example the consent management 880 retrieves current consent (identityToken, appID, (opt) scope, (opt) purpose) from the consent capture page / portal / app 870). As illustrated in block 820, Consent management must extract MSISDN from identityToken. This can happen via interaction with authorization server for decrypting. In step 822, the service provider 100 (e.g. the consent management 880) extracts MSISDN(identityToken). In step 824, consent management 880 sends a checkForContractContext(appID) message to APP registry 890. In step 826, APP registery 890 returns a list of ContractContext to consent management 880. As illustrated in block 827, determination of current contract context for an MSISDN can happen via different mechanisms, e.g. lookup with subscription management. The consent reference data may be retrieved from the application registration in two steps. First the list of contract contexts from the application specific privacy policies may be retrieved. If this list contains an explicit contract context, a further determination of the contract context (contract type, contract owner) of the subscription (identified by MSISDN) may be executed (step 828). Then the applicable application specific privacypolicy is retrieved from the application registry (steps 830-832).Subsequently the already registered consent data from the consent database may beread and combined with the application’s needs (step 834 & 836).The combined data may be returned to the consent capture application, rendered andpresented to the user (steps 838-844).As illustrated in block 842, application presents the processing context, application owner, purpose for processing and data scope, show registered consent data, allow user to select and optionally specify consent constraints. As illustrated in block 846, collect with legal base and consent mode configuration, specify consent constraints if applicable according to configuration derived from privacy policy template. A specification of consent constraints is optional.The consent input may be collected from the user. In this step the user may accept ordeny their consent to make a certain data scope for a certain purpose available to an application. The user may optionally configure the values for consent constraints, if supported according to the policy template (step 848).The input collected from the user shall be made persistent into consent database andcontrol may be returned back to the application (steps 850 – 854).The sequence diagram illustrates the consent capture process using a consent capturepage provided by the service provider. Alternatively, also an app plugin may be used tocollect consent.As briefly described above, in some embodiments, consent constraints may be used.It will be appreciated that for simplicity, network contexts have not been considered in the flow of Figure 8. However, it may be first checked whether multiple application privacy policies for different countries or networks have been configured. Consent capture can then configure the user preferences for all application privacy policies or only thepreferences for the current network the user is connected to. For the latter case it maybe determined whether the user is roaming and in which network, to filter out the list ofprivacy policies applicable to the current country, the user is in or the current network, the user is connected to .Figure 9 illustrates a method, performed by an API service provider, for enabling anapplication to expose information over at least a first API provided by the API service provider. The method of Figure 9 may be performed for example, by the API service provider 100 illustrated in Figure 1. In step 901, the method comprises obtaining consent from the first user to allow the application to access information over the first API, wherein the consent is associated with at least one consent constraint attributes. In step 902 the method comprises to receiving a request from the application to access the first API for a first user, obtaining constraint context information corresponding to the at least one consent constraint attributes. In step 903, the method comprises comparing the constraint context information to the at least one consent constraint attributes. In step 904, the method comprises responsive to the constraint context information complying with one or more consent rules, allowing the application access to the first API for the first user. It will be appreciated that the information may be for a particular data scope and a particular purpose. Figure 9 therefore provided a method for consent attribute-based access control. Consent constraints may comprise a definition aspect, a configuration aspect as well as an evaluation aspect at runtime:a) Constraint rule: defines an algorithm evaluating an information item, which has beendetermined out of the API invocation context, and comparing this item against a certain value or set of values, the constraint attributesb) Constraint attribute: defines a pair of (constraint property, value), which ispreconfigured or collected from the user / legal responsible of the data subject / resource ownerc) Invocation Context: data available at API invocation time, which is used todetermine the data to be compared and evaluated against the constraint attributes Embodiments described herein may provide for: a) Defining consent constraint rules to be supported in the systemb) Defining how and where the context data to be compared against consentattributes will be determined; the logical function responsible to determine the input data is a.k.a. policy information point (PIP)c) Defining, which consent constraints shall be supported for anapplication / purpose / data scope / contract context combination; this definition happens initially in the privacy policy template and is then eventually overridden on the dedicated application policy template level. d) Defining a mechanism for capturing consent constraint attributes during consentcollectione) Defining a mechanism for accessing different distributed PIPs to collectconstraint comparison data at API invocation time f) Defining the options for constraint evaluation at a policy enforcement point basedon comparing the constraint attributes against the constraint comparison data collected in the PIP. g) Defining APIs on consent management will allow to pass constraint comparisondata collected in external PIP (where external means: external to consentmanagement or external to API logic) Consent constraint specification Possible consent constraints, associated rules and policy information points may be defined as a JSON / YAML structure and may be referenced in privacy policy templates, for example as described above. There may be different types of consent constraints. Some of them are related to the information managed or exposed in the service API, others are completely unrelated. Examples of the possible consent constraints which can be configured are as follows (however it will be appreciated that this list is not limiting): 1) Time constraints: The consent is valid for only a specific time-line or dates range.2) Geographical constraints: The consent is valid for a specific geographicallocation. 3) Roaming constraints: The consent is valid only for non roaming scenarios.4) User / device Constraints: The consent is valid for certain users / devices using aspecific application e.g., find my friend use case scenario, 5) Number constraints: The consent is valid for specific number of API invocationse.g., for Carrier Billing API call the consent is valid only for one transaction only and cannot be used for the next transaction. Separate consent is required for each payment transaction debited to the account.Consent constraints can also be a combination of the many individual constraints. E.g., my friend can locate me only during off-working time. Consent Capture During capture for exposing data to a certain application, detailed information about the supported consent constraints for the various purpose and data scope pairs, an application is interested in, may be retrieved. This information is provided by the JSON / YAML structure for consent constraints referenced in the privacy policy templates. Once the consent information includingconsent constraint values has been collected from the resource owner (i.e., legalresponsible of the data subject), the data may be provided to consent management andpersisted. Consent Evaluation Before calling an API, respectively running the API logic and exposing the data, theconsent evaluation may happen. The consent evaluation may be triggered from theauthorization server when this authZ server receives an Oauth2 authorization code grant request or an OpenID Connect access token request and interacts with consent management for checking. The check uses the information about the data subject, the application, the data scope, and the purpose sent in the request and evaluates the consent data captured from the user from consent management (assuming that consent has been captured earlier). The consent evaluation can also be triggered from the API implementation logic itself. With the extension of consent constraints, the constraint data captured from the usermay be compared against other input, which is not necessarily available in theauthorization code request or token request. Depending on the configuration of the constraints with regards to PIP, it might be possible to collect the comparison input inconsent management or this comparison input may be required to be determined as partof / initial step of the API execution. The PEP will be responsible to discover the constraintrule, for example, from a privacy policy template and apply the rule logic.The following example (and non-limiting) scenarios will be covered in the following inmore detail:1. PEP is provided by API Service implementation logic;oService implementation derives invocation context specific PIPs oService implementation implements API specific PIPs oService implementation invokes non API specific PIPs oService implementation runs constraint check for all types of constraints2. PEP is provided by consent managementoService implementation implements API specific PIPs oService implementation triggers consent management for constraint evaluation and sends API specific PIP data as input as well as request data oConsent management invokes non API specific PIPs oConsent management runs constraint check for all types of constraints Both scenarios have in common that the constraint check happens at API invocation time. Both scenarios use the access token, generated by the authorization server as input. This access token is enriched with the consent attributes, which contain the consent constraint details collected from the user. The PEP is not limited to the two scenarios described above. In some cases the PEP could also be implemented by the API Gateway. Some use case examples to explain the consent constraints are as follows: 1) A chat application is allowed to return the user’s name, but only if the user islocated in Germany or Sweden. 2) Kids tracker application is given consent by the parent to allow tracking thelocation of the kid (who is having a smart wearable band) only during the school time. 3) A staff management application is allowed to track an employee’s location onlyduring work hours. 4) Find my friend application is given consent by User X to track his location (hisdevice location precisely) only when the application is being used by User Y. The consent is valid only for few hours and then consent expires. In some examples, the concepts described with reference to Figure 9 may be combined with the embodiments described in Figures 3 to 8.For example, the method of Figure 3 further comprise obtaining consent from thefirst user to allow the application to access the particular data scope over the first API, wherein the consent is associated with at least one consent constraint attributes. It will be appreciated that the consent may be obtained before or after receiving a request from the application to access the first API for a first user for the particular data scope and the particular purpose. The method of Figure 3may further comprise responsive to receiving a request from theapplication to access the first API for a first user for the particular data scope, obtainingconstraint context information (e.g. what time is it now, or where is the user currently located) corresponding to the at least one consent constraint attributes (e.g. only provide consent during working hours, or only provide consent when located in a particular country); comparing the constraint context information to the at least one consent constraint attributes; and responsive to the constraint context information complying with one or more consent rules, allowing the application access to the first API for the first user for the particular data scope. The one or more consent rules may be comprised with the first privacy policy template, wherein each consent rule is associated with a respective a consent type of a respective one of the at least one consent constraint attributes. Consent Constraints as part of privacy policy Template A consent constraint definition may comprise the following information: -name of the constraint- description of the constraint- context parameters, each parameter includes:o nameo data typeo descriptiono pip, which is a reference to the method for getting the value of thecontext parameter -constraint attributes, each parameter includes:o nameo data typeo descriptiono value- constraint rules. Each rule refers to context parameters and constraintattributes, using comparison operators like isWithin, isEqual,isNotEqual, isInList, isNotInList, isInRange, isNotInRange, isInPeriod, isNotInPeriod… -pep, indicating which entity will act as PEP.- A potential consent constraint definition might look like the following json structure:“constraints”: {“WorkingHours”: { “description”: “API invocation time shall be within the specified time periods.”, “contextParameters”: { “invocationTime”: { “datatype”: “DateTime”,“description”: “API invocation time.”, “pip”: { “request” “input”: “Date” } } }, “rules”: [ “$contextParameters.inovationTime isWithin $constaintAttributes.timePeriods” ], “constraintAttributes”: { “workingHours”: { “datatype”: “TimePeriods”, “description”: “Time period, during which the API invocation is permitted.”, “value”: [{ “from”: “09:00:00”, “to”: “18:00:00” }] } }, “pep”: “ApiGateway” }, “Countries”: { “description”: “The user’s current location shall be inside one of the specified countries.”, “contextParameters”: { “currentLocation”: { “datatype”: “Location”, “description”: “Current location of the user in coordination format.” }, “locatedCountry”: {“datatype”: “String”, “description”: “Current location of the user in coordination format.”, “pip”: { “service”: “http: / / example.com / location2Country”, “input”: “$currentLocation” } } }, “rules”: [ “$contextParameters.locatedCountry isMemberOf $constaintAttributes.countries”], “constraintAttributes”: { “countries”: { “datatype”: “String[]”, “description”: “List of countries.”,“value”: [ “Germany”, “Sweden” ] } }, “pep”: “ApiService” },} How the consent constraints and / or consent rules may be configured is illustrated in more detail in Figure 14. Consent enforcement. Figures 10 and 11 give a high level overview of consent enforcement and illustrate the different Policy enforcement points: the API gateway, the API server or consent management. Some embodiments described herein may leverage RFC 9396 to encode consent constraints within an Access Token. The API invoker may then use the access token when calling the API and by doing so makes the consent constraints available to the API implementation logic. Overview of Consent constraint evaluationFigure 10 illustrates a final constraint policy enforcement in the API server, with anoptional prior partial policy enforcement in the API Gateway, mainly applicable to time constraints. The API server may be responsible to invoke the various policy information points / functions and collect the input (called constraint context) to be compare against the constraint attributes included in the access token. Figure 11 illustrates a final constraint policy enforcement in Consent Management, with an optional prior partial policy enforcement in the API Gateway, mainly applicable to time constraints. The collection of the consent context may be distributed. The API may beresponsible for collecting request related and API related constraint context data. TheAPI may trigger consent management to run constraint check. Consent management may determine the remaining (non API related) constraint context data and then run the constraint check. Consent management may use the constraint attributes included in the access token or can lookup the latest constraint attributes. It will be appreciated that the constraint enforcing entity may comprise any one of: ^API Gateway or^ API Server or^ Consent ManagementThe information for constraint enforcement may include one or more of:^ Information from API request. Some of the information need to be trustedinformation by the enforcing entity.^ Context information known by the enforcing entity, for example, invocation time.^ Information from API Server during API handling.^ Information derived via calling policy information functions.Sequence for Consent constraint evaluationFigure 12 is a signalling diagram illustrating an example of API Invocation involvingconsent constraints. In particular, Figure 12 illustrates retrieving input data for consent constraint comparison from the Network API and / or from the consent management function. The input data may come from the request information, the API or from a constraint input function called form the API or consent management. Once all the consent context data is available, the consent constraint evaluation may be triggered. Depending on the result the API execution is continued or an error is returned to the API invoker.The system illustrated in Figure 12 comprises an App BE 1280 and a communicationservice provider (CSP) 1282. The CSP comprises a CSP authorization server 1284, an API gateway 1286, a consent management 1288, a non-API-related policy information point (PIP) 1290 and a network API 1292. Steps 1200-1216 comprise an API invoker triggering API call for UserID (MSISDN). As illustrated by block 1200, the access token request in this example is simplified and only meant to illustrate the overall sequence. The diagram is applicable for oAuth2authorization code grant flow and CIBA.In step 1202, the APP BE sends an access token request (getToken message)(comprising UserID, appId, app credentials, purpose, and scopes) to the CSP 1282 (e.g. the CSP authorization server 1284). As illustrated by block 1204, the API invoker gets authenticated and the user gets authenticated. The authorization server 1284 interacts with consent mangement 1288 to retrieve consent data. Consent data is enriched with consent constraints according to RFC 9396. For simplicity, a potential consent capture flow is omitted. In step 1206, the CSP authorization server 1284 sends a getConsentData message (comprising UserID, appId, purpose, and scopes) to consent management 1288.In step 1208, the consent management 1288 evaluates consent needs based on thereceived appId, purpose, scopes. In step 1210, the consent management 1288 gets consent details based on the received userID, appId, purpose, scopes. In step 1212, the consent management 1288 returns consent details to the CSP authorization server 1284. In step 1214, the CSP authorization server 1284 generates an access token using theconsent details.In step 1216, the CSP 1282 (e.g. the CSP authorization server 1284) returns accesstoken (list of {purpose, scope, validity, consent constraints,…}) to the APP BE 1280.Steps 1217-1230 comprise an API invocation with accessToken.In step 1217, the APP BE 1280 may send a “call NetworkService” message (comprising<accesstoken> and input_params) to the CSP 1282 (e.g. the API gateway 1286).In step 1218, the API gateway 1286 validates the token <access_token>.Steps 1220 and 1222 are optional and may be performed if the access token containsconstraints which can be enforced by API gateway.In step 1220, the API gateway 1286 extracts info for constraint.In step 1222, the API gateway 1286 consent constraints (access_token,constraintConsent). Step 1224 is opt and may be performed on on failure.In step 1224, the CSP 1282 (e.g. the API gateway 1286) returns error on consentevaluation.In step 1226, the API gateway 1286 sends a callNetworkService message (comprising<access_token> and input_params) to the Network API 1292.In step 1228, the network API 1292 sends an introspectToken message (comprisingaccess_token) to the CSP authorization server 1284.In step 1230, the API gateway 1286 returns tokenDetails to the network API 1292.Steps 1232-1266 comprise starting constraint evaluation.In step 1232, the network API 1292 extracts constraint info using the tokenDetails.In step 1234, the network API 1292 initializes constraint context (PEP=”API”).Steps 1236-1252 are looped over constraints. Steps 1236-1242 are optional. Steps 1236 and 1238 may be performed if the PIP is fromrequest. Steps 1240 and 1242 may be performed if the PIP is API related. Steps 1244to 1252 may be performed if the PIP is non API related.In step 1236, the network API 1292 extracts request info for constraint.In step 1238, the network API 1292 appends constraint context (constraintname,requestInfo, state=”determined”).In step 1240, the network API 1292 gets constraint info in API (constraintname,input_params).In step 1242, the network API appends constraint context (serviceInfo,state=”determined”).Steps 1244-1248 are optional and may be performed if the API supports PIP invocation).In step 1244, the network API 1292 gets constraint info (input_params) from the PIP1290.In step 1246, the PIP 1290 sends a result pipconstraintdata to the network API 1292.In step 1248, the the network API 1292 appends constraint context (constraintname,pipnstraintdata, state=”determined”). Steps 1250 and 1252 are optional and may be performed if the PIP must be called in Consent Management.In step 1250, the network API 1292 appends constraint context (constraintname,<empty>, state=tobedetermined”).In step 1252, the network API 1292 updates constraint context structure(PEP=”CONSENTMGMT”). Step 1254is optional and may be performed where the “PEP=API”.In step 1254, the network API 1292 evaluates the consent constraints (accesstoken,constraintcontext). Step 1256 o 1266 are optional and may be performed if the “PEP” = “Consent Management”.In step 1256, the network API 1292 sends an evaluateConsentConstraints (accesstoken,constraintcontenxt) message to the consent management 1288.Steps 1258-1262 are looped over remaining PIP functions.As illustrated in block 1257, the method comprises collecting remaining needed constraint input via calling PIP functions.In step 1258, the consent management 1288 sends a getConstraintInfo(input_params)to the PIP 1290.In step 1260, the PIP 1290 sends a result pipconstraintdata message to the consentmanagement 1288.In step 1262, the consent management 1288 appends constraint context(constraintname, pipconstraintdata, state=”determined”).In step 1264, the consent management 1288 evaluates consent constraints(accesstoken, constraintcontext).In step 1266, the consent management 1288 returns a result of the constraint check tothe network API 1292. Steps 1268-1276 comprise continuing after constraint evaluation. Steps 1268 to 1272 are optional and may be performed if the constraint check is successful.In step 1268, the network API 1292 continues logic.In step 1270, the network API 1292 returns a result to the API gateway 1286.In step 1272, the CSP 1282 (e.g. the API gateway 1286) returns the result to the APPBE 1280. Step 1274 and 1276 are optional and may be performed if the consent constraint check resturns no-consentIn step 1274, the network API returns error on consent evaluation to the API gateway1286.In step 1274, the CSP 1282 (e.g. the API gateway 1286) returns the error on consentevaluation to the APP BE 1280. The sequence of API invocation depicted in Figure 12 starts from the simplified access token request (step 1202) sent from the application backend to the authorization server. This is not necessarily the first step of interaction, depending on which flow variant of Oauth2 or OpenIdConnect flows is implemented. The authorization server interacts with consent management to retrieve the consent details for the target resource (identified with help of User ID, e.g. an MSISDN), the application, the purpose and the list of data scopes. These consent details may also include consent constraints, which have been captures earlier from the user (e.g. during registration of the application or during subscription to the API). The authorization server generates the access token out of the result, and especially appends consent constraint information. This constraint information may comprise constraint definition as well as constraint attributes (the values captured from the user). (steps 1206-1214). The access token may then be returned to the application backend and used to call the API (step 1216,1217). The application backend may first hit the API Gateway, who will run an initial access token validation, for example, by validating the digital signature of the Access Token with the certificate of the issuer (step 1218). There is now the option to enforce some of the constraints, e.g. time related constraints already at the API Gateway. To do so, the gateway determines the input value for the constraint evaluation out of the API invocation context and runs the comparison (step 1220-1224). If the constraint enforcement passes, API Gateway forwards the API request with the access token to API Service (step 1226). The API service interacts with the authorization server for token introspection (steps 1228,1230). As the constraints are carried inside the Access Token (step 1232), the API Service could enforce the constraints. Thus, the constraint context will be initialized assuming that the API acts as final policy enforcement point (step 1234). The API service may now process the constraint definitions of all constraints named in the access token and tries to determine the comparison input. If the constraint indicates that the constraint input information is to be taken out of the request, the information is extracted and appended to the constraint context (step 1236,1238). -If the constraint indicates that the constraint input information is to be takenout of the request, the information is extracted and appended to the constraint context (step 1236,1238). -If the constraint indicates that the constraint input information is to bedetermined in the service logic, the needed step in the service logic are executed, the information is extracted and appended to the constraint context (step 1240,1242). -If the constraint indicates that the constraint input information is to bedetermined by invoking an external function, the service logic might invoke this function (following the configured URL) (step 1244,1246). However, this will only happen if the service logic knows upfront, how to interpret the result of the invocation. If so, it will append the result to the constraint context for later comparison (step 1248). If not, it will indicate this fact in the constraint context and update the policy enforcement point to be consent management (step 1250,1252). If, after processing all constraints, the policy enforcement point is still with the APIservice, the API service runs the comparison of the constraint context against theconstraint attributes from the access token (step 1254). If, after processing all constraints, the policy enforcement point is now withConsent management, the API service will forward the access token details andthe constraint context collected so far to consent management and trigger a constraint evaluation (step 1256). Consent management is now to collect the remaining constraint input by calling the configured policy information functions and appending the output to the constraint context (steps 1258-1262). Once the constraint context is complete, a comparison against the constraint attributes in the access token (or eventually refreshed from the consent registry) happens. The result is returned to the API service (step 1266). In case of successful consent constraint check, the API execution continues, otherwise an error is returned to the application backend (steps 1268-1276).Example 5: device location for consent constraintThe example assumes that an enterprise communication application would like to check the device location for fraud-prevention use cases. The CSP providing the API service has configured possible consent constraints allowing to limit the time period and the location.The employee (e.g., the data subject) has taken advantage of this option duringconsent capture and specified that checking the location is only possible duringwork hours (first constraint) and only if he is located in the countries “Germany”or “Sweden” (second constraint).As described above, in some embodiments RFC 9396 is leveraged to encode theconstraints inside an Access Token. Here comes an example ofauthorization_details for a device location API:[{ “type”:”device-location”, “actions”:[ “read” ], “locations”:[ “https: / / example.com / ” ], “datatypes”:[ “location” ], “purpose”:[ “dvp:EnforceSecurity” ], “constraint”:{ “name”=”WorkingHours”, “type”=TimePeriod, “constraintContextParameter” = { “name”=invocationTime, “PIP”=”request:Date” },“rule”=<context.invocationTime> isInPeriod {constaintAttribute.value.from, constaintAttribute.value.to}”, “constaintAttribute”:{ “name” = “WorkingHours”, “datatype”=”timePeriod” “value”:[ { “from”:”08:30:00.000Z”, “to”:”12:00:00.000Z” }, { “from”:”13:30:00.000Z”, “to”:”18:00:00.000Z” } ] },{“name”=”countries”, “type”=Country, “constraintContextParameter” = { “name”=country, “PIP”=”api:Country” }, “rule”=<context.country> isInList {constaintAttribute.value.countries}”, “constaintAttribute”:{ “countries”:[ “Germany”, “Sweden” ], } } ] Evaluation of consent constraintsFigure 13 illustrates an example of how evaluation of consent constraints may beperformed. In this example, ^API Gateway enforces the “periods” constraint by checking if the invocation timeis within the periods. ^API Server enforces the “countries” constraint by checking whether the targetdevice is located in one of the countries specified by the constraint. API Server needs to obtain the raw location of the target device and derives the country from the raw location and convert this into country information.Figure 14 is a flow chart illustrating an example of how consent constraints and relatedconsent rules may be configured. The flow chart includes the steps of: 1.defining the possible constraints and constraint rules, including a reference to the function, which will act as Policy Information Point (PIP). PIP could be: a. data from the request; PIP reference is”request:[header|payload]:<propertyname> b. service data; PIP reference is “api: <propertyname>c. constraint function; PIP is “cf: / url-to-cf / constraint-function-name:”inputparam1”=?, 2. configuring the policy templates for API / data scope / purpose with the subset ofconsent constraints which shall be supported For service related PIP, it may be the responsibility of the API service to determine the comparison input data at runtime out of the API invocation context.For non-service related PIP, the API can call the PIP function, but may be aware of theresult returned by the PIP function and know how to interpret it. If it is not intended to encode the PIP invocation in the API, this may be done in consent management. The API implementation as well as consent management (triggered from the service) can act as Policy Enforcement Point (PEP). In addition, for some constraints, also the API gateway can act as Policy Enforcement Point. The flow diagram of Figure 14 describes the steps of configuring consent constraints and assigning them to policy templates. In step 1401, start consent capture (app / self service page / authZ server page). In step 1402, start collecting consent reference data for app. In step 1403, determine data subject / contract context. In step 1404, read app consent needs from policy templates in API subscription including constraint definition. In step 1405, define constraint attributes with description, data type, values or value reference. In step 1406, define constraint rules on constraint attribute comparison with constraint context. In step 1407, configure privacy policy templates with subset of consent constraints to be supported. In step 1408, end definition. Embodiments described herein allow a service provider to comply with legal regulations for handling privacy sensitive data of their users and put the needed mechanisms in place to collect and manage user consent, as well as evaluate consent information at runtime when API access is requested by an application. In addition, it will be possible to provide full transparency to the users showing them,which consent they have given or can give based on the legal basis configuration.When applying the mechanisms for consent constraint handling, it will be possible to support a much higher level of data privacy handling. When a user provides consent to an application, the user will have the option to specify under which conditions / constraints the consent he gives is valid. Users do not want to provide an open consent to any application (or a user of this application) for getting access to their privacy sensitive data, e.g., location. Embodiments described herein may allow service providers to support their users with the ability to specify the constraints under which the consent is valid. This will significantly improve the experience of the API Service Providers customers as well as help API ServiceProvider to be in better alignment with regulationsApplication calling APIs exposed by service providers do not know whether their user is roaming or not. However, the rules on data privacy as combination of rules originating from the home service provider of the user combined with the rules originating from the visited service provider may be required to be followed. The ability to maintain multiple configurations of privacy policies for application, purpose and scope combinations and selecting the applicable one by evaluating the roaming situation and eventually other runtime conditions allows a service provider to comply to legal requirements and handle this deviation transparently and without impact on the application service provider. Though an application service provider will not know if a user would be roaming, they could indicate the countries where they wish to provide the service while ordering the Api Products. Based on the list of countries specified, the API service provider may create the necessary applicationFigure 15 illustrates an API service provider 1500 comprising processing circuitry (orlogic) 1501. The processing circuitry 1501 controls the operation of the API serviceprovider 1500 and can implement the method described herein in relation to an APIservice provider 1500. The processing circuitry 1501 can comprise one or moreprocessors, processing units, multi-core processors or modules that are configured orprogrammed to control the API service provider 1500 in the manner described herein.In particular implementations, the processing circuitry 1501 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to theAPI service provider 1500. It will be appreciated that the API service provider 1500 maycomprise one or more virtual machines running different software and / or processes. TheAPI service provider 1500 may therefore comprise, or be implemented in or as one ormore servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.Optionally, the API service provider 1500 may comprise a memory 1503. In someembodiments, the memory 1503 of the API service provider 1500 can be configured tostore instructions (e.g. program code) executable by the processing circuitry 1501 of theAPI service provider 1500 whereby the apparatus is operable to perform any one or moreof the methods described herein (for example as illustrated in any of the Figures 2 to 14).Alternatively or in addition, the memory 1503 of the API service provider 1500, can beconfigured to store any requests, resources, information, data, signals, or similar that aredescribed herein. The processing circuitry 1501 of the API service provider 1500 maybe configured to control the memory 1503 of the API service provider 1500 to store anyrequests, resources, information, data, signals, or similar that are described hereinIn some embodiments, the API provider 1500 may optionally comprise acommunications interface 1502. The communications interface 1502 of the API serviceprovider 1500 can be for use in communicating with other nodes, such as other virtualnodes. For example, the communications interface 1502 of the API service provider 1500 can be configured to transmit to and / or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry 1501 of APIservice provider 1500 may be configured to control the communications interface 1502of the API service provider 1500 to transmit to and / or receive from other nodes requests,resources, information, data, signals, or similar. The communications interface 1502 can use any suitable communication technology.The API service provider 1500 may be configured operate in the manner describedherein in respect of an API service provider. There is also provided a computer program comprising instructions which, when executed on a least one processor (such as the processing circuitry 1501 of the APIservice provider 1500 described earlier), cause the processor to carry out at least part ofthe method(s) described herein. According to some embodiments there is provided a carrier containing the computer program. In some embodiments, the carrier can be any one of an electronic signal, an optical signal, an electromagnetic signal, an electrical signal, a radio signal, a microwave signal, or a computer-readable medium. There is also provided a (for example, tangible and / or non-transient) computer-readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform at least part of the method(s) described herein. Some embodiments described herein may allow a service provider to comply with legal regulations for handling privacy sensitive data of their users and put the needed mechanisms in place to collect and manage user consent, as well as evaluate consent information at runtime when API access is requested by an application. In addition, it may be possible to provide full transparency to the users showing them,which consent they have given or can give based on the legal basis configuration.When applying the mechanisms for consent constraint handling (e.g. as described withreference to Figure 9), it may be possible to support a much higher level of data privacyhandling.When a user provides consent to an application, the user may have the option to specifyunder which conditions / constraints the consent he gives is valid. Users do not want to provide an open consent to any application (or a user of this application) for getting access to their privacy sensitive data, e.g., location. Embodiments described herein allow service providers to support their users with the ability to specify the constraints under which the consent is valid. This will significantly improve the experience of the API Service Providers customers as well as help API Service Providerto be in better alignment with regulations.It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope. AbbreviationsABAC Attribute Based Access ControlAPI Application Programming InterfaceASP Application Service ProviderCSP Communication Service ProviderEU European UnionGDPR General Data Protection RegulationPII Personally Identifiable InformationPEP Policy Enforcement PointPIP Policy Information Point

Claims

CLAIMS 1. A method, performed by an API service provider, for managing subscription to atleast a first API dealing with privacy sensitive data provided by the API service provider, the API service provider having access to a plurality of privacy policy templates, wherein each privacy policy template comprises one or more values for a plurality of parameters comprising: an application context parameter, a purpose parameter, a data scope parameter a legal basis parameter, the method comprising: receiving a subscription request to subscribe an application to a first API provided by the API service provider, wherein the application is associated with at least one first application context at the API service provider; and obtaining one or more suitable privacy policy templates from the plurality of privacy policy templates, wherein the one or more suitable privacy policy templates each comprise values for the plurality of parameters that correspond to the at least one first application context, one or more first data scopes and one or more first purposes; and selecting a first privacy policy template from the one or more suitable privacy policy templates; creating a first privacy policy from the first privacy policy template for use with the application, wherein the first privacy policy is associated with a first legal basis.

2. The method of claim 1 further comprising ensuring that a first consent modederived from the first legal basis is used by the API service provider when the application calls the first API for a particular data scope in the one or more first data scopes and a particular purpose in the one or more purposes.

3. The method of claim 1 or 2 wherein the plurality of parameters further comprisesa consent mode parameter, and wherein the first privacy policy template has the first consent mode as the value of the consent mode parameter.

4. The method of claim 1 to 3, further comprising:selecting the first privacy policy template from the one or more suitable privacy policy templates based on a priority process.

5. The method of claim 4 wherein the priority process is performed according to apriority associated with application context value types of application context parameters in the one or more suitable privacy policy templates.

6. The method of claim 1 to 4 wherein, responsive to the subscription requestcomprising no indication of the one or more first data scopes, the one or more first data scopes comprises a wildcard value.

7. The method of claim 1 to 5, wherein, responsive to the subscription requestcomprising no indication of the one or more first purposes, the one or more first purposes comprises a wildcard value.

8. The method of claim 1 or 4 wherein the subscription request further comprisesan indication of one or more of: the one or more first data scopes and the one or more first purposes.

9. The method of any previous claim wherein the plurality of parameters furthercomprises a contract context parameter.

10. The method of claim 9 wherein the selecting the first privacy policy template ofthe one or more suitable privacy policy templates for use with the application comprises: for each value of the contract context parameter in the one or more suitable privacy policy templates, selecting a respective first privacy policy template comprising the value of the contract context parameter.

11. The method as claimed in any preceding claim, wherein the plurality of privacypolicy templates comprises at least one catch-all privacy policy template comprising a wildcard value for the application context parameter.

12. The method as claimed in claim 11 when dependent on claim 9, wherein thecatch-all privacy policy template further comprises a wildcard value for the contract context parameter.

13. The method as claimed in any preceding claim when dependent on claim 2,further comprising: responsive to receiving a request from the application to access the first API for a first user for the particular data scope and particular purpose, ensuring consent is or has been obtained for the first user according to the first consent mode.

14. The method as claimed in claim 13 wherein ensuring comprises:determining whether consent has already been obtained for the first user, responsive to consent not having already been obtained for the first user, checking whether consent is required according to the first consent mode, and responsive to consent being required, enabling the first user to provide consent over the first API to access the particular data scope for the particular purpose.

15. The method as claimed in claim 13 when dependent on claim 9 wherein ensuringcomprises: determining whether consent has already been obtained for the first user, responsive to consent not having already been obtained for the first user, determining the respective first privacy policy that applies to the first user according to the respective values of the contract context parameters, checking whether consent is required according to a first consent mode value of the respective first privacy policy, and responsive to consent being required, enabling the first user to provide consent over the first API for the particular data scope for the particular purpose.

16. The method as claimed in claim 15 further comprising:obtaining consent from the first user to allow the application to access the particular data scope over the first API, wherein the consent is associated with at least one consent constraint attributes.

17. The method as claimed in claim 16 further comprising:responsive to receiving a request from the application to access the first API for a first user for the particular data scope, obtaining constraint context information corresponding to the at least one consent constraint attributes; comparing the constraint context information to the at least one consent constraint attributes; and responsive to the constraint context information complying with one or more consent rules, allowing the application access to the first API for the first user for the particular data scope.

18. The method as claimed in any preceding claim wherein the one or more consentrules are comprised with the first privacy policy template, wherein each consent rule is associated with a respective a consent type of a respective one of the at least one consent constraint attributes.

19. The method of any preceding clam wherein the subscription request comprisesan indication of an application reference of the application, and the method further comprising: obtaining the at least one application context utilizing the application reference.

20. The method as claimed in any preceding claim further comprising:responsive to receiving a request for an indication of APIs available for subscription, transmitting an indication of one or more available APIs provided by the API service provider including at least the first API, and receiving the subscription request to the first API responsive to transmitting the indication of available APIs 21. The method as claimed in any preceding claim wherein the at least one firstapplication context is provided to the API service provider on registration of the application with the API service provider.

22. The method as claimed in claim 21 wherein the at least one first applicationcontext is updated by the API service provider during registration of the application with the API service provider.

23. The method of any preceding claim wherein any application context parameter isof one of the following types: application group, application type, applications for an enterprise, a business, applications from a service provider, application reference, application service provider reference, wildcard value.

24. The method of any preceding claim wherein any contract context parameter is ofone of the following types: wildcard value, contract type or customer identification.

25. The method of any preceding claim wherein a consent mode may be one of: opt-in, opt-out, or automatic.

26. A method, performed by an API service provider, for enabling an application toexpose information over at least a first API provided by the API service provider, the method comprising: obtaining consent from the first user to allow the application to access information over the first API, wherein the consent is associated with at least one consent constraint attributes; responsive to receiving a request from the application to access the first API for a first user, obtaining constraint context information corresponding to the at least one consent constraint attributes; comparing the constraint context information to the at least one consent constraint attributes; and responsive to the constraint context information complying with one or more consent rules, allowing the application access to the first API for the first user.

27. An API service provider the API service provider comprising processing circuitryand a memory, the memory containing instructions executable by the processing circuitrywhereby the API service provider is operable to perform the method as claimed in anyone of claims 1 to 26.

28. A computer program, comprising which, when executed on at leastone processor, cause the at least one processor to carry out a method according to any of claims 1 to 26.

29. A carrier containing the computer program according to claim 28, wherein thecarrier comprises one of an electronic signal, optical signal, radio signal or computer readable storage medium.

30. A computer-readable medium comprising instructions that, when executed on atleast one processor, cause the at least one processor to perform the method according to any of claims 1 to 2631. A computer program product comprising non transitory computer readable mediahaving stored thereon a computer program according to claim 28.

Images