Federation
Two organizations. Neither surrenders its authority.
Two sovereign organizations can communicate without collapsing into one shared directory or one shared root of authority. Each keeps its own root, its own Command and its own view of its own people. A directional boundary decides what may cross.
- Independent roots
- Two-sided authority
- Directional
- Graph non-leakage
- Available under controlled evaluation
The thesis
Authority is the thing being governed, not the ciphertext.
Federation makes the platform's central distinction visible between two organizations, where it is easiest to see: the boundary governs who may communicate, and the payload stays sealed to the endpoints throughout.
Encryption protects the communication; Tunnel Sovereign governs the authority to communicate.
The Sovereign Guard
The boundary is enforced by a Guard the receiver operates.
Crossing is governed by a Guard the receiving organization runs. It decides direction, capability and how a foreign mission maps to a local one, and it fails closed: if a crossing is not explicitly permitted, it does not happen.
The Guard governs whether traffic may cross, not what the traffic says. It holds no message or media keys.
The separation is the same one that holds inside a single deployment: the component that decides whether communication is permitted does not possess the keys required to read it. A Guard that fails is a boundary that closes, not one that opens.
No shared graph
Only mission-scoped aliases cross the boundary.
Federation does not merge two directories into one. An organization's internal list of people and devices never appears on the other side.
What crosses is a mission-scoped alias, meaningful only within the mission it belongs to. The counterpart organization learns what it is authorized to reach, in the direction it is authorized to reach it, and nothing about the shape of the organization behind it.
What holds at the boundary
The properties an evaluator can check.
Federation is described here as an architecture, with the same discipline applied to a single deployment: each property is stated with the limit that qualifies it.
- Independent roots
- Each organization keeps its own root of authority. The two are peers, each rooted in itself, rather than branches of one certificate authority.
- Trust anchors
- Recognition of a foreign organization is a root-signed statement that names which organization is recognized. It can be withdrawn.
- Two-sided
- Crossing requires sender-side authorization and receiver-side acceptance. Both are required, and a crossing proceeds only when both are present.
- Directional
- Authority points one way. A to B is not B to A, and each direction is granted on its own.
- Guard holds no keys
- The Guard governs whether traffic may cross. It receives the decision alone, and the keys required to read a payload stay on the endpoints, and it fails closed.
- Graph non-leakage
- Only mission-scoped aliases cross. A domain's own list of people and devices stays inside it.
Federation is described here as an architecture. It is not a certified cross-domain solution, and no external accreditation of a crossing between two security domains is represented.
The control-plane mechanisms described above are implemented and verified by automated testing across two live domains: independent organizational roots, separately governed authority, directional boundary authorization, the receiver-side guard, and fail-closed refusal. Verification of the endpoint application path for federated traffic, on physical handsets, remains outstanding.
Product configurations, integrations and operational capabilities are delivered according to customer requirements, deployment environment, validation scope and applicable authorization. No approval for classified information is represented.