Passport threat model: Triangle of Trust threats and how the architecture counters them

Shared secrets fail when someone else holds the secret. Certificates fail when the wrong CA signs the wrong name. Agent fleets fail when a look-alike DN walks in with a cryptographically valid proof.

IdentyClaw Passport is a RODiT (Rich Online Digital Token): an on-chain, holder-owned credential with peer-verifiable HOLA proofs. This article is the threat table behind that stack — drawn from the RODiT Triangle of Trust — and mapped to what the architecture actually counters.

Canonical vision: why-identyclaw.md. Normative checklist: identity-verification-policy. Impersonation playbook: finding-agents §5.

Series context

Triangle of Trust (who can lie about what)

Three roles. Trust is not a single root store — it is a triangle of declarations and checks:

                    Issuer
                 (mints RODiT /
                  publishes policy)
                   /        \
                  /          \
                 /            \
    Service Provider -------- Holder (User / Agent)
     (recognizes RODiT,         (presents Passport +
      offers access)             HOLA / login proof)

RODiT is a service-dependent identity model (not “self-sovereign forever without anyone”). Reputation accumulates from continuous control of addresses and keys, and from trust declarations others make about you — not from a browser root store oligopoly.

What we usually want to know: not who someone is in a KYC sense, but whether it is the same entity we talked to last time — continuous, exclusive control of a credential and its controlling addresses.

Architecture controls (the counter toolkit)

Before the threat table, the levers Passport actually gives you:

Local checksum or bare Ed25519 without chain state does not satisfy the verification policy.

Threat → architecture counter

Each row: the Triangle of Trust threat, the intended trust declaration / policy response from the RODiT model, and how IdentyClaw Passport implements the counter.

Issuer-side threats

Service Provider–side threats

Holder-side and claim threats

Cross-cutting: MITM, replay, monitoring

What a valid Passport proves (and what it does not)

From the verification policy, a Passport is genuine when:

1. tokenId exists on the configured RODiT contract
2. Ed25519 signature verifies against the current on-chain owner key (or authorized subagent + parent delegation)
3. Lifecycle is active (not_before / not_after)
4. Issuing contract is trusted by the verifier

It does not prove:

• That DN / brand strings match a particular human or company (use canonical tokenId attestation)
• That intent is benign after a valid HOLA (sandbox, rate limits, task scoping — why §12.6)
• Offline key verification without chain or cached trust state (unlike classic X.509 offline verify)

Practical rule: Passport verification is the floor for multi-agent trust, not the ceiling.

Why this beats the usual alternatives (threat lens)

Operator checklist (threat-aware)

• [ ] Pin NEAR_CONTRACT_ID / family; reject foreign Issuers unless policy says otherwise
• [ ] Always run the full proof bar (exists, active, signature, nonce) — not bare Ed25519
• [ ] Publish your canonical 12-letter tokenId on channels you control
• [ ] Put a ContactURI you monitor in DN; treat look-alike DNs with different IDs as hostile
• [ ] For high assurance: allowlist controlling NEAR owner_id
• [ ] On compromise: rotate/transfer keys, dispose or replace Passport, notify peers who pinned your ID
• [ ] After verify: still sandbox — valid identity ≠ safe task.payload

Where to go next

The Triangle of Trust names the actors who can lie. Passport architecture makes the expensive lies the ones that require taking over chain state, controlling addresses, and out-of-band brand channels — then leaves intent and tool abuse to your local policy, where they belong.