#6. Security Overview

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

#6.1 Security Architecture

The CSF implements a multi-layered security architecture combining three established standards. Together, they deliver end-to-end encryption, authenticated access, and verifiable trust for every connection, credential, and message.

This combination delivers a zero-trust, cryptographically assured trust boundary across networks and services.

#6.2 Transport Layer Security (TLS 1.3)

TLS is a cryptographic protocol providing secure communication over computer networks. It ensures that data transmitted between MAPs remains confidential, authentic, and integrity-protected.

#What TLS 1.3 Provides

• Encryption: Protects data from eavesdropping using symmetric encryption after a secure handshake
• Authentication: Verifies server identity using digital certificates from trusted Certificate Authorities
• Integrity: Ensures data has not been tampered with during transit through message authentication codes

#Why TLS 1.3 Specifically

TLS 1.3 (RFC 8446) is mandated by the CSF because it:

• Removes legacy insecure algorithms (RSA key exchange, SHA-1, static DH)
• Reduces handshake latency from two round-trips to one
• Mandates forward secrecy — session keys cannot be recovered even if a server's private key is compromised
• Supports only strong, modern encryption (AES-GCM, ChaCha20-Poly1305)
• Encrypts more of the handshake, hiding metadata from passive observers
• Has growing support for Post-Quantum cryptography (NTRU, ML-KEM, etc.)

CSF Requirement: TLS 1.3 is mandatory for all CSF deployments. Earlier TLS versions MUST NOT be used.

#6.3 OAuth 2.0

OAuth 2.0 is the authorisation framework used by the CSF to control access to API endpoints. It provides token-based security with granular permissions.

#How OAuth 2.0 is Used in the CSF

The CSF uses the Client Credentials flow — the machine-to-machine (M2M) flow — because CSF communication is between MAP servers, not end users.

Each MAP:

1. Registers with other MAPs during onboarding, receiving a client_id and client_secret
2. Requests a time-limited access token from the other MAP's OAuth token endpoint
3. Includes the bearer token in API requests to the other MAP's endpoints
4. The receiving MAP validates the token's signature, issuer, audience, and expiry on every request

#CSF OAuth 2.0 Requirements

• All token exchanges MUST use HTTPS/TLS 1.3
• Token scope and lifetime MUST be limited
• Client secrets MUST NOT be exposed in logs or client-side code
• Token signature, issuer, and audience MUST be validated on every request

OAuth 2.0: mirrors the approach used by TOTSCo for OTS, making it the most compatible option across the industry. MAPs that already have TOTSCo OAuth credentials may be able to reuse them for CSF connectivity.

#6.4 API Key Authentication

API key authentication is a simpler mechanism where a client includes a unique secret key in each request. In the CSF context:

• API keys are recommended for MAP-to-CP communication, where full OAuth 2.0 would be excessive
• API keys MUST NOT be used for MAP-to-MAP communication over the CSF — OAuth 2.0 is mandatory
• All API key exchanges MUST use TLS 1.3
• Keys MUST be stored securely, rotated regularly, and granted minimal access

#6.5 PKI and DKIM Message Signing

Public Key Infrastructure (PKI) provides the cryptographic framework for message signing and verification. The CSF implements PKI through DKIM (DomainKeys Identified Mail, RFC 6376), a standard originally designed for email authentication but ideally suited to federated, distributed messaging.

#Why DKIM?

DKIM is ideal for the CSF because it:

• Provides message integrity — the message body cannot be tampered with undetected
• Provides domain-level authentication — the signature confirms which domain (and therefore which CP) authorised the message
• Uses DNS for public key distribution — no centralised certificate authority is needed
• Gives CPs control — a CP's DNS records determine which MAP is authorised to sign on their behalf
• Is a proven standard used at internet scale for email authentication

#How It Works (Conceptual)

1. When a MAP sends a message, it creates a cryptographic hash of the message body and selected headers
2. The hash is encrypted (signed) with the source CP's private key — held securely by the MAP
3. The signature is placed in the HTTP header X-CSF-SIGNATURE — the message body is not modified
4. The receiving MAP retrieves the source CP's public key from a DNS TXT record
5. The receiving MAP recalculates the hash and verifies it against the decrypted signature
6. If the hashes match, the message is authentic and unaltered; if not, the message is rejected

#DNS Records for Each CP

Each CP maintains two DNS TXT records that establish their identity and MAP association:

• [RCPID]._domainkey.[cp-domain] — Contains the CP's public key for signature verification
• [RCPID]._mapkey.[cp-domain] — Contains the URL of the CP's MAP message endpoint

These records are controlled by the CP, ensuring that:

• Only the MAP indicated in DNS can sign messages on the CP's behalf
• The CP can change MAP by updating these DNS records
• Any receiving MAP can independently verify the message origin without relying on a central authority

CSF Best Practice — DNS independence. A CP SHOULD NOT delegate management of the DNS zone containing _domainkey / _mapkey records to its MAP. The whole point of the DNS-anchored model is that the CP retains unilateral control of who is authorised to sign for it and which MAP routes its traffic. If a CP delegates the DNS zone to its MAP, moving to a different MAP — or becoming a MAP of 1 — requires cooperation from the MAP the CP wishes to leave, which can be slow, contested, or commercially unattractive for the outgoing MAP. CPs SHOULD therefore host their own DNS or use an independent DNS provider with whom they have a direct commercial relationship that is not entangled with their MAP relationship. This keeps the CP's right to change MAP exercisable at any time, by the CP alone.

CSF Best Practice — local DNS server. To ensure the DNS records used to verify CSF messages reflect the live public records as closely as possible, MAPs SHOULD operate a local DNS server that mirrors _domainkey and _mapkey records in near-real-time, observing the public TTLs published by each CP. Core standard: RFC 6303 — Locally Served DNS Zones. This is a common operational pattern (recursive resolver pinned to authoritative servers; or stub bypassing OS resolver cache) and imposes no new infrastructure cost. Detailed rationale and impacts-if-not-implemented are in Part 2: PKI & DKIM Signing §3.3.

For implementers: Detailed DKIM implementation guidance, worked code examples (Java and C#), CSF HTTP headers, signing algorithms, and error codes are provided in Part 2: PKI & DKIM Signing.

#6.6 Security Summary

The CSF protects every interaction with:

• TLS 1.3 — encrypting all data in transit between MAPs
• OAuth 2.0 — controlling who can access which endpoints
• PKI/DKIM — verifying that every message is authentic, unaltered, and authorised by the source CP

No single layer is sufficient on its own. Together, they provide confidentiality (data cannot be read), authentication (identities are verified), authorisation (access is controlled), and integrity (content cannot be tampered with).