Consent and identity management

Overviewheader link

First, let's talk about the difference between consent and identity. It is extremely important to know which applications can access or modify devices' data. Applications need to process personal or private enterprise information, but to do so with "legitimate interest" and have a legal basis to handle this information, we need to get consent (authorization) from device owners. Network as Code (NaC) also adopts the privacy-by-design approach and must comply with data protection regulations, for example, the GDPR regulation in Europe and other ones depending on the region. In summary, this means that a device's owner will allow which applications or APIs can access their device. So, consent management is about granting or revoking the access an application has to APIs and their parameters, so that authorized devices can be safely used.

Now, let's suppose your organization already has several identifiers (IDs) assigned to its devices and now they need to be managed or authorized. Identity management literally means handling these different device IDs. This will allow choosing different authorization scopes (API names) for multiple device IDs and organizations. For example, let's say you need consent to query a device's location or modify its network parameters for Quality of Service (QoS). Then, you will need to know if these actions are within the scope authorized for this device ID before performing them. So, an enterprise will define which service or functionality scope can affect its devices through their IDs.

TIP: With NaC SDKs, you can create a Device object, which is a representation of a device's ID. There are multiple ways to identify mobile network devices. Learn more.

Consent-specific terminologyheader link

• Scope: Feature or operation that is authorized. It's usually defined by the API name, such as "Location Verification", "Quality-of-service-on-Demand (QoD) sessions", etc. In addition to the API name, the scope may be extended with a specific resource name and/or an allowed action, such as "read" or "write", to limit the access.

  NOTE: The scope names should be from the list of the supported scopes (e.g.: location-retrieval). Please, check the list below.

• Device ID: it can be a phone number or the email-like identifier for the device (or subscriber) into the network. E.g.: 36721601234567, [email protected], and so on.

• Authorized Party: the private enterprise or organization name, system integrator and so on, which will be authorized to use the devices within the defined scopes. The NaC Administrator ("Admin") will then validate this authorization with the Operator.

• Operator: the owner of a network that can be used through the NaC APIs.

Getting consent in a Business to Business (B2B) scenarioheader link

Let's first consider a B2B scenario, in which a farming enterprise owns multiple mobile devices that can be accessed by different organizations and perform different actions. In agriculture, we have many examples of drone applications, such as crop or soil analysis, yield estimation, taking high-quality images, videos or even spraying crops! Since different access types can be granted to different organizations or service providers, this enterprise will need to provide a form listing the different device IDs, API scopes, authorized parties and operators (depending on the area they are located).

Network as Code will make the link to make these actions possible seamlessly. The NaC Admin will validate the form data with the operators on the list and enable different organizations to access their allowed devices and scopes (qod-sessions, location-verification, specialized-network-create, device-status-roaming, etc.).

Submitting an authorization requestheader link

Here's how private enterprises can get consent for different devices and authorized parties. In the following document, an organization is authorizing the access of three different enterprises to distinct devices:

• First, download the Nokia Network as Code Consent & Authorization template.

• In the steps below, you will learn how to fill out the Consent & Authorization form.

  NOTE: The Organization Admin needs to send the request via e-mail to [email protected]

1. At the top-left field, fill in the name details for the authorizing and authorized organizations, as well as the date for the consent to start. For example: If devices are owned by Enterprise 1 and Enterprise 2 will be authorized to access them, you can fill them like so:

   • Legal Name of the Authorizing Organization: Enterprise 1.
   • Authorized Party: Enterprise 2.
   • Date of Consent: 01/06/2024 (The date format is DD/MM/YYYY).

2. Fill the Device column with phone numbers and external identifiers as device IDs.

3. Provide the Scope column only with values described in the scope table below.

4. The Authorized Party column should contain the Organization Name, which is being authorized to have access to the devices. The Organization Name should be exactly as the one listed in your NaC Portal Dashboard.

5. Provide the Operator name from whom you have the mobile subscription.

6. Fill the Revocation Date with the date your organization wants each consent/authorization to end.

Submitting a new requestheader link

From time to time, it is necessary to add new devices, authorize new scopes, parties or even delete devices, revoke scopes or authorizations. An Organization Admin can submit a new request whenever necessary and the previous one will be completely cleaned up. This means that the devices that are not included in the new list will lose their authorization and be completely revoked. So, if you want to increase the number of scopes, authorize different parties and device or revoke their authorizations, just submit a new authorization request to Network as Code support e-mail address as described above.

Available scopesheader link

Here are all of the scopes you can include or edit in the authorization request.

Device Status scopesheader link

Location scopesheader link

Geofencing scopesheader link

Quality-of-service on Demand scopesheader link

Specialized Networks scopesheader link

Network Insightsheader link

Number Verificationheader link

Device Swapheader link

Know Your Customer Matchheader link

Know Your Customer Age Verificationheader link

Other scopesheader link

Specifying purposeheader link

You may need to dynamically specify a valid purpose for some APIs. This is used to specify why authorization to perform an action is being requested.

Currently the following purposes are supported:

Purpose can be associated with a scope by prefixing it. For example, requesting authorization for number verification for the purpose of fraud detection can be represented as dpv:FraudPreventionAndDetection number-verification:verify.

For APIs other than Number Verification, Network as Code will supply the purpose that was specified during application registration and API plan subscription automatically. If your application uses API calls for a new purpose after registration, it is your responsibility to notify Network as Code support ([email protected]) to update your application's API call purpose information.

End-user consent flowsheader link

Client Initiated Backchannel Authentication (CIBA) flowheader link

In many simpler cases, Network as Code will handle requests for end-user by using CIBA, where the access to the end-user device is guarded by an Authorization Server, which Network as Code will poll until a response is provided. The Authorization Server is then responsible for triggering an appropriate end-user consent request which the user can approve or deny. When the request has been approved, the Authorization Server provides a client token that has been authorized to perform the desired action.

From the application developer's point of view, the CIBA flow should appear essentially transparent and the developer shouldn't need to do anything except call the APIs normally with their application keys. The Network as Code runtime itself will take care of polling for access tokens on behalf of the application. However, as this may take some time before the consent request is approved, you may need to adjust API request timeouts accordingly. The Network as Code SDKs will use extended timeouts by default.

Authorization Code flowheader link

If an end user will need to take positive action to indicate their consent, then the Authorization Code flow will be used.

In this flow the application developer constructs an authorization URL pointing at the Network as Code authorization server and containing their own redirect handler as a redirect URI and directs the end user application running on the end user device to that URL. Network as Code will then redirect the user to their operator-specific consent portal to approve the consent request.

If the consent is given, the application is redirected back to the application's redirect URI with an operator code. This code is then exchanged for a single-use access token and passed along with the subsequent request to an API, validating that the API is being called with user consent.

Last updated November 05, 2025