--- title: 3. Principles and Requirements tags: [Part 1] --- # 3. Principles and Requirements > Connected Services Framework (CSF) — Part 1: Framework — Version 2.0 ## 3.1 How Requirements Were Gathered The requirements documented in this chapter were explicitly gathered from Managed Access Providers (MAPs), Systems Integrators (SIs), and their associated CPs. The purpose was to define how MAPs communicate with each other efficiently, reliably, and securely to facilitate messaging solutions on behalf of their CPs for any industry process. The intention is that modifications stipulated within the CSF will not impact solutions already developed by CPs in support of OTS. However, MAPs may need to implement changes to fully support distributed messaging for processes such as SforB. ## 3.2 Requirements Requirements are prioritised using the MoSCoW method: - **Must** — Non-negotiable; the CSF cannot function without this - **Should** — Important but not blocking; deviation requires justification - **Could** — Desirable if achievable without significant cost or complexity - **Won't** — Out of scope for the current version ### Connectivity and Routing | Ref | Requirement | Priority | |------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| | R.01 | MAPs MUST be free to acquire and manage their own customers without a technical or commercial dependency on, or imposed by, another MAP. No centralised administration is required. | Must | | R.02 | MAPs MUST make their customers available for message exchange with any other requesting MAP without applying a commercial or technical barrier. | Must | | R.03 | Unless required by regulation or an agreed industry process, no single party SHALL be a dependency for routing messages to any other MAP and their CPs. | Must | | R.04 | All OTS messaging MUST continue to be routed via TOTSCo to meet Ofcom compliance requirements. | Must | | R.05 | Direct routing MUST NOT be mandated between MAPs. A MAP can choose who they route through unless required by regulation or an agreed industry process. | Must | | R.06 | MAPs MUST ensure they have peering capabilities to reach all CPs in the directory. | Must | | R.07 | Any MAP MAY choose to provide routing services to another MAP (e.g. TOTSCo), but MUST NOT route to another routing MAP as circular routes MUST be avoided. | Must | | R.08 | MAPs MUST meet the requirements of the industry processes in delivering messages and meeting CP SLAs. | Must | | R.09 | SLAs MUST be defined for all MAP-to-MAP transactions. | Must | | R.10 | MAPs MUST maintain a secure networking environment between all MAPs and their CPs. | Must | | R.11 | MAPs MUST ensure they only accept messages from authenticated CPs and MAPs. | Must | | R.12 | Every MAP MUST provide the same guaranteed delivery capability to its CPs, including retry mechanisms and failure reporting. | Must | | R.13 | A mechanism is REQUIRED to allow auto-discovery of CPs by onboarded MAPs. | Must | | R.14 | The solution MUST support message sending and receiving in compliance with supported industry processes (e.g., OTS, SforB). | Must | | R.15 | The solution MUST be as simple as possible to implement. | Must | ### Directory Management | Ref | Requirement | Priority | |------|------------------------------------------------------------------------------------------------------------------------|----------| | R.17 | A centralised directory SHOULD NOT be a dependency or requirement. | Should | | R.18 | Every MAP MUST provide its customers with access to a complete directory list in support of their messaging processes. | Must | | R.19 | Every MAP is responsible for maintaining and publishing the CP Registry entries of its own CPs. | Must | | R.20 | All MAPs MUST be able to issue their own unique RCPIDs. | Must | | R.21 | A new MAP MUST have a sponsor and be onboarded before being added to the network. | Must | | R.22 | Any shared directory model MUST be openly extensible. | Must | ### Messaging | Ref | Requirement | Priority | |-------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| | R.23 | Messages SHOULD be capable of being encrypted end-to-end. | Could | | R.23a | All messages exchanged between MAPs MUST be digitally signed using DKIM (RFC 6376) so that the receiving MAP can verify the message has not been tampered with in transit and that it originated from the claimed source CP. | Must | ### Operations | Ref | Requirement | Priority | |------|--------------------------------------------------------------------------------------------------------------------------------|----------| | R.24 | No MAP MAY charge for connectivity and routing of messages from or to another MAP, or levy charges to another MAP's customers. | Must | | R.25 | Every MAP MUST ensure they have connectivity to exchange and route messages. | Must | ### Other | Ref | Requirement | Priority | |------|--------------------------------------------------------------------------------------------|----------| | R.26 | Linking RCPIDs (e.g., association of OTS and SforB RCPID if a CP uses one for each process). | Could | ### CP Right to Move | Ref | Requirement | Priority | |------|--------------------------------------------------------------------------------------------------------------------------------------------|----------| | R.27 | Every CP MUST have the right to change to another MAP. | Must | | R.28 | No MAP SHALL actively prevent a CP from moving to a new MAP. | Must | | R.29 | No MAP SHALL deliberately prevent access to switching for a CP while still under contract when the CP is switching to another MAP. | Must | | R.30 | A CP MUST be able to choose their service status within the MAP's directory, regardless of account status (e.g., ACTIVE, TEST, SUSPENDED). | Must | ## 3.3 Summary of Principles Taken together, these requirements establish that the CSF must: 1. **Ensure MAP independence** — No commercial or technical dependency on any other MAP 2. **Guarantee interoperability** — Secure routing of messages between all MAPs 3. **Remove barriers** — MAPs provide connectivity without imposing technical or commercial barriers 4. **Maintain security** — Authenticated message exchanges using OAuth 2.0, PKI, and DNS-based validation 5. **Enable auto-discovery** — Decentralised discovery of MAPs and CPs through shared directory structures 6. **Guarantee delivery** — Consistent message delivery with retry mechanisms and failure reporting 7. **Empower CPs** — Freedom and autonomy to switch MAPs without disruption or obstruction 8. **Enforce SLAs** — MAP-to-MAP service-level agreements for consistency and reliability 9. **Comply with regulation** — All MAP activities must comply with relevant industry regulations 10. **Reward good behaviour** — The framework encourages good actors and discourages bad actors without requiring centralised enforcement These principles support operational excellence, regulatory compliance, and industry-wide interoperability, fostering an environment conducive to innovation and dynamic market competition.