This API provides methods to obtain the capabilities of CAMARA project in mas-stack.

The functionality it will currently have will be for AuthN and its purpose will be, given an MSISDN, scope, purpose and application, to return whether the MSISDN gives consent for the capability query to be performed for the indicated application.

Service Enabling Network Function API to verify that the provided mobile phone number is the one used in the device. It verifies that the user is using a device with the same mobile phone number as it is declared. It also makes it possible for a Service provider to verify the number itself by returning the phone number associated to the authenticated user's access token.

In this API phone number term refers to the mobile phone number.

Introduction

Number Verification API performs real-time checks to verify the phone number of the mobile device being used to access a service provider (SP) service, where the mobile device is accessing the service provider over a mobile network (WiFi connections are out of this API scope) either by getting the comparison result or receiving the phone number of the device that it is used, so they can verify it themselves.

It uses direct mobile network connections to verify possession of a phone number in the background without requiring user interaction. There are neither OTPs (One-time passwords) received by SMS nor authenticator app downloads, so it is much simpler. It can be used at sign up, login, or transaction time to validate that a user's SIM (Subscriber Identity Module) is both actively connected to the mobile network and not spoofed or cloned.

Relevant Definitions and Concepts

• Network-Based Authentication: Authentication mechanism based on the identification of the endpoint of a network connection. Network operators know to which subscriber a network resource is assigned at a given moment, for example the mobile phone number associated to a specific mobile network connection.

API Functionality

This enables a Service Provider (SP) to verify the phone number of the mobile device being used to access their service where the mobile device is accessing the service provider over a mobile network (WiFi connections are out of this API scope). This can happen either by getting the comparison result or receiving the phone number of the device that is used, so they can verify it themselves.

Resources and Operations overview

This API currently provides two endpoints where both require a 3-legged token and authentication via mobile network (excluding for example by SMS/OTP or user/password as an authentication method):

• The first one checks if the user mobile phone number matches the phone number associated with the mobile device. It can receive either a hashed or a plain text phone number as input and it compares the received input with the authenticated user's phone number associated to the access token in order to respond true/false.

Sequence Diagram

Number Verification API uses the standard OIDC Authorization Code Flow. The following diagram will help to clarify the end-to-end process, including previous steps prior to this API call.

Note that the diagram shows just an example of a direct integration from developer's application and MNO's authserver and API, other scenarios of indirect integration via Aggregator/Channel Partner should also be considered. Specific authorization flows may apply, as defined by e.g. GSMA Open Gateway (OGW).

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.

Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.

It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

In the case of the Number Verification API scenario and according to the API definition, 3-legged access tokens must be used by API clients to invoke this API with dedicated scope. The API client must authenticate on behalf of a specific user to use this service. This must be done via mobile network authentication.

Further info and support

GSMA Mobile Connect Verified MSISDN specification was used as source of input for this API. For more about Mobile Connect, please see Mobile Connect website.

The SIM swap API provides a programmable interface for developers and other users (capabilities consumers) to request the last date of a SIM swap performed on the mobile line, or, to check whether a SIM swap has been performed during a past period.

Introduction

The SIM Swap API performs real-time checks on the last SIM Swap event.

The SIM Swap API is useful to prevent fraud by reducing the risk of account takeover fraud by strengthening SIM based authentication processes such as SMS One-time passwords. Fraudsters are using SIM swap techniques to intercept SMS messages and reset passwords or receive verification codes that allow them to access protected accounts.

The SIM Swap API can also be used to protect non-automated actions. For example, when a call center expert contacts a user to clarify or confirm a sensitive operation.

This API is used by an application to get information about a mobile line latest SIM swap date. It can be easily integrated and used through this secured API and allows SPs (Service Provider) to get this information an easy & secured way. The API provides management of 2 endpoints answering 2 distinct questions:

• When did the last SIM swap occur?
• Has a SIM swap occurred during last n hours?

Relevant terms and definitions

SIM swap: A SIM swap is a process in which a user's mobile phone number (MSISDN) is associated with a new SIM card (IMSI). This is typically done by contacting the user's mobile service provider and requesting a new SIM card for various reasons, such as a lost or damaged SIM card or upgrading to a new phone.

SIM swap also happens during other actions like changing user's phone number, changing mobile service provider keeping user's mobile phone number or when activating a new SIM associated to the same phone number, known as multisim service. New subscription is considered as a SIM swap as well, the MSISDN which can be used by another person earlier, is associated with a SIM card it was not associated before.

API functionality

The API provides 2 operations:

• POST retrieve-date : Provides timestamp of latest SIM swap, if any, for a given phone number. If no swap has been performed, the API will return the SIM activation date (the timestamp of the first time that the sim connected to the network) by default, unless this is not possible due to local regulations preventing the safekeeping of the information for longer than the stated period of time. If this is the case, a null value will be returned.

• POST check: Checks if SIM swap has been performed during a past period (defined in the request with 'maxAge' attribute) for a given phone number.

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.

Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.

It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

Identifying a phone number from the access token

This specification defines the phoneNumber field as optional in API requests, specifically in cases where the API is accessed using a 3-legged access token, and the phone number can be uniquely identified by the token. This approach simplifies API usage for API consumers by relying on the information associated with the access token used to invoke the API.

Handling of phone number information:

Optional phoneNumber field for 3-legged tokens:

• When using a 3-legged access token, the phone number associated with the access token must be considered as the phone number for the API request. This means that the phoneNumber field is not required in the request, and if included it must identify the same phone number, therefore it is recommended NOT to include it in these scenarios to simplify the API usage and avoid additional validations.

Validation mechanism:

• The server will extract the phone number identification from the access token, if available.
• If the API request additionally includes a phoneNumber field when using a 3-legged access token, the API will validate that the phone number provided matches the one associated with the access token.
• If there is a mismatch, the API will respond with a 403 - INVALID_TOKEN_CONTEXT error, indicating that the phone number information in the request does not match the token.

Error handling for unidentifiable phone number:

• If the phoneNumber field is not included in the request and the phone number information cannot be derived from the 3-legged access token, the server will return a 422 UNIDENTIFIABLE_PHONE_NUMBER error.

Restrictions for tokens without an associated authenticated phone number:

• For scenarios which do not have a phone number associated to the token during the authentication flow, e.g. 2-legged access tokens, the phoneNumber field MUST be provided in the API request. This ensures that the phone number is explicit and valid for each API call made with these tokens.

Further info and support

GSMA Mobile Connect Account Takeover Protection specification was used as source of input for this API. For more about Mobile Connect, please see Mobile Connect website.

(FAQs will be added in a later version of the documentation)

To consume Open Gateway capabilities, an authorization flow is required through which clients obtain a token with the necessary permissions/scopes to access the requested information.

API for managing View OpenGateway and Capabilities catalog. This service provides CRUD operations for capability management.

Internal administration API for the Open Gateway domain. Provides tenant management and other internal operations.

The Quality-of-Service (QoS) Profiles API provides a set of predefined network performance characteristics, such as latency, throughput, and priority, identified by a unique name. These profiles allow application developers to specify the desired network behavior for their application's data traffic, ensuring optimal performance. By selecting an appropriate QoS profile, developers can request stable latency (reduced jitter) or throughput for specific data flows between client devices and application servers when used by the Quality-On-Demand APIs.

Introduction

QoS Profiles are used in conjunction with other Quality-On-Demand APIs, to offer the API consumer the capability to request for stable latency (reduced jitter) or throughput for some specified application data flows between application clients (within a user device) and Application Servers (backend services). The API consumer has a pre-defined set of Quality of Service (QoS) profiles which they could choose from depending on their latency or throughput requirements. The QoS profiles are defined by the API provider and are mapped to the connectivity characteristics of the supported networks.

API functionality

The QoS Profiles API provides the following functionality:

• Discover all QoS profiles offered by the API provider
• Discover the available QoS profiles for a specific device
• Retrieve the characteristics of a specific QoS profile by name

How QoS profiles are mapped to connectivity characteristics are subject to agreements between the API provider and the API consumer. Within the CAMARA project, you can find a sample for such a mapping of QoS profiles. CAMARA QoS Profiles Mapping Table (REFERENCE DRAFT)

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile.

The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

Identifying the device from the access token

The two operations defined by this API (getQosProfile and retrieveQoSProfiles) both allow the API consumer to use a three-legged access token to specify a target device as a query filter. When provided, only profiles available to the specified target device will be returned. Additionally, when a two-legged access token is used, the operation retrieveQoSProfiles allows the API consumer to optionally specify the target device in the request body.

Hence, for the retrieveQoSProfiles operation:

• When invoked using a two-legged access token, the optional input device object will be used as filter if present.

• When invoked using a three-legged access token, this optional identifier in the request body MUST NOT be provided, as the device to filter will be uniquely identified from the access token.

This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process.

Error handling:

• If the device can be identified from the access token and the optional device object is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same device is identified by these two methods, as the server is unable to make this comparison.

Multi-SIM scenario handling

In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify a single device from that phone number. When filtering QoS profiles by device in such scenarios, one of the following options should be used:

• Use the authorisation code flow to obtain a 3-legged access token, which will automatically identify the intended device
• Identify the intended device from a unique identifier for that device, such as its source IP address and port
• Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

Please refer to the CAMARA_common.yaml of the Commonalities Release associated to this API version for a complete list of error responses. The applicable Commonalities Release can be identified in the API Readiness Checklist document associated to this API version.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

The Quality-On-Demand (QoD) API provides a programmable interface for developers and other users (API consumers) to request stable latency or throughput managed by networks without the necessity to have an in-depth knowledge of the underlying network complexity (e.g. the 4G/5G system in case of a mobile network).

Introduction

Industrial (IoT), VR/Gaming, live video streaming, autonomous driving and many other scenarios demand network communication quality and are sensitive to any change in transmission conditions. Being able to request a stable latency (reduced jitter) or prioritized throughput from the network can improve user experience substantially.

The QoD API offers the application developers the capability to request for stable latency (reduced jitter) or throughput for some specified application data flows between application clients (within a user device) and application servers (backend services). The developer has a pre-defined set of Quality of Service (QoS) profiles which they could choose from depending on their latency or throughput requirements.

The usage of the API is based on QoS session resources, which can be created (based on available QoS profiles), queried and deleted. The deletion of a requested session can be triggered by the API consumer or can be triggered automatically once the QoS session has reached its limit.

Relevant terms and definitions

• QOD service endpoint: The URL pointing to the RESTful resource of the QoD API.

• Authentication: Security access keys such as OAuth 2.0 client credentials used by client applications to invoke the QoD API.

• QoS profiles: Latency, throughput or priority requirements of the application mapped to relevant QoS profile values. The set of QoS Profiles that an API provider is offering may be retrieved via the qos-profiles API (cf. https://github.com/camaraproject/QualityOnDemand/) or will be agreed during the onboarding with the API provider.

• Identifier for the device: At least one identifier for the device (user equipment) out of four options: IPv4 address, IPv6 address, Phone Number, or Network Access Identifier assigned by the mobile network operator for the device. Where more than one device identifier is provided, only one identifier will be selected by the implementation and this choice indicated to the API consumer in the session details. If only a single device identifier is provided, the implementation may or may not include the device identifier in the session details.

  Note: Network Access Identifier is defined for future use and will not be supported with this version of the API.

• Identifier for the application server: IPv4 and/or IPv6 address of the application server (application backend)

• App-Flow (between the application client and application server): The precise application data flow the developer wants to prioritize and have stable latency or throughput for. This flow is in the current API version determined by the identified device and the application server. And it can be further elaborated with details such as ports or port-ranges. Future version of the API might allow more detailed flow identification features.

• Duration: Duration (in seconds) for which the QoS session (between application client and application server) should be created. Limits for session duration can be set by the implementation for the QoS profile. The user may request a termination before its expiration.

• Notification URL and token: The API consumer may provide a callback URL (sink) on which notifications about all status change events (eg. session termination) can be received from the API provider. This is an optional parameter. The notification will be sent as a CloudEvent compliant message. If sink is included, it is RECOMMENDED for the client to provide as well the sinkCredential property to protect the notification endpoint. In the current version, sinkCredential.credentialType MUST be set to ACCESSTOKEN if provided.

API functionality

The usage of the QoD API is based on QoS profile classes and parameters which define App-Flows. Based on the API, QoS session resources can be created, queried, and deleted. Once an offered QoS profile class is requested, application users get a prioritized service with stable latency or throughput even in the case of congestion. The QoD API has the following characteristics:

• A specified App-Flow is prioritized to ensure stable latency or throughput for that flow.
• The prioritized App-Flow is described by providing information such as device IP address (or other device identifier) & application server IP addresses and port/port-ranges.
• The developer specifies the duration for which they need the prioritized App-flow.
• Stable latency or throughput is requested by selecting from the list of QoS profiles made available by the service provider (e.g. QOS_E) to map latency and throughput requirements.
• The API consumer can optionally also specify callback URL (sink param) on which notifications for the session can be sent.
  

Following diagram shows the interaction between different components

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile.

The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

Identifying the device from the access token

This API requires the API consumer to identify a device as the subject of the API as follows:

• When the API is invoked using a two-legged access token, the subject will be identified from the optional device object, which therefore MUST be provided.

• When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process.

Error handling:

• If the subject cannot be identified from the access token and the optional device object is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.

• If the subject can be identified from the access token and the optional device object is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same device is identified by these two methods, as the server is unable to make this comparison.

• If the requested qosProfile exists but is currently not available for creating a session (e.g., its status is INACTIVE or DEPRECATED), then the server will return an error with the 422 QUALITY_ON_DEMAND.QOS_PROFILE_NOT_APPLICABLE error code.

Multi-SIM scenario handling

In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device to which the enhanced QoS profile should apply from that phone number. If the phone number is used as the device identifier when creating a QoS session in a multi-SIM scenario, the API may respond with an error, apply the enhanced QoS profile to all devices in the multi-SIM group, or apply the enhanced QoS profile to a single device in the multi-SIM group which may not be the intended device.

Possible solutions in such a scenario include:

• Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
• Identifying the intended device from a unique identifier for that device, such as its source IP address and port
• Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

Please refer to the CAMARA_common.yaml of the Commonalities Release associated to this API version for a complete list of error responses. The applicable Commonalities Release can be identified in the API Readiness Checklist document associated to this API version.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.