Portable Reputation
An agent that worked under Org A and now operates under Org B carries its history with it. The agent owns the signing keypair; every receipt it accumulated names that key as the subject. Org B can read those receipts, weigh them against its own bilateral policy, and decide how much weight to give the imported signal. There is no global score. Each org evaluates the same agent independently.
The Agent Owns the Keys
Reputation in chio is not a transferable token. It is observable evidence about a subject keypair. Three properties follow.
- Identity is the keypair. A
did:chio:<public-key>identifier encodes the public key directly. Any verifier that learns the DID can verify signatures by that key without contacting an identity provider. - Receipts name the subject. Every receipt records the subject public key. The set of receipts mentioning a given key is the agent's observable history.
- Reputation is a projection. A score is something each org computes from the receipts it has admitted, weighted by its own policy. There is no authoritative number stamped onto the agent.
Portable, not transferable
Passports as the Carrier
The Agent Passport is the container that travels with the agent. It bundles the subject's receipt roots, the issuing operator's attestation of reputation signals, and optional enterprise identity provenance. See Passports for the full schema.
A passport projection contains:
| Claim family | Contents |
|---|---|
| Always disclosed | iss, sub, vct, cnf, chio_passport_id, chio_subject_did, chio_credential_count |
| Selectively disclosable | chio_issuer_dids, chio_merkle_roots, chio_enterprise_identity_provenance |
| Optional sidecar | chio_passport_status pointing at the issuer's lifecycle endpoint |
A passport can carry credentials issued by multiple orgs. The bounded CrossIssuerPortfolio profile aggregates issuer DIDs and Merkle roots so a verifier can check each strand independently. This is an evidence container, not a synthesized new trust root.
Per-Org Scoring
Each org scores the agent against its own observed receipts. The receipts an org actually saw at runtime are stored locally; receipts from other orgs come in as imported evidence shares (see Bilateral Receipts). The scoring inputs are kept distinct.
- Native reputation: computed from receipts the local kernel signed. These are first-hand observations: dispatched calls, denials, observed latencies, observed costs.
- Imported reputation: computed from receipts and reputation summaries received in signed evidence shares from a federation peer, weighted by the bilateral policy and never merged into native truth.
Both values surface side by side on comparison tools. An operator deciding whether to grant a capability sees the local signal, sees the imported signal, and sees the provenance of each. The kernel does not collapse them into a single number for runtime enforcement.
$ chio --json reputation compare \
--subject-public-key ed25519:80f2b577472e6662f46ac2e029f4b2d1300f889bc767b3de1f7b63a4c562fd8f \
--passport ./agent-passport.json
# Output (abbreviated):
# {
# "subject": "did:chio:80f2b577...",
# "native": {
# "receipts": 1240,
# "denial_rate_bps": 12,
# "average_latency_ms": 240,
# "since": 1714000000
# },
# "imported": [
# {
# "partner": "org-a",
# "share_id": "imp-2026-04-15-001",
# "receipts": 5800,
# "denial_rate_bps": 9,
# "attenuated_composite_score": 0.87,
# "issued_at": 1713590000,
# "import_policy": "max_evidence_age_secs=3600 sharing_posture=pair_scoped"
# }
# ]
# }Imported Evidence Is Attenuated
Federation imports never become native truth. Imported shares carry full provenance and pass through conservative defaults.
- Provenance fields:
share_id,issuer,partner,signer_public_key,imported_at,exported_at. Persisted infederated_evidence_shares. - Policy echo: the bilateral
FederationImportControlin effect at import time is recorded alongside the share so an auditor can see which guardrails were applied. - Conservative defaults: proofless shares are rejected; shares older than
max_evidence_age_secsexpire; accepted shares contribute anattenuatedCompositeScorerather than a native confidence number. - No ambient runtime admission: imported evidence informs visibility and reputation surfaces; it does not silently widen runtime authority. The default
FederationImportControlsetsprohibit_ambient_runtime_admission = true.
Receipt Merkle Proofs
A passport bundles receipt-log Merkle roots rather than the receipts themselves. The verifier checks an inclusion proof against a root they already trust without replaying every receipt. Two consequences follow.
- Bounded import cost: a passport is small even when the agent has thousands of receipts on file. The verifier pulls only the proofs it needs.
- Tamper evidence: an inclusion proof against a signed root is binary. Either the receipt was logged at the issuer at the time the root was published, or it was not.
The receipt log is exposed via the optional ChioReceiptLogService entry in a DID document. Org B's verifier discovers the URL, pulls inclusion proofs, and validates them against the roots embedded in the passport before any reputation projection runs.
$ chio did resolve \
--did did:chio:80f2b577472e6662f46ac2e029f4b2d1300f889bc767b3de1f7b63a4c562fd8f \
--receipt-log-url https://trust.org-a.example/v1/receipts
# The resolved DID document includes ChioReceiptLogService entries.
# Org B uses these to fetch inclusion proofs against passport roots.Use this page when:
Failure Modes
| Failure | Surface | Behavior |
|---|---|---|
| Stale evidence | Imported share past max_evidence_age_secs | Share is rejected; reputation projection drops the contribution |
| Revoked credential | Passport status sidecar reports revoked | Verifier fails closed; receipts under the revoked credential are excluded |
| Conflicting attestations | Two issuers produce contradictory signals about the same subject | Compare surface shows both with provenance; operator decides |
| Unknown issuer key | Imported receipt signed by a key absent from trusted_issuers | Receipt is dropped from the share at import; share marked partial |
| Proofless share | Share lacks Merkle inclusion proofs for referenced receipts | Rejected when require_proofs = true in the partner record |
| Replay | Same share imported twice | Idempotent: share_id primary key prevents duplicate rows |
Worked Example: Buyer Org Evaluates a Provider Agent
Org B (buyer) is considering granting a capability to a provider agent that previously operated under Org A. The agent presents a passport. Org B already has a bilateral policy with Org A and has pinned Org A's kernel as a federation peer.
1. Verify the Passport
Org B's verifier checks the passport signature against the issuer's public key, confirms chio_subject_did matches the keypair the agent presented at the door, and consults the lifecycle sidecar. Anything other than active fails closed.
2. Pull and Verify Receipt Roots
The passport includes Merkle roots for the agent's receipt log at Org A. Org B fetches inclusion proofs from Org A's ChioReceiptLogService endpoint, declared in Org A's DID document. Each proof is verified against the root in the passport.
3. Check Issuers Against trusted_issuers
Receipts signed by an Org A kernel key absent from Org B's bilateral trusted_issuers set are dropped. The remaining receipts form the imported corpus.
4. Compute Reputation
Org B computes its imported-reputation projection over the accepted corpus, applying the attenuation factor declared in the bilateral policy. Org B also computes its native projection over receipts it signed locally for this subject (initially empty for a brand new agent).
5. Operator Decides
The compare surface presents both projections side by side with provenance. The operator decides whether to issue the capability and, if so, with what scope, budget, and autonomy tier. Native receipts begin to accumulate from the first invocation.
Related
- Passports covers the credential bundle that carries history.
- Reputation details native scoring and projection algorithms.
- Scorecards explains the comparison surface that places native and imported signals side by side.
- Bilateral Federation covers the per-pair trust contract that controls import.
- Bilateral Receipts covers the dual-signed evidence that lands in shares.