Federation Overview

Chio is designed to run across organizational boundaries. Identity, delegation, revocation, and receipts all compose when two kernels sit inside different administrative domains. This page walks through the primitives that make federation work: self-certifying did:chio identifiers, signed Agent Passports carried as W3C Verifiable Credentials, bilateral federation policies, and cross-org revocation feeds.

Why Federation

A single chio deployment already solves local governance: an agent holds a capability, the kernel enforces scope, and every call leaves a signed receipt. Federation is what happens when that agent needs to call tools in a partner organization, or when a partner wants to consume chio evidence without trusting the issuing org as a universal root.

• Portable identity: an agent keypair should be the same name from Org A's perspective and Org B's perspective, without either side operating a shared directory.
• Portable delegation: a capability issued in Org A should be presentable at Org B and evaluated against Org B's local policy without a prior account provisioning step.
• Portable revocation: when Org A revokes a capability, Org B should stop honoring it on the next enforcement decision, with bounded staleness and no silent carry-over.
• Portable reputation: evidence of good behavior in Org A should be visible to Org B as an attenuated signal, not a shared score.

Self-Certifying Identifiers

Every chio identity is an Ed25519 keypair. The did:chio method encodes the public key directly into the identifier, so basic resolution never requires a registry lookup.

did:chio:{64-hex-character-ed25519-public-key}

Example:
did:chio:80f2b577472e6662f46ac2e029f4b2d1300f889bc767b3de1f7b63a4c562fd8f

The method-specific identifier is the public key. Any party that learns the DID can verify signatures by that key without contacting a third service. This is the crucial property for federation: identity verification does not require a shared identity provider.

The resolved DID Document is deterministic:

• @context points at the W3C DID v1 context.
• A single verificationMethod entry named #key-1, shape Ed25519VerificationKey2020, with publicKeyMultibase base58btc encoding.
• authentication and assertionMethod both reference #key-1.
• Optional ChioReceiptLogService entries point at the operator's receipt query endpoint, so a counterparty can pull downstream evidence.

$ chio did resolve \
    --did did:chio:80f2b577... \
    --receipt-log-url https://trust.org-a.example/v1/receipts

Agent Passports as Verifiable Credentials

A chio Agent Passport is a signed bundle of receipts, reputation projections, and enterprise identity provenance. The native delivery format is the compact CHIO passport artifact. For partners who want a standards-legible envelope, chio projects the same passport truth into either application/dc+sd-jwt (SD-JWT VC) or jwt_vc_json (JWT VC JSON).

Claim families inside a passport projection:

• Always disclosed: iss, sub, vct, cnf, chio_passport_id, chio_subject_did, chio_credential_count.
• Selectively disclosable (SD-JWT lane only): chio_issuer_dids, chio_merkle_roots, chio_enterprise_identity_provenance.
• Optional: chio_passport_status sidecar pointing at the issuer's lifecycle endpoint.

Bilateral Federation Policies

Federation in chio is bilateral. Every partner pair records an explicit policy that states which credential authority keys are trusted, which autonomy tiers the counterparty is allowed to present, how stale evidence may be before it is rejected, and whether evidence may be re-shared with a third organization.

apiVersion: chio.dev/v1
kind: FederationPolicy
metadata:
  name: org-a-to-org-b
spec:
  partner_id: org-b
  trusted_issuers:
    # Org B's current authority plus previous generation for rotation overlap.
    - ed25519:9a4f1c3b2e7d8a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b
    - ed25519:7f3b9c1e4d6a8b0c2d4e6f8a0b2c4d6e8f0a2b4c6d8e0f2a4b6c8d0e2f4a6b8c
  max_scope:
    tool_servers:
      - billing.org-b.internal
      - reports.org-b.internal
    tools:
      - tool: reports.read
        parameter_bounds:
          row_limit: 10000
  max_autonomy_tier: TIER_2_DELEGATED
  max_evidence_age_secs: 3600
  revocation_feed: https://trust.org-b.example/v1/revocations/feed
  sharing_posture: pair_scoped

Cross-Org Delegation

Delegation works across a federation boundary when the inbound capability chain satisfies the bilateral policy. The protocol is straightforward because capability chains are already content-signed and monotonically attenuated.

1. An agent in Org A already holds a capability issued by Org A's authority. The capability carries an ed25519 signature from an issuer key that Org B has listed in trusted_issuers.
2. The agent signs a delegated child capability for a downstream worker whose subject key lives in Org B. The child strictly attenuates scope, expiry, and budget relative to the parent.
3. The Org B kernel receives a tool call carrying the delegated chain. It verifies the parent signature against its local copy of Org A's trusted public-key history, verifies the child signature against the parent subject, and then applies the bilateral policy.
4. The Org B kernel's guard pipeline clamps the effective grant to max_scope and max_autonomy_tier, emits a receipt, and either dispatches or denies.

Federated Revocation

Revocation is the most time-sensitive federation surface. When Org A revokes a capability, Org B must stop honoring it on the next enforcement decision. Chio handles this via signed transparency feeds.

• Each trust control plane publishes a revocation feed as a signed, append-only log. Entries name a capability ID, a revocation timestamp, and a signer key.
• The counterparty's trust control plane subscribes to that feed and merges new entries into its local revocation store. Merges are idempotent; replay is safe.
• Every tool call at every edge kernel re-checks revocation status against the local store, so once the feed has landed, enforcement is instant on the next invocation.
• Subscription uses a small polling interval. The bilateral policy states the ceiling on acceptable staleness; calls observed after that ceiling with an unreachable feed fail closed.

# Bootstrap a revocation subscription on Org B's trust control plane.
$ chio trust federation-policy create \
    --config ./federation-policy.yaml \
    --control-url https://ctl.org-b.example:8940 \
    --control-token-file ./secrets/chio_admin.txt

# Evaluate an inbound chain against the stored policy.
$ chio trust federation-policy evaluate \
    --partner-id org-a \
    --capability-file ./inbound-capability.json \
    --control-url https://ctl.org-b.example:8940

Imported Reputation Is Attenuated

Chio treats imported reputation as an operator-visible signal rather than a merged score. When Org B imports an evidence package from Org A, the local compare surface reports native reputation and imported trust side by side, with explicit provenance.

• Provenance fields: every imported share carries shareId, issuer, partner, signer key, and import/export timestamps.
• Policy echo: the imported-trust policy that was in effect at import time is recorded alongside the share, so an auditor can tell which guardrails were applied.
• Conservative defaults: proofless shares are rejected, stale signals expire, accepted shares become an attenuatedCompositeScore rather than a native confidence number.

# Import a signed cross-org evidence package.
$ chio evidence import --input ./upstream-package

# Compare local and imported reputation for a specific agent key.
$ chio --json reputation compare \
    --subject-public-key ed25519:80f2b577... \
    --passport ./agent-passport.json

Agent Passport as Portable Reputation

The Agent Passport is the container that makes reputation portable. It bundles the subject's receipt roots, the operator's attestation of reputation signals, and optional enterprise identity provenance from the issuing organization. The counterparty verifies the passport signature, verifies each referenced Merkle root against the local copy of the issuer's receipt log, and then applies the bilateral policy to decide whether to treat the passport as input to an authorization decision.

• A presented passport is not a bearer token. It does not itself authorize a tool call; it feeds the policy evaluation that decides whether a capability issued under the passport's subject key is honored.
• Multi-issuer composition is supported through the bounded CrossIssuerPortfolio profile. A portfolio is an evidence container, not a synthetic new trust root.
• Lifecycle state is pulled from the issuer's signed status sidecar. Only active is considered healthy; stale, superseded, and revoked fail closed at the verifier.

Trust Control Plane Federation

The federation surface lives on the trust control plane. Both operators run their own chio trust service; the federation policy is a per-partner record inside each local control plane.

Topology

A minimal bilateral federation has two trust control planes and a shared public-key registry that each side pins locally. The registry is not a central authority; it is a mirror each operator maintains of the other's trusted keys, fed by signed snapshots.

Non-Goals

• A permissionless global identity network. Every relationship is bilateral and operator-declared.
• A universal reputation score. Imported reputation is attenuated, provenance-tagged, and never merged into native local truth.
• Automatic widening of authority on the strength of a discovered public identity document. Discovery supports interoperability, not admission.
• DIDComm or generic wallet messaging. The supported transport is the documented chio projected-passport family plus the narrow OID4VP verifier profile.

For the specific compliance frameworks that benefit from this federation posture, continue with NIST AI RMF, EU AI Act, and ISO/IEC 42001.