Federation and bilateral trust

Summary. In TrustBridge, organizations do not trust each other as members of a shared federation, but in pairs. Every trust relationship is agreed between exactly two organizations, and each side decides for its own direction which of the other side's services it trusts, for what purpose, under which cryptographic requirements, and for how long. Trust is not passed on: if A trusts partner B and B trusts partner C, A does not trust C because of that. Either side can revoke its direction at any time on its own. The identities, keys, and rules of both organizations remain separate.

• Organization – a party with its own hierarchy of certificate authorities, its own approvers, and its own ledger.
• Trust relationship – an agreement between exactly two organizations to recognize the other side's trust anchors for specific services and purposes.
• Direction – one side of a trust relationship: the direction from A to B defines how A trusts B's systems.
• Relationship policy – an organization's settings for its direction.
• Relationship anchor – the other side's certificate that an organization adds to the relationship; only chains up to this anchor count.
• Relationship revocation – one side ending its direction unilaterally, with immediate effect on new connections and a defined effect on existing ones.

graph TD
  A[Organization A<br/>customer]
  B[Organization B<br/>maintenance provider]
  C[Organization C<br/>technical service provider]
  N[no relationship:<br/>A does not trust C]
  A ---|relationship A and B| B
  B ---|relationship B and C| C
  A -.- N
  N -.- C
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  class A,B,C par
  class N onl

In many federations, joining means trusting every other member, often through a shared root or through cross-certificates whose effect carries on along chains. TrustBridge avoids both:

Each organization sets for its own direction:

The two directions of a relationship are independent of each other. A can admit B for one service while B accepts nothing from A at all; or both sides require different cryptographic properties. A connection only comes about if it satisfies both policies, the caller's and the callee's.

stateDiagram
  [*] --> Requested
  Requested --> Agreed: both sides add the anchor and approve their policy
  Agreed --> Active: start of validity reached
  Active --> Active: policy changed, with approval
  Active --> Revoked: one side revokes its direction
  Active --> Expired: duration reached
  Revoked --> [*]
  Expired --> [*]

1. Request. One organization invites the other. The invitation carries the inviting side's trust anchor and a fingerprint, which is confirmed over a separate channel, such as by phone or in the contract.
2. Agreement. Both sides check the other side's anchor against the fingerprint, add it, and approve their policy. The approval is a signature by an authorized person, just like a manual certificate issuance.
3. Operation. Each side's CA worker includes the approved relationship in a signed trust bundle. TLS adapters and key agents use only this bundle, for every connection setup and every key exchange. That is why whoever controls the database cannot slip in a foreign anchor.
4. Change. A change to a direction needs approval according to that direction's right to change and is recorded in that organization's ledger.
5. End. Through expiry or revocation. The other side does not need to agree.

Revoking a relationship is not revoking a certificate. The other side's certificates remain valid, and its connections to other organizations are unaffected. Certificate revocation concerns a single certificate; relationship revocation concerns a relationship.

A relationship recognizes an anchor; it does not issue a certificate. That is why there are no cross-certificates, no shared root, and no chain that leads past one organization into a third. A partner without a PKI of its own receives a partner CA in the customer's hierarchy instead; even then the relationship is bilateral, and the partner can later move to an installation of its own. Both paths are described in Trust model.

A relationship does not depend on who operates an installation. A supplier whose installation is run by an operating partner and an enterprise with its own installation agree on the same relationship in the same way. A partner with an existing enterprise PKI takes part by bringing its PKI's trust anchor into the relationship and equipping its systems with the TrustBridge TLS adapter and key agent. Operating models describes the models.

• Authorization. A relationship admits services and purposes; which operation is allowed is defined by the target application.
• Contract terms. Liability, obligations, and deadlines between the organizations are governed by their contract; the policy implements the technical settings derived from it.
• Passing identities on to third parties, or federation of user accounts. TrustBridge connects systems and services; it is not a sign-in service for people.