Open-Gateway API V0 save_alt

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

This API allows to check the last time that the phone (device) - phone number association has changed

Introduction

The Device Swap API performs real-time checks on the last Device Swap event, providing real-time information about whether the SIM card associated with a user’s phone number has been transferred to a different physical device.

Device Swap information can be invaluable for enhancing security, fraud detection, and ensuring compliance with regulatory requirements in various applications, apart from providing useful information of device upgrade trends in user segments.

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

• When did the last Device Swap occur?
• Has a Device Swap occurred during the last n hours?

Relevant terms and definitions

Device Swap: A Device Swap is a process in which the association between a user’s mobile phone number (MSISDN) and a device (IMEI) is created for the first time or changes for any reasons.

API Functionality

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

The API provides 2 operations:

• POST retrieve-date: Provides timestamp of latest device swap for a given phone number. If no device swap has been performed, the API will return the first phone number usage in the device (the timestamp of the first time that the phone number was connected to the network, it is, the first time that the SIM is installed in the device) by default. It will return an empty string in case is not possible to retrieve the date (e.g. in case local regulations are preventing the safekeeping of the information for longer than the stated period, or in some edge error cases). In case no data is available in the operators records (e.g. no recorded event), API will return a 422 error.
• POST check: Checks if device swap has been performed during a past period (defined in the request with ‘maxAge’ attribute) for a given phone number, the API will return boolean response (true/false), indicating that the device has been swapped or not in the specified period. In case the phone number has never been installed in a device, or no data is available in the operators records (e.g. database error), API will return a 422 error.

So, when consuming this operation, the following scenarios will exist:

The API is consumed in 3-legged:

• If no phoneNumber is provided in the body, the API will return in the response the information of the phoneNumber that is associated to the access token.
• If the phoneNumber is provided in the body, the API will return in the response the information of that phone number if it matches the one associated to the access token.
• If the phoneNumber provided in the body does not match the one associated to the access token, the API will respond with HTTP 403 INVALID_TOKEN_CONTEXT.

The API is consumed in 2-legged:

• If no phoneNumber is provided in the body, the API will respond with HTTP 400 INVALID_ARGUMENT.
• If the phoneNumber is provided in the body, the API will return in the response the information of the phoneNumber provided in the body.

Resources and Operations overview

The API provides the following endpoints:

• An operation to retrieve last date in which the device of the end-user was swapped.
• An operation to check if the SIM of the end-user has been installed in a different device during a past period

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.

This API provides the customer with the ability to compare the information it (Service Provider, SP) has for a particular mobile phone user with that on file (and verified) by the mobile phone user’s Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the mobile phone user.

Relevant Definitions and concepts

• KYC: stands for Know Your Customer and it is the process of a business verifying the identity of their clients and assessing their suitability, along with the potential risks of illegal intentions towards the business relationship.

• Match Score: a numerical value that quantifies the similarity between two pieces of text based on the words they contain. This score is often used in various applications like text comparison, plagiarism detection, information retrieval, and natural language processing. The score typically reflects how well the words in one text match the words in another text. In the context of this API, this score will be used to determine how much does the input information looks like the information stored in the Operator’s system. Unless otherwise captured in the implementation notes which Operators may publish, score will use the Jaro-Winkler distance algorithm for all countries. This parameter, as optional, will be returned depending on the capability of the Operator to calculate the scoring value. This means that not all Operators will implement this functionality or won’t have the requested parameter available. It can happen that an Operator implements the score functionality but, for whatever reason, is not able to calculate it based on the client’s input or the related stored information. For these cases, the score property related won’t be returned in the response.
  The range of score values is between “0” and “100”, where higher scores indicate a higher similarity between the two compared parameters.

API Functionality

This API allows API clients to verify the matching of a number of attributes related to a customer identity against the account data bound to their phone number. The API is intended to be used in the following scenarios, for example:

• To verify the user personal data during the digital registration of an account to a 3rd party service.

• To prevent fraud, wrong or imprecise information, and/or facilitate the onboarding of a mobile phone user to a 3rd party service.

The API supports a multi-level hierarchy of property validation. In addition to the initial verification of the phoneNumber, an additional idDocument validation may occur based on different Operator requirements. This means that, in those cases, if the value of idDocument is not provided or it does not match the one bound to the specific phone number in the Operator systems, the operation will return an error.

Resources and Operations overview

The API provides the following endpoint:

• An endpoint to verify the matching of a number of attributes related to a mobile phone user identity against the account data bound to their phone number.

Identifying the phoneNumber from the access token

This API requires the API consumer to identify a phoneNumber 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 phoneNumber field, which therefore MUST be provided.
• When a three-legged access token is used, the subject will be uniquely identified from the access token. So, the optional phoneNumber is not used for identifying the subject, but, if it is provided in the API request body, it needs to match with the one associated with the access token.

Error handling:

• If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code. This is an error typically, but not uniquely, returned in 2-legged scenarios when the access token doesn’t identify a single subscription.
• If there is a mismatch between the provided phone number in the request body and the phone number associated with the access token, the server will return an error with the 403 INVALID_TOKEN_CONTEXT error code.

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.

Security

Base URLs