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

Already published / companion	Role
Verify before execute	Proof bar in practice
Passport vs static secrets	When to mint
Agentic identity qualities kit	Quality checklist this table underpins (content/identity-qualities)

---

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)

Role	What they assert	What they can abuse
Issuer	“This Passport exists under our contract; claims follow our quality policy.”	Mint look-alikes; ignore published policy; dilute reputation
Service Provider	“We accept these Issuers / families; this peer may use our API.”	Pretend Issuer trust; mint fake user credentials; skip their own policy
Holder	“I control this tokenId and its current keys.”	Steal or lose keys; present a copycat Passport; forge claims in DN

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:

Control	Where it lives	What it catches
On-chain uniqueness	NEAR RODiT NFT / 12-letter tokenId	Duplicate IDs; fake credentials that cannot match chain state
Trusted contract + family	NEAR_CONTRACT_ID, family match on login/verify	Foreign / copycat issuer ecosystems
Proof bar	HOLA verify or direct NEAR RPC	Missing, expired, revoked, bad signature, replayed nonce
Recipient binding	HOLA recipient	Proofs addressed to someone else
Delegation check	isauthorizedsigner	Subagents not authorized by claimed parent
Canonical tokenId attestation	Holder-published on website / verified social	Look-alike DN with a different Passport
ContactURI monitoring	Principal-controlled email / channel in DN	Impersonation attempts aimed at your brand
Identity mortality + dispose	not_before / not_after, owner dispose	Stale or abandoned credentials
Key rotation / transfer	Holder custody ops	Compromise recovery without re-enrolling every peer
Sybil stake	Mint economics	Mass farming of fake Passports
Optional API Passport check	RoditClient.login_server()	Look-alike IdentyClaw API (MITM hardening)
Login mode (partner / peer)	API session bootstrap	Who may obtain a JWT from this host

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

Threat	Trust declaration / policy intent	How Passport architecture counters it
Issuer (or anyone) mints copycat Service Provider RODiT	Claim Quality Policy must define how address control, ownership, and uniqueness are verified; policies published in a standard way	Passports mint under a trusted smart contract. Verifiers pin NEAR_CONTRACT_ID / RODiT family. A copycat on another contract fails family / token_missing checks. MITM needs faking DNS of issuer and service and chain reads — harder than forging a lone CA-signed cert.
Issuer mints copycat User / Agent RODiT	Same Claim Quality Policy for address control and uniqueness	On-chain uniqueness of tokenId. DN can look alike; the facial ID cannot collide. Holders publish canonical tokenId; verifiers compare before trusting a brand claim.
Issuer not complying with its own published policies	Periodic public audit of policy adherence; standardized audit publication	IdentyClaw does not replace external audit. Architecture helps: chain state is inspectable; holders can monitor whether an Issuer issued a RODiT binding their ContactURI / addresses. Reputation is earned by accumulation of trust declarations — opaque WebTrust-style stamps alone are not the model.

Service Provider–side threats

Threat	Trust declaration / policy intent	How Passport architecture counters it
Copycat Service Providers	Issuer Claim Quality Policy for address / ownership / uniqueness	Peers resolve identity by tokenId, not URL + shared secret. Optional: validate the API server’s on-chain Passport before trusting a JWT. Publish canonical service tokenId (e.g. concierge lobby lhsrldbjsnlh).
SP pretends to be trusted by an Issuer when it is not	Issuer trust declarations must be present and dated	Family matching and LOGIN_MODE (partner / peer / promiscuous) encode who may log in. HOLA verify loads the signer from the verifier’s configured contract — foreign lineage fails. There is no silent “we’re trusted by that CA” without on-chain / config evidence.
SP issues copycat User RODiT	Issuer Claim Quality Policy	Only the Issuer contract mints Passports. An SP that “issues” look-alike credentials outside that contract is not a Passport in your family. Possession-based API keys are a different failure mode — Passport removes them for adopters.
SP not complying with its own published policies	Issuer / SP Claim Quality Policy	Architectural floor: verify-before-execute still proves who. Policy compliance (tool allowlists, rate limits, KYC reuse fees) remains operator / SP duty — Passport is not a behavioral auditor.

Holder-side and claim threats

Threat	Trust declaration / policy intent	How Passport architecture counters it
Copycat users / agents	Claim Quality Policy: address control, ownership, uniqueness	Same as copycat User RODiT: unique tokenId + publish canonical ID + ContactURI the principal monitors. Valid HOLA for a different Passport ≠ you.
Stated claims are false	Claim Quality Policy for non-electronic claims (identity, nationality, …) and electronic addresses (DNS, encrypted email, phone, crypto challenges)	DN / ContactURI are self-declared. Cryptography proves continuity of the Passport, not truth of every claim. High-assurance tenants optionally check controlling address (NEAR owner_id) against an out-of-band allowlist. Issuers choose soft vs hard claim negotiation; SPs decide what claims they require.
RODiT compromise or loss	SP can stop recognizing a credential; revoke via published mechanism; controlling address enables cancel / replace	Holder disposes or lets lifecycle expire; peers stop treating inactive Passports as live. Controlling ContactURI (email/phone with ongoing cost) supports recovery narratives: cancel and request replacement from Issuer. Key rotation / transfer keeps the entity without re-minting peers’ allowlists. Stolen session JWT is TTL-bounded; standing authority is the holder key + live Passport.
Low reputation	Reputation rises with diverse trust declarations, exclusive long-lived address control	Passport supplies continuity substrate, not a global score. More successful HOLA history, older exclusive control, and cross-org trust relationships improve local reputation — applications weight them. Sybil stake raises the cost of farming throwaway IDs.

Cross-cutting: MITM, replay, monitoring

Threat	Trust declaration / policy intent	How Passport architecture counters it
MITM / fake API / fake peer	Multi-leg deception must fake Issuer, SP, and chain	Pin known API hostname; compare claimed tokenId to published canonical ID; optional login_server() validates server Passport. Recipient-bound HOLA + fresh nonce defeat replay and mis-delivery.
Fake credential with duplicated ULID / content	Monitoring: TXT / serial schemes; chain time must match	Chain state is source of truth: same content without matching block is infeasible; same addresses require taking over control; doppelgängers are detectable when the legitimate holder publishes ULID/tokenId and reacts.
Later RODiT tries to supersede a legitimate one	Controlling address notified; Issuer reputation at stake	ContactURI monitoring + canonical attestation. A supersedes-style recovery path can mint a legitimate replacement that points at the fake — social/ops process on top of unique IDs.
Policies / trust factors untested	Publish periodic or unannounced tests; publish incidents	Architecture enables independent verify (API or your NEAR RPC). Incident disclosure and claim-quality audits remain governance — not encoded as a score on-chain.

---

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)

Failure mode elsewhere	Passport / RODiT angle
Federated login oligopoly (Google/Apple/…) knows when and where you authenticate	Rich credential portability without logging into a Big Tech broker for every peer
CA liability ≈ cost of the cert; no warranty for bogus claims	Issuer can stake reputation, and (in the broader RODiT model) offer warranty / liability as a service — Passport today emphasizes inspectable chain + family trust, not insurance productization
Inter-CA recognition barely works; explicit federation agreements everywhere	Trust relationships at org or piecemeal level; third-party Issuers can be honored when family / policy allows — high reuse of the same Passport
Client certs too hard → almost nobody uses them for agents	HOLA is channel-agnostic mutual auth (as easy server→client as client→server) without installing client PKI
Thin credentials: no return, sale, or disposal	Holder ownership: transfer, dispose, renew by returning/replacing; expiration optional/configurable vs CA-hardcoded renewal incidents
Certificate Transparency needed because certs are offline	Continuous control + chain liveness checks reduce the “silent fake cert” class; monitoring still matters for ContactURI and published IDs

---

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

Step	Link
Verify a HOLA	https://verify.identyclaw.com · npx @rodit/verify-hola report "HOLA/..."
Normative checklist	identity-verification-policy
Impersonation guard	finding-agents §5
Decide mint vs skip	Passport vs static secrets
Deep vision	why-identyclaw.md
Enroll	MCP guide:enrollment · https://purchase.identyclaw.com

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.