#Definitions and Terminology
Connected Services Framework (CSF) — Version 2.0
This document provides a single, consolidated reference for all acronyms, abbreviations, and special terminology used throughout the CSF documentation. It is intended for readers who are new to the CSF or the UK telecoms switching landscape.
#1. Acronyms and Abbreviations
| Abbreviation | Full Term | Definition |
|---|---|---|
| BSS | Business Support System | The back-office systems used by a CP to manage customers, orders, billing, and operations. A MAP may integrate with a CP's BSS to automate message exchange. |
| CP | Communications Provider | An organisation participating in an industry process (e.g., OTS, SforB) that creates or consumes messages and sends or receives them via a MAP. CPs include retailers, wholesalers, and agencies providing services on behalf of other CPs. |
| CSF | Connected Services Framework | An open, free-to-use set of message communication standards that define how MAPs exchange messages securely and efficiently on a peer-to-peer basis, without reliance on a centralised hub. |
| DDG | Detail Design Group | The original industry group that documented the requirements for the technologies and processes of switching residential broadband and voice services, which Ofcom termed "One Touch Switch." |
| DKIM | DomainKeys Identified Mail | A message authentication standard defined in RFC 6376. It uses public/private key pairs to sign messages and verify that they have not been altered in transit. The CSF adapts DKIM — originally designed for email — for HTTP message signing between MAPs. |
| DNS | Domain Name System | The internet system that resolves domain names to IP addresses. In the CSF, DNS TXT records serve two critical purposes: publishing CP public keys for signature verification, and recording which MAP is authorised to act on behalf of each CP. |
| FCS | Federation of Communication Services | The UK trade body that publishes the Switching for Business (SforB/GPLB) process documentation on behalf of the GPLB Steering Group. |
| FQDN | Fully Qualified Domain Name | The complete domain name for a specific host on the internet (e.g., api.mymap.com). Used in the CSF to specify API endpoint addresses. Must comply with RFC 1035. |
| GPLB | Gaining Provider Led Business Switching | The original name for the industry process for switching business telecommunications services. Now branded as Switching for Business (SforB). Ofcom has not mandated a single technical solution for this process. |
| HMAC | Hash-based Message Authentication Code | A cryptographic technique for verifying data integrity and authenticity using a secret key and a hash function. Referenced in the CSF in the context of API key security. |
| HMAP | Hub Managed Access Provider | A specialised MAP type that operates as a hub-and-spoke delivery mechanism (e.g., TOTSCo). An HMAP accepts messages and forwards them among its subscribed members without reading or processing the message body. |
| IAS | Internet Access Service | A broadband or internet connectivity service provided to end customers. One of the service types covered by the Switching General Conditions. |
| IETF | Internet Engineering Task Force | The international standards body that publishes RFCs defining internet protocols and standards used by the CSF (TLS, OAuth 2.0, DKIM, UUID, etc.). |
| IPG | Industry Process Group | A working group within TOTSCo responsible for generating and proposing changes to OTS and SforB process documentation. |
| JAM | JSON Asynchronous Message | The industry-wide messaging standard published on the OTA2 website. JAM defines the envelope format — addressing, routing, correlation, and audit data — used by all CPs and MAPs regardless of the underlying transport (CSF, TOTSCo Hub, or other). |
| JWT | JSON Web Token | A compact, URL-safe token format used in OAuth 2.0. JWTs carry signed claims (such as identity, scope, and expiry) and are used as bearer tokens in CSF API authentication. |
| KYC | Know Your Customer | The due-diligence checks an entity performs before establishing a commercial or technical relationship with a customer — typically identity verification, company registration evidence, ICO registration, anti-fraud screening, and any sector-specific obligations. In the CSF, KYC controls are the MAP's commercial responsibility; the framework does not impose its own KYC requirements on top of those a MAP already operates. MAPs joining TOTSCo already have KYC processes in place; TOTSCo's existing onboarding for MAPs and CPs (under both OTS and SforB/GPLB) carries this work forward unchanged when TOTSCo participates as an HMAP. |
| MAP | Managed Access Provider | An organisation that facilitates message exchange on behalf of one or more CPs by offering integration services, portals, and technical solutions. A MAP is the only entity authorised to exchange messages with other MAPs over the CSF. A CP can become a MAP of 1 (serving only itself) by implementing the MAP rules. |
| MoU | Memorandum of Understanding | The agreement governing collaboration between MAPs and CPs participating in the CSF. Designed to be simple to join, with no licensing fees. |
| NBICS | Number-Based Interpersonal Communications Service | A voice telephony service provided to end customers. One of the service types covered by the Switching General Conditions. |
| OAuth | Open Authorisation | See OAuth 2.0 below. |
| OG | Operations Group | A working group within TOTSCo responsible for operational aspects of OTS and SforB. |
| Ofcom | Office of Communications | The UK's communications regulatory authority. Ofcom mandates the Switching General Conditions and oversees both OTS and SforB processes. |
| OTA2 | Office of the Telecommunications Adjudicator | The industry body accountable for publishing and controlling the RCPID Standards and the JSON Asynchronous Messaging Specification (JAM). All documentation is published on the OTA2 website. |
| OTS | One Touch Switch | The Ofcom-mandated process for switching residential IAS and NBICS services between consumer CPs. All OTS messages must be routed via the TOTSCo Hub. |
| PKCE | Proof Key for Code Exchange | A security extension to the OAuth 2.0 Authorisation Code flow that prevents authorisation code interception attacks. Recommended for public clients. |
| PKI | Public Key Infrastructure | A framework for managing cryptographic key pairs and digital certificates. In the CSF, PKI is implemented via DKIM (RFC 6376) to sign and verify messages between MAPs. Each CP has a public key (published in DNS the CP owns) and a private key (held by whichever entity the CP has authorised to sign — typically the CP's MAP, or held in-house when the CP operates as a MAP of 1). The CP controls who is authorised to sign on its behalf via the DNS-published public key, and revokes that authorisation at any time by rotating the record. |
| RCPID | Retail Communications Provider Identifier | A unique identifier assigned to a CP brand for the purpose of message exchange. In the CSF, RCPIDs use the UUIDv4 format (RFC 4122) and remain with the CP for the lifetime of that brand, even when changing MAPs. |
| RFC | Request for Comments | A publication series from the IETF that defines internet standards, protocols, and technical specifications. Key RFCs used by the CSF include RFC 8446 (TLS 1.3), RFC 6376 (DKIM), RFC 6749 (OAuth 2.0), and RFC 4122 (UUID). |
| RPO | Recovery Point Objective | The maximum acceptable amount of data loss measured in time. Used in CSF disaster recovery planning — defines how far back data can be recovered from. |
| RTO | Recovery Time Objective | The maximum acceptable length of time a system can be offline after a failure. Used in CSF disaster recovery planning — defines how quickly service must be restored. |
| SforB | Switching for Business | The current branding for the GPLB process — the industry process for switching business telecommunications services. This is the CSF's initial application. |
| SI | Systems Integrator | An organisation that provides technology solutions and integration services to CPs and MAPs. Several SIs have contributed to the CSF design. |
| SLA | Service Level Agreement | A formal commitment defining expected performance levels. The CSF defines SLAs for MAP-to-MAP transactions, including response times, fix times, and availability targets. |
| Switchable Asset Base | — | The total count of customer services across all of a MAP's CPs that can be switched as part of the Switching for Business (SforB) protocol. Comprises IAS (Internet Access Service — broadband, e.g. FTTP/FTTC/cable/fixed-wireless) and NBICS (Number-Based Interpersonal Communications Service — voice telephony, e.g. landline/VoIP). A single business customer may contribute multiple assets to the count (one IAS + one NBICS = two switchable assets). Used as input to the CSF capacity-planning formula in part1-framework §9.10 (Messages/second = Total Switchable Asset Base ÷ 1,000, minimum 2/s). |
| TAG | Telecom Technical Architecture Group | A consortium of telecoms industry stakeholders — including MAPs, SIs, and CPs — responsible for the development, publication, and change control of the CSF. The TAG steering group meets weekly (Wednesdays). |
| TLS | Transport Layer Security | A cryptographic protocol providing secure communication over networks. The CSF mandates TLS 1.3 (RFC 8446) for all connections. Earlier versions must not be used. |
| TOTSCo | Telecoms One Touch Switching Company | The organisation operating the centralised hub for OTS message routing. TOTSCo also publishes OTS process and technical documentation. For SforB, TOTSCo may operate as an HMAP within the CSF. |
| UUID | Universally Unique Identifier | A 128-bit identifier standardised by RFC 4122. The CSF uses UUIDv4 (random) for RCPIDs, providing 122 bits of randomness and a collision probability of approximately 1 in 2.71 x 10^18. |
#2. CSF-Specific Terminology
#2.1 The Three-Tier Registry Model
The CSF uses a three-tier model for distributing CP information across the network. Understanding the distinction between these three tiers is essential.
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ Tier 1: CP Registry │
│ ───────────────── │
│ Published by each MAP. Contains that MAP's CPs with full │
│ metadata (RCPID, brand, PKI domains, contacts, resources). │
│ Shared WITH OTHER MAPs via an OAuth 2.0-protected API. │
│ │
│ │ │
│ ▼ (each MAP collects all other MAPs' CP Registries) │
│ │
│ Tier 2: Master Registry │
│ ─────────────────────── │
│ Built PRIVATELY by each MAP. The converged view of ALL CP │
│ Registries. Contains full routing, PKI signing domains, and │
│ contact details for every CP in the entire CSF network. │
│ Used internally for message routing and signature verification. │
│ │
│ │ │
│ ▼ (each MAP filters and simplifies for its own CPs) │
│ │
│ Tier 3: Directory │
│ ──────────────── │
│ A cut-down view shared with the MAP's OWN CPs. Contains │
│ only brand names and RCPIDs — for drop-down lists, search, │
│ and message addressing. Excludes routing, PKI, and operational │
│ details. │
│ │
└─────────────────────────────────────────────────────────────────────┘| Term | What It Is | Who Creates It | Who Sees It | Contains |
|---|---|---|---|---|
| CP Registry | A JSON document published by a MAP | Each MAP publishes one | Other MAPs (via API) | Full CP metadata, PKI signing domains, contacts, routing groups |
| Master Registry | The converged view of all CP Registries | Each MAP builds its own | Private to that MAP only | Everything from all CP Registries — used for routing and verification |
| Directory | A filtered extract from the Master Registry | Each MAP creates one for its CPs | The MAP's own CPs | Brand names, RCPIDs, supported processes — for selection lists only |
#2.2 Entity Types
| Term | Definition |
|---|---|
| Communications Provider (CP) | Any party participating in an industry process — creating, consuming, sending, or receiving messages. CPs include retailers, wholesalers, and agencies. A CP does not need to understand the CSF — it interacts only with its MAP. |
| Managed Access Provider (MAP) | An organisation that facilitates message exchange on behalf of CPs. MAPs handle PKI signing, OAuth 2.0 authentication, CP Registry publication, message routing, and delivery guarantees. The only entity authorised to exchange messages over the CSF. |
| MAP of 1 | A CP that acts as its own MAP — operating CSF infrastructure to exchange messages directly with other MAPs. Must comply with all MAP rules. Allows CPs to exchange messages for free without a third-party MAP. |
| Hub MAP (HMAP) | A specialised MAP that operates a hub-and-spoke model (e.g., TOTSCo). Accepts messages and forwards them without reading the message body. Not required to implement DKIM/PKI signing. |
| Sponsor MAP | An existing, onboarded MAP assigned (via round-robin rotation) to guide a new MAP through the onboarding process. Acts as a gatekeeper to the CSF network. Sponsor MAPs are not expected to charge for onboarding; an optional fee may be charged when significant time and effort is required, capped at £3,000 + VAT for a traditional (multi-CP) engagement or £350 + VAT for a single-cp (MAP-of-1) engagement. Charged once per MAP regardless of how many protocols it carries. See Part 1 §7.2.1 for the full fee model. |
| New MAP | An organisation seeking to join the CSF. Must complete the full sponsored onboarding process before publishing its CP Registry or exchanging production messages. |
#2.3 Messaging Terms
| Term | Definition |
|---|---|
| Envelope | The outer wrapper of a JAM message containing delivery instructions: source RCPID, destination RCPID, routing ID, correlation ID, and audit data. Defined by the JAM Specification. The CSF is responsible for the envelope; the message body is defined by the industry process. |
| Message Body | The inner content of a JAM message containing the industry process payload (e.g., a Switch Match request, a Switch Order). Opaque to the CSF transport layer unless the MAP provides a hosted solution. |
| Letterbox | The REST API endpoint used by MAPs to send and receive messages. Accepts a JAM-formatted JSON message via HTTP POST over TLS 1.3 with OAuth 2.0 authentication. Returns HTTP 202 on successful acceptance. |
| Routing ID | A string in the JAM envelope that identifies the type of message (e.g., businessSwitchMatchRequest, residentialSwitchOrderConfirmation). Used by MAPs to route messages to the correct service endpoint. |
| Routing Group | A named collection of routing ID patterns (regular expressions) that determines which message types are accepted by a specific MAP service endpoint. For example, businessSwitch.* matches all SforB messages. |
| Correlation ID | A unique string in the JAM envelope used to link a response message back to the original request. The source always includes a correlation ID; the destination includes it only in response messages. UUIDs are recommended. |
| Audit Data | An array of name-value pairs in the JAM envelope used for regulatory reporting, diagnostics, and industry auditing. Each industry process defines its own audit requirements. |
| Contact Object | A reusable JSON structure (contact array) used at both the MAP level and the CP level in the CP Registry. Contains type (phone, email, url), value, purpose (sales, support, technical), availabilityFrom, availabilityTo, availabilityDays, and comment. Allows each entity to advertise its preferred contact methods and trading hours. The same structure is used for both MAP and CP contacts — MAP contacts are for MAP-to-MAP technical issues; CP contacts are for CP-to-CP operational escalations. |
| Bit pipe | Refers to a network provider that simply moves data without adding value or examining content. The CSF is, by design, a bit pipe for SforB (and other industry processes that may use it) — it carries the JAM envelope between MAPs and does not interpret the message body. This is what allows the same transport to carry multiple industry protocols, and what keeps end-consumer business state (customers, SORs, ServiceIdentities, billing) entirely with the CP rather than with the transport. |
#2.4 Security Terms
| Term | Definition |
|---|---|
| X-CSF-SIGNATURE | The HTTP header that carries the DKIM signature of a CSF message. Contains the signing algorithm, selector (CP RCPID), domain, body hash, headers included, and the signature value. |
| X-CSF-SIGNATURE-DATESTAMP | The HTTP header containing the timestamp of when the signature was created (yyyyMMddHHmmssS). Embedded in the signature to protect against replay attacks. |
| X_CSF_ROUTE | An optional HTTP header recording the route a message has taken through the network. Each MAP adds a new header entry with a timestamp and MAP name. Used for diagnostics. |
| Selector | In DKIM, the identifier used (together with the domain) to locate the public key in DNS. In the CSF, the selector is always the CP's RCPID. |
| Domain Key Record | A DNS TXT record at [RCPID]._domainkey.[cp-domain] containing the CP's public key in RFC 6376 format. Used by receiving MAPs to verify message signatures. |
| MAP Key Record | A DNS TXT record at [RCPID]._mapkey.[cp-domain] containing the URL of the CP's MAP message endpoint. Used for routing verification and conflict resolution. Controlled by the CP. |
| PERM_FAIL (8101) | A CSF PKI error code indicating that message signature verification has permanently failed. Retrying will not resolve the issue. Returned with HTTP 403. |
| TEMP_FAIL (8102) | A CSF PKI error code indicating that message signature verification has temporarily failed (e.g., DNS lookup error). A retry may resolve the issue. Returned with HTTP 403. |
| Client Credentials Flow | The OAuth 2.0 flow used by the CSF for machine-to-machine (MAP-to-MAP) authentication. No user interaction is required — the MAP authenticates using a client_id and client_secret. |
| Bearer Token | An OAuth 2.0 access token included in the Authorization HTTP header (Bearer {token}) to authenticate API requests. Typically a JWT with a limited lifetime (e.g., 1 hour). |
| Forward Secrecy | A property of TLS 1.3 where session keys cannot be recovered even if the server's long-term private key is compromised. Mandated by the CSF. |
#2.5 Error Code Series
| Series | Scope | Purpose |
|---|---|---|
| 9xxx | Industry-wide | Validation and delivery error codes defined by the OTS/TOTSCo standards. Used by both the CSF and TOTSCo Hub for message validation failures and asynchronous delivery failures. |
| 8xxx | CSF-specific | Error codes introduced by the CSF for PKI signing and verification failures. Currently defines 8101 (PERM_FAIL) and 8102 (TEMP_FAIL). Not sent to TOTSCo. |
#2.6 Switching Process Terms
| Term | Definition |
|---|---|
| Switch Match | The process where a Gaining CP submits customer details to a Losing CP to identify and match the customer's existing services. The first step in the switching process. |
| Switch Order | The formal order to proceed with switching a customer's services from the Losing CP to the Gaining CP. Follows a successful Switch Match. |
| Gaining CP (GCP/GRCP) | The CP that is acquiring the customer — the initiator of the Switch Match. |
| Losing CP (LCP/LRCP) | The CP that currently serves the customer and will lose them as a result of the switch. |
| In-Flight Order | A Switch Order that has been submitted but not yet completed. The CSF includes mechanisms for transferring in-flight orders when a CP changes MAP. |
| RCPID Status Request | A CSF message sent by a new MAP to the old MAP when a CP transitions. Triggers the export of in-flight order data and signals the move. Validated via DNS to confirm the requesting MAP is the CP's new authorised provider. |
| SOR | Switch Order Reference — a reference number associated with a Switch Order. SORs have a validity period (typically 31 days) and cannot be transferred between MAPs; they must be re-issued. |
#2.7 Operational Terms
| Term | Definition |
|---|---|
| Onboarding | The structured, multi-phase process by which a new MAP or CP is verified, tested, and granted access to exchange messages over the CSF. |
| Sponsor | See Sponsor MAP in Entity Types above. |
| Conflict | A state in the Master Registry where a CP appears in more than one MAP's CP Registry simultaneously. Resolved using DNS-based verification to determine the legitimate MAP. |
| Conflict Resolution | The process by which MAPs use DNS _mapkey lookups to determine which MAP legitimately represents a CP when duplicate entries exist. The CP controls routing through its DNS records. |
| Feature Discovery | The mechanism by which a MAP queries another MAP's CP Registry to identify which features, API versions, and industry processes are supported. Enables automatic negotiation of the highest compatible version. |
| Exponential Backoff | A retry strategy where the wait time between retry attempts increases exponentially (e.g., 1s, 2s, 4s, 8s). Used by MAPs when message delivery fails. Jitter (random variation) should be added to prevent thundering herd problems. |
| Circuit Breaker | An enterprise pattern where, after N consecutive failures to a destination, the MAP temporarily stops sending and raises an alert rather than continuing to retry. Prevents overloading a failing MAP. |
#3. Key RFCs Referenced by the CSF
| RFC | Title | CSF Usage |
|---|---|---|
| RFC 4122 | UUID URN Namespace | UUIDv4 format for RCPIDs |
| RFC 6376 | DomainKeys Identified Mail (DKIM) Signatures | Message signing and verification between MAPs |
| RFC 6749 | OAuth 2.0 Authorisation Framework | API authentication (Client Credentials flow) |
| RFC 8446 | TLS 1.3 | Mandatory transport encryption for all CSF connections |
| RFC 8463 | Ed25519 for DKIM | Alternative signing algorithm (shorter keys than RSA) |
| RFC 1035 | Domain Names — Implementation and Specification | FQDN format compliance for endpoint addresses |
#4. Industry Standards and Governance Bodies
| Body | Role in CSF Context |
|---|---|
| Ofcom | UK communications regulator. Mandates the Switching General Conditions. Has mandated OTS via a single hub but has not mandated a single technical solution for SforB. |
| OTA2 | Publishes and controls the RCPID Standards and JAM Specification — the foundational addressing and envelope formats used by the CSF. |
| TOTSCo | Operates the centralised OTS Hub. Publishes OTS process documents, message specifications, and the Hub API Specification (v2.0). May operate as an HMAP within the CSF for SforB. |
| GPLB-SG | The GPLB Steering Group — an independent body of industry stakeholders working alongside the OTA2, that guides and facilitates the steering meetings and the publication of the SforB process documentation. Note: the steering group retains the historical "GPLB" label even though the process it stewards has been renamed from Gaining Provider Led Business switching to Switching for Business (SforB) as a more suitable name for the protocol. Publishes the SforB process documents, matching specifications, SforB Response Codes, and SLAs via FCS. |
| TAG | The Telecom Technical Architecture Group. Develops, publishes, and controls the CSF documentation. Meets weekly. Maintains autonomy over CSF changes. |
| FCS | Federation of Communication Services. Publishes the GPLB-SG documentation on its website. |