#4. Architecture Overview

Connected Services Framework (CSF) — Part 1: Framework — Version 2.0

#4.1 Layered Architecture

The CSF operates as a layered messaging stack. Each layer has a distinct responsibility, and together they provide a complete, secure message delivery pipeline.

The process layer and JAM routing layer are industry-wide standards that exist independently of the CSF. The CSF's contribution is the security layer and the operational framework that binds everything together.

#4.2 Entity Definitions

#4.2.1 Communications Provider (CP)

A CP is any party participating in an industry process — creating or consuming messages and sending or receiving them from other CPs. CPs include retailers, wholesalers, and agencies providing services on behalf of other CPs.

The CP involved will vary based on the industry process. A CP does not need to understand how the CSF works — it creates messages according to the industry process specification and hands them to its MAP for delivery.

#4.2.2 Managed Access Provider (MAP)

A MAP facilitates message exchange on behalf of one or more CPs. MAPs provide integration services, portals, technical solutions, and the operational infrastructure to send and receive messages over the CSF.

Within the CSF, a MAP is the only entity authorised to exchange messages with other MAPs, because MAPs are responsible for:

• Publishing and maintaining their CP registry
• Applying PKI signing to outbound messages
• Verifying PKI signatures on inbound messages
• Establishing and maintaining OAuth 2.0 credentials with other MAPs
• Guaranteeing message delivery with retry mechanisms

A MAP may serve multiple roles concurrently for its clients (insourced, technical, fully managed), and the CSF imposes no restrictions on this. There are no charges or licensing requirements mandating specific MAP definitions.

#4.2.3 MAP of 1

Any CP can become a "MAP of 1" — operating as its own MAP. This allows CPs to exchange messages directly with the industry for free, maintaining full control of all messages sent and received from their own infrastructure. The CP must abide by all MAP rules when implementing.

#4.2.4 Hub Managed Access Provider (HMAP)

An HMAP is a specialised MAP designed to facilitate integration for proxy hubs such as TOTSCo. An HMAP:

• Accepts messages and forwards them among its subscribed members using a hub-and-spoke model
• Does not engage with the message payload — it routes based on addressing information
• When interfacing with the CSF, uses its Master Registry (built from collected CP Registries) to locate the destination CP and dispatches the message to the appropriate MAP
• Is not required to implement PKI/DKIM signing when exchanging messages on behalf of its CPs (to minimise integration cost)
• Is strongly recommended to implement the full CSF CP Registry format for SforB, as its CP clients benefit significantly from the additional information it provides

Best Practice: MAPs on the CSF should provide a dedicated endpoint exclusively for HMAPs, separate from the endpoint used by other CSF MAPs. This allows rapid CSF iteration without disrupting established hub exchange networks.

#4.3 Message Flow

The following diagram illustrates the end-to-end message flow through the CSF:

#Step-by-Step Workflow

1. CP creates message: The CP creates a message according to the industry process specification (e.g., SforB) and wraps it in a JAM envelope with RCPID addressing, using directory information provided by its MAP.

2. CP sends to MAP: The CP sends the message to its MAP using whatever integration method the MAP provides (API, portal, BSS integration). MAP-to-CP integration is outside the scope of the CSF.

3. MAP validates: The MAP validates the message structure, format, and addressing. Unlike a hub model, MAPs can read the full CP payload and validate compliance before signing.

4. MAP discovers route: Using its Master Registry, the MAP identifies which MAP serves the destination CP.

5. MAP signs message: The MAP signs the message with the source CP's private key using DKIM (RFC 6376). The signature is placed in HTTP headers — the message body is not altered.

6. MAP authenticates: The sending MAP authenticates with the receiving MAP via OAuth 2.0.

7. MAP delivers: The signed message is sent over TLS 1.3 to the receiving MAP's letterbox endpoint.

8. Receiving MAP verifies: The receiving MAP validates the OAuth token, checks the JSON envelope, retrieves the source CP's public key from DNS, and verifies the DKIM signature to confirm the message is authentic and unaltered.

9. Receiving MAP acknowledges: On successful validation, the receiving MAP returns HTTP 202 (Accepted) — indicating the message has been accepted for processing but processing has not yet completed.

10. Receiving MAP delivers: The receiving MAP delivers the message to the destination CP.

Note: If both CPs use the same MAP, the CSF is typically not needed as there is no inter-MAP exchange. However, MAPs operating multiple instances or solutions may elect to use the CSF for their own internal interconnections.

#4.4 CSF Networks

Message exchanges are conducted solely between MAPs. The CSF may be employed across diverse industry processes, and the network adapts its size to the specific process in use.

Each MAP must:

1. Undergo sponsored onboarding with an existing MAP that supports the relevant industry process
2. Establish secure connectivity with all other MAPs (OAuth 2.0 credentials, endpoint registration)
3. Publish its CP Registry detailing its CPs and supported processes
4. Retrieve all other MAPs' CP Registries to build its Master Registry

Feature-based services are advertised in the CP Registry, allowing certain MAPs to utilise additional functionalities for bilateral and advanced communication. This design ensures MAPs transmit only messages that the receiving MAP can process.

#4.5 API Versioning and Feature Releases

The CSF supports incremental evolution through two mechanisms:

#API Versioning

MAPs can support multiple API versions simultaneously, allowing new features to be adopted without disrupting existing integrations. When both parties support the latest version, they automatically use advanced features. Where compatibility varies, messages default to the highest compatible version.

#Feature Discovery

A MAP queries the directory to identify the supported feature set of another MAP. This enables:

• Backward compatibility: All MAPs maintain compatibility with earlier API versions
• Flexible adoption: MAPs can adopt new features at their own pace
• Rapid iteration: The TAG can release new capabilities without requiring industry-wide synchronisation

By implementing versioning and feature discovery, the CSF enables rapid feature adoption while reducing the constraints of traditional messaging protocols.

#4.6 What the CSF Does Not Prescribe

The CSF is deliberately silent on:

• MAP-to-CP integration: How a MAP connects to its CPs is a commercial decision (API, portal, BSS plugin, etc.). Typically, MAPs will attempt to offload or shield CPs from as much of the heavy lifting for a process like SforB as possible, and this is often used to differentiate between MAPs, but this is a technical-commercial decision outside the scope of this framework.
• Internal MAP architecture: MAPs are free to use any technology stack
• CP message creation: CPs create messages according to industry process specifications, not CSF specifications
• Commercial arrangements: MAPs and CPs establish their own commercial relationships independently of the CSF