Glossary of Terms and Concepts
The list below introduces several key concepts:
Aggregator
The party that aggregates CAMARA APIs exposed by Operators, and exposes services that utilize these APIs to ASPs. An Aggregator can be a hyperscaler (e.g. Vonage, AWS, Azure, Google Cloud) offering its own services that consume CAMARA APIs, or exposing Operators' CAMARA APIs in an aggregated way, or an Operator acting as an Aggregator, i.e. an Operator aggregating other Operators' CAMARA APIs.
API Exposure Platform
The Operator's platform for exposing CAMARA APIs to ASPs and Aggregators, providing authentication and authorization mechanisms, and End-User Consent management. The API Exposure Platform typically consists of at least an Auth Server and an API Gateway.
Application or Application Backend
The ASP's software services that access CAMARA APIs.
Application Service Provider (ASP)
The Legal Entity that provides the Application and/or services that consume CAMARA APIs.
Authorization (Auth) Server
The authorization server processes requests from an Application to issue an access token upon successful authentication and authorization. The Auth Server provides OpenID Connect (OIDC) compliant endpoints, and is able to authenticate the User by validating the provided user identity with an Identity Provider; the Auth Server exposes the OIDC authorization endpoints and the OIDC token endpoint.
CAMARA
CAMARA is an open-source project within Linux Foundation to define, develop and test the APIs. CAMARA works in close collaboration with the GSMA Operator Platform Group to align API requirements and publish API definitions and APIs. Harmonization of APIs is achieved through fast and agile created working code with developer-friendly documentation. API definitions and reference implementations are free to use (Apache2.0 license). The tool to manage the work and outcomes of the APIs standardization at CAMARA is GitHub: https://github.com/camaraproject
CIBA
CIBA (Client-Initiated Backchannel Authentication) is a type of authentication that allows applications to authenticate a user asynchronously, meaning the user does not need to directly interact with their credentials. In Open Gateway, it is used for backend authentication flows.
Consent
Tn explicit opt-in action that the User takes to allow processing of personal data. Consent grants a Legal Entity (e.g. the Operator or ASP) access to a set of Scopes related to the Resource Owner, for a specific Purpose.
Consumption Device
The physical device on which an Application is installed or running.
End-User
The human participant using an Application on a Consumption Device, only applicable to some CAMARA APIs.
Identity Provider (IdP)
The OpenID Identity Provider, the party that provides authentication as a service (the IdP creates, maintains, and manages identity information).
Legal Entity
The legal subject that processes Personal Data for a specific Purpose.
OAuth 2.0 or OpenID Connect
Standards and protocols for user authentication and authorization, allowing secure access to APIs and services.
Operator
Mobile Network Operator (MNO), Communication Service Provider (CSP), or telco operator exposing network capabilities.
Personal Data or Personally Identifiable Information (PII)
Tata which may identify or relates to an individual as defined within the relevant regulatory framework; for example, this may include an individual's name or address.
Purpose
The reason for which Personal Data will be processed by an Application. For example, an Application might want to create a movie recommendation for an End-User using their Personal Data, such as age or gender. CAMARA defines a standard set of Purposes which can be used by Applications to specify the reason for their intended Personal Data processing.
Resource Owner or User
The End-User or Subscriber which Personal Data processed by a CAMARA API relates to, the Resource Owner has the authority to authorize access to CAMARA APIs which process Personal Data.
Resource Server
The server that exposes protected resources to Applications. The Resource Server requires a valid access token to be provided before allowing access to the protected resource.
Scope
The OpenID Connect scope which maps one or more protected resources, some scopes may require processing of Personal Data.
Subscriber
The mobile subscriber of the Operator. The Subscriber is usually also the End-User, but this is not always the case. For example, a parent may be the Subscriber of a mobile subscription for their child, the End-User.
Three-Legged Access Token
Tn access token that involves three parties: the Resource Owner (User), the Authorization Server (operated by the Operator or Aggregator), and the client (the ASP's Application). In CAMARA, Three-Legged Access Tokens are typically created using the OIDC Authorization Code flow or Client-Initiated Backchannel Authentication (CIBA) flow.
Two-Legged Access Token
Tn access token that involves two parties, the Authorization Server (operated by the Operator or Aggregator), and the client (the ASP's Application); the Two-Legged Access Token does not include a Resource Owner (User). The Authorization Server does not authenticate a User, nor can User Consent be captured or validated for Two-Legged Access Tokens; therefore Two-Legged Access Tokens must only be used for CAMARA APIs that do not process Personal Data.
On this page
- Aggregator
- API Exposure Platform
- Application or Application Backend
- Application Service Provider (ASP)
- Authorization (Auth) Server
- CAMARA
- CIBA
- Consent
- Consumption Device
- End-User
- Identity Provider (IdP)
- Legal Entity
- OAuth 2.0 or OpenID Connect
- Operator
- Personal Data or Personally Identifiable Information (PII)
- Purpose
- Resource Owner or User
- Resource Server
- Scope
- Subscriber
- Three-Legged Access Token
- Two-Legged Access Token