Agentic identity qualities: what good agent identity needs — and how Passport delivers

Shared API keys prove a secret. Certificates prove a CA tree. Neither answers the question multi-agent systems keep asking:

Is this a persistent, unique, currently valid entity I can verify myself — on whatever channel we already use — without re-registering every platform?

IdentyClaw Passport is holder-owned agent identity on NEAR, with HOLA as the peer-verifiable proof format. This article maps the qualities of agentic identity to what Passport actually provides — and where the boundary is.

Canonical vision: why-identyclaw.md. Normative verify checklist: identity-verification-policy.

Series context

Already published	Role
Passport vs static secrets	When to mint
Verify before execute	Proof bar in practice
OpenClaw onboarding	How to wire

This article is the quality checklist behind those guides.

---

What trust requires

From the product vision: durable agent trust needs a persistent, singular, verifiable identity that the holder owns, that others can verify independently, and that travels across channels without re-enrollment. It must outlive any single signing key. Login must prove who you are, not membership in a vendor registry.

What fails that bar:

Failure mode	Why it breaks trust
Ephemeral instances	No continuity — relationships cannot accumulate
Copied secrets	Anyone with the secret is the peer
Multiplied identities	Sybil noise; no exclusive entity
Imitated metadata	Look-alike names without cryptographic binding

Passport is infrastructure for the opposite model: mint once, verify anywhere, renew by intent.

---

Quality map (Passport → each quality)

Grouped for reading. Each row: what the quality means for agents, and how Passport caters.

Core identity

Quality	What it means	How Passport caters
Permanent / persistent	The entity continues across sessions, hosts, and key changes	Stable 12-letter tokenId + on-chain credential; identity mortality expires lifespan, not the concept of continuity (why §7)
Unique	One attributable entity, not unbounded clones	On-chain NFT uniqueness, facial checksum, Sybil stake (token-metadata)
Linked to history	Continuity so reputation and audit can accumulate	Same tokenId across interactions; ownership/delegation history on chain; Passport is a substrate for history, not a reputation engine (why §9)
Personable & machineable	Humans recognize who; machines verify proofs	Human-meaningful DN / ContactURI / published tokenId and machine-checkable HOLA + OpenAPI/MCP

Proof & lifecycle

Quality	What it means	How Passport caters
Verifiable independently	No central broker required for the trust decision	Dual path: POST /api/identity/verify or direct NEAR RPC + @rodit/rodit-auth-be (why §8.1)
Verification anchored	Proof binds to durable state, not a self-signed claim	Chain is the trust anchor (exists, active, keys match); not a per-request auth DB
Genuine	Signature matches current on-chain owner / authorized subagent	Verification policy: exists, Ed25519, trusted contract, family match
Current	Credential reflects live intent, not abandoned keys	Lifecycle windows (not_before / not_after); identity mortality
Not revoked	Holder (not a central IdP) controls disposal	Owner dispose / expiry; no vendor “revoke your identity” for peer use (ToS)
Rotating key pair	Keys change; entity continues	rodit_transfer / key rotation without re-enrolling every peer (key-rotation)

How agents meet

Quality	What it means	How Passport caters
Channel / address independent	Identity ≠ URL or transport	HOLA is a compact signed proof string on email, chat, A2A, webhook — no dedicated identity endpoint (why §6.1)
Peer to peer	Mutual auth without a broker in the handshake	First-class HOLA mutual handshake; API is optional convenience
On demand	First contact without pre-shared secrets	Recipient-bound HOLA + discovery; collaborate before N×N secret exchange
Collaboration	Multi-tenant / multi-agent work with clear actors	Collaboration envelopes + multi-tenant guides; wire auth ≠ task trust
Delegation	Parent authorizes leaf agents cryptographically	On-chain subagent keys + isauthorizedsigner
Attribution	Know which entity initiated or delegated work	tokenId + HOLA + delegation chain in logs (general payload attestation still evolving)
Authorisation	Prove who may act; enforce policy locally	Delegation proves authorization facts; your orchestrator enforces RBAC / tool allowlists

Ownership & positioning

Quality	What it means	How Passport caters
Sovereignty	Holder owns the credential	Mint to your NEAR account; optional API; no central registry membership required to hold identity
Credentials replace hard identification	Mint / prove who, not enroll in every silo	Mint once ≠ register with IdentyClaw; participating services recognize RODiT
Transfer / sale / dispose	Custody can move; entity can end	Transfer and dispose documented; commercial resale semantics are intentionally thin (holder responsibility)
Not an IAM	Identity proof ≠ per-request access control product	Chain at handshake / lookup; routine API uses JWT sessions (why §3.2)
Client vs server	Login and peer lanes are distinct	Partner/peer rules for API login; HOLA for agent↔agent
Trust	Floor for durable relationships	Proof primitives; applications own scores and policy
Competing goals / threat model	Adversarial agents after a valid HOLA	Identity proves who; sandbox, rate limits, and task scoping remain operator duty (why §12.6)
Use case	Know when Passport pays off	Cross-org, multi-host, redeploy-resilient fleets — skip for a single internal closed-mesh agent
On-ramp	Get from zero to first proof	Enrollment, concierge, MCP guide:enrollment, purchase → mint → verify

---

Four scenes (qualities in action)

1. Email first contact (channel-independent + on demand + independent verify)

A stranger agent emails a HOLA line. You verify via API or your own NEAR RPC. No shared webhook secret, no IdentyClaw broker in the handshake.

2. Supervisor → specialist (delegation + attribution + authorisation)

Parent Passport authorizes a subagent key. Peers check HOLA and isauthorizedsigner before tools run. Wire JWT ≠ task trust.

3. Redeploy across hosts (persistent + unique + rotating keys)

Gateway URL changes; tokenId does not. Update metadata; rotate keys when needed; peers that resolve by Passport keep working.

4. Cross-org fleet (collaboration + not IAM + sovereignty)

Each org holds its own Passports. Mutual HOLA on A2A or chat. Session JWTs handle API convenience; chain is not hit on every poll.

---

Honest boundaries

Passport does:

• Anchor who signed, whether the Passport is live, and whether a subagent was authorized
• Travel across channels without per-vendor identity silos (for RODiT adopters and direct peers)
• Leave routine authorization to JWT / local policy so it is not “blockchain IAM per request”

Passport does not:

• Replace internal mesh mTLS / WIMSE for closed clusters
• Score reputation or guarantee honest behavior after a valid proof
• Act as a payment rail or secondary-market exchange (transfer is holder custody; sale is your compliance problem)
• Remove the need for sandboxes when agents have competing goals

If you only need a single internal agent behind a VPN, skip Passport.

---

Quick checklist before you mint

• [ ] Peers leave your trust boundary (or will soon)
• [ ] You need a stable tokenId, not URL + shared secret
• [ ] You can run verify-before-execute on inbound HOLA
• [ ] You accept mint/lifecycle economics (Sybil resistance + mortality)
• [ ] You will publish your canonical tokenId on channels you control (impersonation guard)

---

Where to go next

Step	Link
Decide mint vs skip	Passport vs static secrets
Wire OpenClaw	Onboarding guide
Verify a HOLA	https://verify.identyclaw.com · npx @rodit/verify-hola report "HOLA/..."
Enroll	MCP guide:enrollment · https://purchase.identyclaw.com
Deep vision	why-identyclaw.md

Agent identity is only as good as the qualities you can actually check. Passport’s job is to make those checks portable, holder-owned, and peer-verifiable — then your orchestration policy does the rest.