---
title: Connected Services Framework (CSF)
tags: [Overview]

---

# Connected Services Framework (CSF)

**An Open Transport Framework for the UK Telecommunications Industry**

Version 2.0 | Published by the Telecom Technical Architecture Group (TAG)

---

## What is the CSF?

The Connected Services Framework (CSF) is a free, open, and decentralised messaging framework that enables UK Communications Providers (CPs) to exchange messages securely and efficiently through Managed Access Providers (MAPs) — without reliance on a centralised hub or administrative body.

Built on established internet standards (TLS 1.3, OAuth 2.0, DKIM/PKI via RFC 6376) and the industry-standard JSON Asynchronous Messaging Specification (JAM), the CSF provides a peer-to-peer transport layer that any CP or MAP can adopt at zero licensing cost.

## Why CSF?

| Capability | Centralised Hub Model | CSF (Distributed Model) |
|---|---|---|
| **Cost** | Ongoing per-message or subscription fees | Free to operate — no licensing or transaction charges |
| **Independence** | All parties depend on a single operator | Each MAP operates autonomously |
| **Speed of change** | Change requests go through a single vendor | TAG consensus enables rapid iteration |
| **Resilience** | Single point of failure | Distributed — no single point of failure |
| **Scalability** | Hub capacity limits all participants | Each MAP scales independently |
| **CP freedom** | CPs may be locked to a provider | CPs control their MAP choice via DNS |
| **Security** | Trust delegated to hub operator | End-to-end PKI signing verifiable by any party |
| **Onboarding** | Central registration and approval | Peer-sponsored onboarding — operational in hours |
| **Market entry** | Barriers to becoming a provider | Any CP can become a MAP of 1 |

## Initial Use Case: Switching for Business (SforB)

The CSF's first application is delivering **Switching for Business** (SforB), formerly known as Gaining Provider Led Business Switching (GPLB). Unlike One Touch Switch (OTS) for residential customers, Ofcom has not mandated a single technical solution for business switching — enabling the industry to adopt this open, distributed approach.

The framework is not limited to SforB. It is designed to support any industry messaging process, including future applications such as number porting and bilateral communications.

## Documentation Structure

### Reference

| Document | Description |
|---|---|
| [Definitions & Terminology](standalone/definitions.md) | Consolidated reference for all acronyms, abbreviations, and CSF-specific terminology |
| [CP Rights Charter](standalone/cp-rights-charter.md) | Plain-language summary of CP rights under the CSF — standalone, no technical background required |
| [MAP Onboarding & Testing Process](standalone/onboarding-testing-process.md) | Practical handbook for developers, implementers, and testers — environments, status model, NowYoYo PKI test harness, and the TAG Baseline Test Suite |

This documentation is organised into two parts:

### Part 1 — Framework (Management & Architecture)

For decision-makers, solution architects, and programme managers.

| Document | Description |
|---|---|
| [Introduction](part1-framework/01-introduction.md) | Purpose, scope, and value proposition of the CSF |
| [Background](part1-framework/02-background.md) | OTS history, SforB context, and regulatory landscape |
| [Principles & Requirements](part1-framework/03-principles-and-requirements.md) | Gathered requirements with MoSCoW prioritisation |
| [Architecture Overview](part1-framework/04-architecture-overview.md) | Layered model, message flow, and entity definitions |
| [CP Registry, Master Registry & Directory](part1-framework/05-directory-and-registry.md) | Three-tier distributed registry model and synchronisation |
| [Security Overview](part1-framework/06-security-overview.md) | TLS 1.3, OAuth 2.0, and PKI/DKIM at a conceptual level |
| [Onboarding](part1-framework/07-onboarding.md) | MAP sponsorship and CP registration processes |
| [RCPID Management](part1-framework/08-rcpid-management.md) | UUIDv4 identifiers — allocation, transitions, and rationale |
| [Operational Excellence](part1-framework/09-operational-excellence.md) | Resilience, SLAs, monitoring, and deployment patterns |
| [Governance](part1-framework/10-governance.md) | Standards bodies, MoU, and change control |
| [Glossary](part1-framework/glossary.md) | Abbreviations and definitions |

### Part 2 — Implementation (Technical)

For developers, integration engineers, and technical architects.

| Document | Description |
|---|---|
| [Getting Started](part2-implementation/01-getting-started.md) | Prerequisites and onboarding checklist |
| [OAuth 2.0 Implementation](part2-implementation/02-oauth2-implementation.md) | Token requests, responses, and error handling |
| [PKI & DKIM Signing](part2-implementation/03-pki-dkim-signing.md) | DKIM process, CSF headers, worked examples, and error codes |
| [Message API](part2-implementation/04-message-api.md) | Letterbox API, HTTP codes, message delivery failures, and the `auditData` conventions for test flagging and match-session sequencing |
| [Directory API](part2-implementation/05-directory-api.md) | Registry JSON schema, MAP-level (`map.status`) and per-CP (`processSupport[].status`) status fields, and field reference |
| [TOTSCo Integration](part2-implementation/06-totsco-integration.md) | Hub interoperability and dual-endpoint configuration |
| [CP Transitions](part2-implementation/07-cp-transitions.md) | Six-step migration process, RCPID Status export schema, suggested in-flight order export routine, Step 6 sign-off checklist, and conflict resolution |
| [Commercial Scenarios](part2-implementation/08-commercial-scenarios.md) | MAP failure, CP mergers, and administration handling |
| [Operations](part2-implementation/09-operations.md) | Monitoring, malicious behaviour, regulatory and industry reporting (with the proposed distributed telemetry collection model), and risk register |
| [FAQ — GPLB Steering Group](standalone/sg-faq.md) | GPLB-SG questions and answers |
| [FAQ — TOTSCo Integration](standalone/totsco-faq.md) | TOTSCo integration questions and answers |
| [Appendix: OpenAPI Specification](part2-implementation/appendix-openapi.md) | Full OpenAPI 3.0.3 spec for the Letterbox API |

## Standards & External References

The CSF builds on and references the following industry standards:

- **JSON Asynchronous Messaging Specification (JAM)** — published on the [OTA2 website](https://www.offta.org.uk/)
- **RCPID Standards** — published on the [OTA2 website](https://www.offta.org.uk/)
- **[TOTSCo Hub API Specification v2.0](https://totsco.org.uk/wp-content/uploads/2026/04/TOTSCo-API-specifications-v2-Clean.pdf)** — the industry-standard letterbox and directory API for SforB, used by TOTSCo and supported by CSF for hub interoperability
- **Switching for Business Process Documents** — published on the [FCS website](https://www.fcs.org.uk/gaining-provider-led-business-switching/)
- **GPLB-SG Switching for Business Message Specification v3.0** — bundled with this repo as `framework/GPLB SG Switching for Business Message Specification V3.0.pdf`; the authoritative low-level SforB message spec (canonical source published by the GPLB-SG via FCS)
- **TOTSCo Process & Technical Documents** — published on the [TOTSCo website](https://totsco.org.uk/process-technical-documents/)

## Key RFCs

| RFC | Usage in CSF |
|---|---|
| [RFC 8446](https://datatracker.ietf.org/doc/html/rfc8446) | TLS 1.3 — mandatory transport encryption |
| [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376) | DKIM — message signing and verification |
| [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) | OAuth 2.0 — authorisation framework |
| [RFC 4122](https://datatracker.ietf.org/doc/html/rfc4122) | UUIDv4 — RCPID format |
| [RFC 8463](https://datatracker.ietf.org/doc/html/rfc8463) | Ed25519 for DKIM — alternative signing algorithm |

## Reading the Working Draft

The **working draft** of the CSF is held by the **Telecom Technical Architecture Group (TAG)**. The TAG manages change control, version increments, and the editorial lifecycle of the document set.

**Published versions** are made available for download from the CSF website. Each published version is signed off by the TAG and superseded only by a subsequent published version through the TAG's change-control process.

## Contributing

The CSF is maintained by the Telecom Technical Architecture Group (TAG). The TAG steering group meets weekly to review changes and proposals. All CSF documentation is under TAG change control.

### Contributors

| Name                 | Organisation                    |
| -------------------- | ------------------------------- |
| Dave Stubbs          | Zentive Limited                 |
| David A Wilson       | iconectiv                       |
| Marcel Horst         | CWP                             |
| Mark Delo            | NowYoYo Limited                 |
| Shanmugavel Krishnan | iconectiv                       |
| Simon Phillips       | ICUK Computing Services Limited |
| Stephen Breen        | iconectiv                       |
| Steven Pearce        | NowYoYo Limited                 |
| Susan Mangini        | iconectiv                       |

## Version History

| Version | Date | Description |
|---|---|---|
| 2.0.1 | 2026-04-29 | Content additions: new MAP Onboarding & Testing Process handbook with the TAG Baseline Test Suite; expanded CP Transitions §7.3–§7.4 with detailed step descriptions, suggested in-flight order export routine, full RCPID Status export schema, and Step 6 sign-off checklist; new optional `map.status` enum (`ACTIVE`/`TEST`/`SUSPEND`) in the Directory API; tightened telemetry rules in §10.6 (collection limited to `ACTIVE` participants, `auditData.test=true` exclusion); new auditData conventions in the Letterbox doc cross-linking the test-flag and match-session-sequencing rules; bundled GPLB-SG SforB Message Specification v3.0 PDF as the authoritative low-level reference. |
| 2.0 | 2026-04-24 | Comprehensive rewrite in Markdown. Restructured into separate Part 1 (Framework) and Part 2 (Implementation) documents with deduplication, consistent terminology, and improved technical accuracy. |
| 1.0.5 | 2026-01-07 | Last Word document version (Part 1 — Framework) |
| 1.0.5 | 2025-11-14 | Last Word document version (Part 2 — Implementation) |

## Licence

The Connected Services Framework is an open transport framework, free for any Communications Provider or Managed Access Provider to use for any purpose. There are no licensing fees or transaction charges. Participation is governed by the Memorandum of Understanding (MoU) agreed among participating MAPs and CPs.