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 specification, 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.

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.

Summary

This API provides the customer with the ability to check if the user of the line is older than a provided age, in order to provide API customer's age-restricted services, access to its age-restricted website etc..

API functionality

The API defines one service endpoint:

• POST /verify

  Takes the network subscription identifier (e.g. the mobile phone number for a mobile network subscriber) and checks if the age of the subscriber is older than the age threshold in the request. Additionally, as optional function, provides (1) if age check is done against another form of official identification (Note) or not (verifiedStatus), (2) an overall score of how certain is the response using both information provided in the request and information that the Operator holds(identityMatchScore), (3) an indicator on whether the subscription has any kind of content lock (contentLock) and (4) an indicator on whether the subscription has any kind of parental control activated (parentalControl). Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.

Inputs

The endpoint request body is a JSON object with the following parameters:

• phoneNumber: The network subscription identifier (i.e. the phone number of the subscriber). [Required only in case a 2-legged flow has been agreed between API Provider and API Consumer following CAMARA directives; otherwise, phoneNumber must not be included]
• ageThreshold: The age threshold from which the age of the user must be compared. [Required]
• any of idDocument, name, givenName, familyName, middleNames, familyNameAtBirth, birthdate, email; additional subscriber's information to be checked in order to confirm that the subscriber is the contract's owner [Optional]
• includeContentLock and includeParentalControl: These two flags allow the API Client to indicate that the corresponding response properties contentLock and parentalControl should be returned. Its implementation is optional for the API Provider, so in such cases, these parameters will be ignored. [Optional]

Outputs

If successful, a JSON object is returned containing the following data:

• ageCheck: Indicate 'true' when the age of the user is the same age or older than the age threshold (age >= age threshold), and 'false' if not (age < age threshold). Otherwise, 'not_available'.
• verifiedStatus: true if the information provided was checked against another form of official identification (Note), otherwise false. Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.
• identityMatchScore: The overall score of identity information available in the Operator, information either provided in the request body comparing it to the one that the MNO holds or directly using internal MNO's information. It is optional for the Operator to return the Identity match score.
• contentLock: Indicates if the subscription associated with the phone number has any kind of content lock (i.e certain web content blocked).
• parentalControl: Indicates if the subscription associated with the phone number has any kind of parental control activated.

Errors

• If the authentication access token is not valid, a 401 UNAUTHENTICATED error is returned
• If the API call contains a formatting or other any other syntactic error, a 400 INVALID_ARGUMENT error is returned.
• If the network subscription cannot be identified from the provided parameters (e.g. the subscription identifier is not associated with any customer of the CSP), a 404 IDENTIFIER_NOT_FOUND error is returned.
• If the API consumer has a valid access token that does not have the required scope to obtain Age Verification information for the specified network subscription, then a 403 PERMISSION_DENIED error is returned.

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.

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number 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 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 phoneNumber field 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 phoneNumber field 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 phone number is identified by these two methods, as the server is unable to make this comparison.

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.

Further info and support

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

Summary

The CAMARA Know Your Customer (KYC) Tenure API allows for verification that a network subscriber has been a customer of the Communications Service Provider (CSP) for a specified minimum length of time so as to establish a level of trust for the associated network subscription identifier.

API functionality

The API defines one service endpoint:

• POST /check-tenure

  Takes the network subscription identifier (e.g. the mobile phone number for a mobile network subscriber) and the specified minimum tenure date to validate for the associated network subscription. This endpoint will respond with a confirmation of whether or not the network subscriber tenure is longer than the specified date timestamp, optionally supplemented with details of the subscription contract type.

To call this endpoint, the API consumer must first obtain a valid access token with the specified scope from the specified token endpoint, which is then passed to the endpoint via the Authorization header. For more details on access token processing, see below.

Inputs

The endpoint request body is a JSON object with the following parameters:

• tenureDate: The date from which continuous tenure of the identified network subscriber is required to be confirmed. This field is always required.
• phoneNumber: The network subscription identifier (i.e. the phone number of the subscriber). This field is only required if no network subscription identifier is associated with the access token.

Outputs

If successful, a JSON object is returned containing the following data:

• tenureDateCheck: true when the identified network subscription has had valid tenure since tenureDate, otherwise false
• contractType: The network subscription account type, if known

An example of a JSON response object is as follows:

{
    "tenureDateCheck": true,
    "contractType": "PAYM"
}

Errors

If the authentication token is missing, not a valid token, or is no longer valid, a 401 UNAUTHENTICATED error is returned

If the API call contain a formatting or other error, a 400 INVALID_ARGUMENT error is returned. This includes cases where:

• The tenureDate is in the future (greater than the current date)
• The date format is invalid or does not conform to RFC 3339 / ISO 8601 (YYYY-MM-DD)

If the network subscription cannot be identified from the provided parameters (e.g. the subscription identifier is not associated with any customer of the CSP), a 404 IDENTIFIER_NOT_FOUND error is returned.

If the API consumer has a valid access token that does not have the required scope to obtain tenure information for the specified network subscription, then a 403 PERMISSION_DENIED error is returned.

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.

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number 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 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 phoneNumber field 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 phoneNumber field 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 phone number is identified by these two methods, as the server is unable to make this comparison.

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.

Further info and support

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

The Consent Info API allows API Consumers to easily validate whether they have the necessary permissions to process User's personal data for a specific Purpose before using other CAMARA APIs. It provides a simple true/false response and, when applicable, a URL to direct the User to manage their Consent.

Introduction

This API facilitates compliance with privacy regulations and promotes transparency with Users by providing a standardized way to check whether, for example, the User has given their Consent or opted out of data processing. Key inputs include the specific scope(s) of access being requested (i.e. the CAMARA API(s) operations to which the data processing refers), the Purpose for data processing, and a User identifier (either explicitly provided or derived from a three-legged access token). The API responds with the validity status of the data processing, and, when applicable, can provide a capture URL for the API Consumer to manage it.

Relevant terms and definitions

• Consent: An explicit opt-in action that the User takes to allow processing of personal data. Consent grants the API Consumer access to a set of scopes related to the User for a specific Purpose.
• Purpose: The reason for which personal data will be processed by an API Consumer. CAMARA defines a standard set of Purposes which can be used by API Consumers to specify the reason for their intended personal data processing. CAMARA uses the W3C Data Privacy Vocabulary (DPV) to represent these purposes e.g. dpv:FraudPreventionAndDetection or dpv:RequestedServiceProvision.
• Scope: A string representing the specific access rights or actions an API Consumer requests from the User for their data (e.g., "location-verification:verify"). A request can contain multiple scopes.

API Functionality

This API enables the API Consumer to determine whether their data processing is permitted for a given User, scope(s) and Purpose.

Specifically, the API:

• Provides the data processing validity status: The API returns statusValidForProcessing, a boolean flag that indicates whether the requested data processing is currently permitted (true) or not (false).
• Provides an explanation if invalid: If data processing is not permitted, the response includes a statusReason field to explain why.
• Offers a Capture URL (if requested): If the status is not valid because user action is required, and the API Consumer sets requestCaptureUrl to true, the API will return a captureUrl field that can be presented to the User. This URL directs them to the API Provider's secure Consent capture channel, where they can provide or renew their Consent.

Importantly, this API does NOT delegate Consent capture to the API Consumer but rather empowers the API Consumer to present the API Provider's Consent capture URL at the most opportune time and place. The actual Consent capture occurs within the API Provider's secure environment, ensuring the User's authentication with the API Provider.

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 phone number from the access token

This API requires the API consumer to identify a phone number 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 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 phoneNumber field 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 phoneNumber field 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 phone number is identified by these two methods, as the server is unable to make this comparison.

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.

Further info and support

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

The API can be used to check whether the subscriber of the phone number has changed. A common scenario is when Application service provider (ASP) wants to check whether there has been a change in the user associated with the phone number after the specified date. This allows the ASP to ensure that a phone number is correctly linked to a user and prevent the mis-delivery of SMS messages.

For example, below are potential scenarios:

• Scenario 1
  • Pre-conditions
    • User A signed a contract with MNO A for the phone number '+123456789' on October 9, 2023, and is still using it.
    • User A also signed contracts with ASP A on December 22, 2023 for its services.
    • ASP A holds the contract date (2023-12-22) and the phone number (+123456789) for User A.
    • Currently, on November 2, 2024, ASP A wishes to send a SMS message to User A.
  • Potential operations
    • ASP A sends a request with specified date (2023-12-22) and phone number (+123456789) to the Number Recycling API.
    • The API response sets to 'false', indicating that there has not been a change in the user associated with the phone number.
  • Post-conditions
    • ASP A decides to send the SMS message to User A.
  • By following these steps, ASP A ensures that a phone number is linked to User A.

Note:

• When API receives a request with specified date on which a user signed a contract with MNO, the API respond sets to 'false'(e.g., 2023-10-09 in the Scenario 1 of the figure above).

  • Scenario 2
    • Pre-conditions
      • User A signed a contract with MNO A for the phone number '+123456789' on October 9, 2023, and canceled it on February 25, 2024. Subsequently, User B signed a contract with MNO A for the same phone number on September 21, 2024, and is still using it.
      • User A also signed contracts with ASP A on December 22, 2023 for its services.
      • ASP A holds the contract date (2023-12-22) and the phone number (+123456789) for User A.
      • Currently, on November 2, 2024, ASP A wishes to send a SMS message to User A.
    • Potential operations
      • ASP A sends a request with specified date (2023-12-22) and phone number (+123456789) to the Number Recycling API.
      • The API response sets to 'true', indicating that there has been a change in the user associated with the phone number.
    • Post-conditions
      • ASP A decides to stop sending the SMS message to User A and contacts User A by mail.
    • By following these steps, ASP A ensures that a phone number is not linked to User A and prevents the mis-delivery of the SMS message.

Note:

• When the API receives a request with specified date during which there is no contract with MNO for the phone number, the API respond sets to 'true'(e.g., the period between 2024-02-25 and 2024-09-20 in the Scenario 2 of the figure above).

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 phone number from the access token

This API requires the API consumer to identify a phone number 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 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 phoneNumber field 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 phoneNumber field 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 phone number is identified by these two methods, as the server is unable to make this comparison.

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.

This API provides the ability to retrieve a device location.

Introduction

With this API, API consumers can retrieve the area where a certain user device is localized. The area provided in the response could be described:

• by a circle determined by coordinates (latitude and longitude) and a radius.
• by a simple polygon delimited by segments connecting consecutively an array of coordinates (points). The last point connects to the first point to delimit a closed shape bounded with straight sides.

The retrieved shape depends on the network conditions at the device's location and any of the supported shapes could be received.

The requester could optionally ask for

• a freshness of the localization information by providing a maxAge ("I want a location not older than 600 seconds").
• an accuracy of the localization information by providing a maxSurface ("I want a location not larger than 1000000 square meters").

The result accuracy depends on the network's ability and accuracy to locate the device.

Additionally to location information, the answer will also provide indication about the location time.

Location retrieval API could be useful in scenarios such as:

• Fraud protection to ensure a given user is located in the region, country or location authorized for financial transactions

• Verify the GPS coordinates reported by the app on a device to ensure the GPS was not faked e.g. for content delivery with regional restrictions

• Contextual-based advertising, to trigger advertising after verifying the device is in the area of interest

• Smart Mobility (Vehicle/bikes renting): obtain the location of a vehicle/bike to guarantee they are rented correctly

Note: Location is in most jurisdictions considered to be sensitive data and thereby consent by device owner/user must be verified before providing it to the developer.

Relevant terms and definitions

• Device: A device refers to any physical entity that can connect to a network and participate in network communication.

• Area: It specifies the geographical surface where a device may be physically located.

• Max Age: Maximum age of the location information which is accepted for the location retrieval (in seconds).

  • Absence of maxAge means that "any age" is acceptable for the client. In other words, this is like maxAge=infinite. The system will return lastLocationTime in the response. If the system is not able to provide location, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_LOCATE is sent back.
  • maxAge=0 means that a fresh calculation is requested by the client. If the system is not able to provide the fresh location, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_AGE is sent back.

• Last Location Time : Last date and time when the device was localized.

• Max Surface: Maximum surface in square meters which is accepted by the client for the location retrieval.

  • absence of maxSurface means that "any surface size" is acceptable for the client.
  • API implementation could specify the minimum acceptable maxSurface in the documentation (for example a minimum of 10000 square meters are allowed).
  • If the system is not able to provide an area with a surface acceptable with the client request, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_SURFACE is sent back.
  • Note: if both maxAge and maxSurface requirements fail, the system can either send back one or the other error code.

API Functionality

The API exposes a single endpoint/operation:

• /retrieve : Retrieve where the device is localized. The operation returns:
  • a localization defined either as a circle, with the center specified by the latitude and longitude, and a radius for answer accuracy, or as polygon defined by the array of points delimiting its boundary.
  • a timestamp with the location information freshness.

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.

Multi-SIM scenario handling

In multi-SIM scenarios, where more than one mobile device is associated with the phone number given as input in the API call (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device whose location is to be verified. Check with the API provider what is the expected behaviour when a phone number belonging to a multi-SIM group is used as the device identifier, as the API may response with:

• an error indicating that that phone number is not supported for this API, or
• the location of a single device in the multi-SIM group, if one of the devices is considered linked to the main SIM and this concept is supported by the operator, or
• a location value that combines the location of all the SIMs associated to the requested phone number.

Possible solutions to make the scenario more deterministic include:

• Using preferably 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 API 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.

Further info and support

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