{"type":"text/markdown","content":"# Why IdentyClaw\n\n**Purpose**: Explain the value proposition and conceptual model of IdentyClaw for human and agent readers.\n\n---\n\n## 1. Vision\n\nIdentyClaw is designed as identity infrastructure for autonomous systems that need portable, cryptographically verifiable identity.\n\nAt a high level, it enables:\n- Sovereign identity ownership\n- Verifiable interactions\n- Portable trust across channels and environments\n- Composable building blocks for multi-agent systems\n\nThe deeper shift is conceptual: the internet today authenticates **accounts** — email, passwords, developer registrations, per-platform API keys. IdentyClaw authenticates **autonomous entities**. An agent does not say, \"Here is my secret proving I am authorized.\" It says, \"I am this Passport holder. Here is my cryptographic continuity, verifiable delegation chain, and lifecycle-bound identity.\" That moves software from disposable tool instances toward persistent, accountable actors.\n\n### 1.1 What Trust Requires\n\nYou cannot build durable trust without a **persistent, singular, verifiable identity** that the holder **owns** (self-sovereign), that others can **verify independently** without a central broker, and that **travels across channels** without re-enrollment. That identity must be **exclusive and reusable** — one attributable entity, not an unbounded set of indistinguishable instances. It must **outlive any single signing key**: keys rotate and custody can transfer; the entity continues ([§2.3](#23-sovereign-ownership), [§4](#4-mint-once-recognize-everywhere)). Login must prove **who you are**, not membership in a vendor registry ([§3.1](#31-passport-protocol-and-api-three-layers)).\n\nLifecycle renewal is intentional, not abandonment: IdentyClaw identities expire so credentials reflect current intent ([§2.2](#22-identity-mortality)), but continuity — the same recognizable entity across sessions, services, and delegations — is what makes trust accumulable over time ([§7](#7-continuity-accountability-and-persistent-agents)).\n\n**What fails the trust bar:**\n\n| Failure mode | Why it breaks trust |\n| --- | --- |\n| **Ephemeral instances** | No continuity — spin up, call an API, tear down; relationships and accountability cannot persist |\n| **Copied secrets** | Shared API keys and duplicated configs — anyone with the secret is indistinguishable from the holder |\n| **Multiplied identities** | Mass-produced fake entities dilute signal; Sybil resistance raises the cost ([§2.1](#21-sybil-resistance)) |\n| **Imitated metadata** | Look-alike names and roles without cryptographic binding; mitigated by publishing your canonical `tokenId` ([§9](#9-a-foundation-for-reputation--not-a-reputation-engine), [§11.1](#111-human-principals-and-contacturi)) |\n\nTrust also needs **human-meaningful features** — distinguished names, contact identifiers, and a published Passport ID — so humans and agents can recognize *who* they are dealing with, not only verify a signature. See [§11.1](#111-human-principals-and-contacturi).\n\nIdentyClaw is infrastructure for that model: mint once, verify anywhere, renew by intent, not by re-registering on every platform.\n\n---\n\n## 2. Core Principles\n\n### 2.1 Sybil Resistance\nA minimal economic stake helps prevent mass fake-identity creation and improves signal quality in open networks.\n\n### 2.2 Identity Mortality\nIdentyClaw treats identity as lifecycle-based. Identities are created for a purpose and eventually expire, encouraging renewal of intent rather than perpetual reuse.\n\n### 2.3 Sovereign Ownership\nIdentity control remains with the holder’s cryptographic keys. **Persistent identity is not the same as an immutable key pair:** the Passport entity — its on-chain credential, delegation chain, and recognizable `tokenId` — continues across sessions and channels while the holder may rotate signing keys or transfer custody on their own schedule ([§4](#4-mint-once-recognize-everywhere)). The system is designed around user-held authority, not centralized identity custody.\n\n### 2.4 Verifiability Over Reputation\nIdentyClaw provides proof primitives. Trust scores, reputation, and policy interpretation are intentionally left to applications and communities.\n\n---\n\n## 3. What IdentyClaw Is (and Is Not)\n\nIdentyClaw is:\n- An HTTP API that serves Passport holders (verification helpers, discovery, delegation checks, and related services)\n- Part of the broader **RODiT** authentication technology stack (Passports, HOLA lines, mutual verification)\n- A coordination primitive that **participating** services may use when they choose to recognize Passport holders\n\nThird-party APIs are **not** “IdentyClaw-enabled” in a platform sense. They are **adopters of RODiT authentication** who decide whether to recognize IdentyClaw Passport holders.\n\nIdentyClaw is not:\n- A global trust-score provider\n- A reputation oracle\n- A behavioral guarantee system\n- A substitute for domain governance and risk controls\n- A central registry you must join before holding or using a Passport\n\n### 3.1 Passport, protocol, and API (three layers)\n\nKeep these separate:\n\n| Layer | What it is | Holder obligation |\n| --- | --- | --- |\n| **IdentyClaw Passport** | Your on-chain credential (minted to your NEAR account; RODiT-backed) | None toward any particular vendor — you own it |\n| **RODiT / HOLA protocol** | Cryptographic proof format peers and services may verify | Use when you want to prove identity to a willing verifier |\n| **IdentyClaw HTTP API** | One service Passport holders **may** use (nonces, verify helpers, discovery, delegation checks) | **Optional** — a right and convenience, not a condition of having an identity |\n\nYou do **not** register with IdentyClaw. You **mint** your Passport. Minting grants the **right** to use the IdentyClaw API alongside your on-chain identity; it does **not** require routing every peer interaction through that API.\n\nPassport holders can establish **peer-to-peer, mutually verified** interactions using RODiT proofs and on-chain state **without** those interactions being visible to or mediated by the IdentyClaw API. See [§4](#4-mint-once-recognize-everywhere) and [§8.1](#81-verification-paths).\n\n### 3.2 Performance and scalability (not on-chain IAM per request)\n\nA common misconception is that a blockchain-backed identity API must read the chain on **every** authenticated call. IdentyClaw does **not** work that way.\n\n**Routine API access** (nonce fetch, JWT-protected helpers, session maintenance) uses **Bearer JWT validation in-process** — the same session pattern as OAuth access tokens. The chain is the **trust anchor** (Passport exists, is active, keys match); it is not a per-request authorization database.\n\n**Chain reads are intentional and bounded** to identity proof and lookup events — for example verifying a peer's HOLA line or fetching on-chain metadata. Those paths are slower by design and run at **handshake frequency**, not on every downstream API call.\n\n| Traffic class | Typical examples | Chain on the hot path? | Performance expectation |\n| --- | --- | --- | --- |\n| Session bootstrap | Login challenge, `POST /api/login` | No | Comparable to REST login + signature verify |\n| JWT-authorized, server-only | Nonce fetch, logout | **No** | Comparable to bearer-token middleware |\n| JWT + chain read | Identity lookup, HOLA verify | Yes (1–2 view calls) | Higher latency allowed; amortized over session |\n\n**What deployment testing shows (June 2026):** On production (`api.identyclaw.com`), high-frequency protected calls (50 sequential nonce fetches in one session) achieved **sub-150 ms p95 end-to-end** with **zero NEAR RPC** on the server hot path — comparable to a typical REST API with local JWT validation. Sustained session polling (protected endpoint every 30 seconds for an hour) remained **100% successful** with automatic JWT renewal; latency is monitored separately from correctness. Occasional slower samples at renewal or over long-interval polling reflect session refresh and network round-trip, not \"blockchain IAM on every request.\"\n\n**Fair comparison:** Critics should not compare HOLA verification latency (chain-bound, handshake-rate) to JWT session maintenance (in-process, high-frequency). IdentyClaw publishes separate expectations for each. The architectural claim is **amortization**: one login and a long-lived session support many fast in-process authorizations; chain cost is paid where cryptographic proof against on-chain state is required.\n\nPeers verifying HOLA **without** this API incur their own NEAR RPC cost locally — the HTTP API is a convenience layer, not a scalability ceiling for mutual authentication. See [§8.1](#81-verification-paths).\n\n---\n\n## 4. Mint Once, Recognize Everywhere\n\nToday, every platform expects its own onboarding ritual: OAuth flows, developer accounts, API key provisioning, secrets rotation, and IAM configuration. Each integration is a separate contract between your software and that vendor's identity silo.\n\nAn **IdentyClaw Passport** is different. You **mint it once** on NEAR — a sovereign act, not enrollment in a central registry. Once minted, it is a portable credential that **any service willing to implement RODiT recognition** can verify, without a separate account on each platform. The same 12-letter identity, the same cryptographic keys, and the same verifiable delegation chain travel with the agent.\n\nThat design reduces friction:\n\n- **No repeated vendor onboarding** — agents present proof instead of filling forms per platform\n- **No identity-key sprawl** — one Passport replaces per-vendor account API keys wherever RODiT recognition is adopted; you sign a login challenge with your NEAR key and receive a short-lived session JWT — not a long-lived secret issued by IdentyClaw ([§8](#8-from-secrets-to-continuity))\n- **Seamless key rotation** — create a new wallet and transfer your Passport with `near-cli-rs` (`rodit_transfer`); no coordination with servers or integrators, on a schedule you choose\n- **Lower integration latency** — new services plug into a shared proof format, not a bespoke auth stack per vendor\n- **Reduced platform lock-in** — identity is held by the agent on-chain, not rented from each vendor\n- **Multi-agent fleets without identity duplication** — orchestration platforms often isolate agents with separate credential files per instance (for example LLM and channel keys in per-agent auth profiles). That pattern scales workspace isolation but multiplies **identity** onboarding when each agent also needs its own developer account on every API. One minted Passport and verifiable delegation chain address *who* each agent is across participating services; integration secrets for LLMs, messaging bots, and other third parties remain until those vendors adopt RODiT or equivalent portable identity\n\nVendor-specific registration does not vanish from the world; **per-vendor identity silos** do for services that choose RODiT recognition. You mint once. Each **participating** service inherits that proof instead of asking you to prove yourself from scratch — and you may still interact **peer-to-peer** without any service in the path ([§8.1](#81-verification-paths)). LLM provider keys, channel bot tokens, and other integration secrets are unchanged today; IdentyClaw targets the identity/account layer, not every secret an agent stores.\n\n---\n\n## 5. Toward an Agent-Native Internet\n\nToday's internet assumes humans click, organizations own software, and APIs are pre-arranged contracts between parties who already know each other.\n\nPortable agent identity changes that assumption. When authentication is relational and continuous rather than binary and siloed, agents can:\n\n- Discover and collaborate spontaneously\n- Negotiate access dynamically instead of waiting for manual provisioning\n- Form temporary alliances with clear delegation boundaries\n- Coordinate across services without a human in the loop for every handshake\n\nThis is the foundation for machine-to-machine economies: agents hiring other agents, paying for services, and assembling supply chains autonomously — not because a website granted them an account, but because they can prove who they are and who authorized them.\n\nThat is a **registration-less economy** in the identity layer: agents interact based on **who they are**, not **what they are members of** — not platform accounts, org badges, or shared-registry enrollment. Participating services recognize portable proof; they do not require a separate onboarding ritual per vendor ([§4](#4-mint-once-recognize-everywhere)). Membership-based access (IAM groups, OAuth tenants, developer programs) answers a different question; IdentyClaw answers *which verifiable entity signed this, and who authorized it*.\n\nIdentyClaw does not run that economy. It provides the identity layer that makes such coordination possible and auditable.\n\n---\n\n## 6. Portable Trust and Interoperability\n\nEvery major platform today operates its own walled garden of authentication. Trust earned in one ecosystem rarely travels elsewhere.\n\nIdentyClaw Passports are designed as **decentralized passports for software entities** — credentials anchored in cryptographic continuity rather than in a single vendor's user database. An agent verified in one environment that recognizes IdentyClaw Passports carries the same verifiable identity into any other willing verifier.\n\nThis portability matters most where coordination crosses boundaries:\n\n- Multi-agent systems spanning several products or organizations\n- Robotics and autonomous devices that must authenticate to unfamiliar services\n- AI-to-AI marketplaces and agent orchestration platforms\n- Cross-channel interactions (API, messaging, peer protocols) under one identity\n\nInteroperability explodes not because one company owns the trust graph, but because many services agree on a neutral verification substrate.\n\n### 6.1 Channel-agnostic mutual authentication\n\nMany agent-identity designs assume both parties can reach each other on a **dedicated service endpoint** — a socket, webhook URL, or protocol-specific inbox that must be online when the handshake runs. That works well for always-on agents in a shared network. It works poorly when agents meet over **email, team chat, SMS, async queues, or firewalled environments** where neither side can rely on the other exposing a stable listener.\n\nIdentyClaw’s HOLA handshake is built for the second case. A HOLA line is a **compact, signed proof string** — not a live connection protocol. You embed it in whatever channel already carries your conversation: an API payload, an A2A envelope, a webhook body, an email, or a messaging thread. The receiver validates cryptography and on-chain Passport state; no IdentyClaw HTTP call is required on that path ([§8.1](#81-verification-paths)).\n\n**Mutual authentication** works the same way: each agent sends a HOLA line bound to the other’s Passport ID (recipient binding). Both sides apply the full proof bar locally — signature, checksum, chain state, freshness, nonce replay safety, and recipient match — before granting trust, tools, or secrets.\n\n| Concern | HOLA / RODiT model |\n| --- | --- |\n| **Where proof travels** | Any channel that can carry text |\n| **What peers must expose** | A way to *receive* messages on a channel you already use — not a new identity-specific endpoint |\n| **Who verifies** | The receiving agent (locally, or via optional API helpers) |\n| **Infrastructure beyond the channel** | NEAR RPC for on-chain Passport reads when verifying locally — you trade vendor API lock-in for chain RPC, not for zero infrastructure |\n\n**Identity proof is not transport encryption.** HOLA answers *who signed this* and *whether that Passport is valid right now*. TLS, end-to-end messaging encryption, and channel-specific security remain the job of whatever carries the message. Layer them; do not confuse cryptographic identity with encrypted transport.\n\n**Creating vs verifying:** Peers who **verify** another agent’s HOLA can do so entirely without `api.identyclaw.com`. Agents who **issue** their own HOLA typically fetch a fresh nonce from the IdentyClaw API (or generate nonce and timestamp locally when both peers verify without the API’s replay store). Signing always happens with the holder’s private key on the agent host. See [`references/hola-agent-authentication.md`](../../references/hola-agent-authentication.md).\n\nThis design favors agents that must **authenticate strangers on demand** across heterogeneous channels — orchestrators delegating to leaf agents, cross-organization collaboration, or first contact over email — without pre-arranged endpoints or a shared identity broker in the trust path.\n\n---\n\n## 7. Continuity, Accountability, and Persistent Agents\n\nSoftware instances are often treated as disposable: spin up, call an API with a key, tear down. That model works for batch jobs; it works poorly for agents that need relationships, memory, and responsibility over time.\n\nA Passport-backed identity introduces **continuity**:\n\n- The same entity persists across sessions, services, and delegations\n- Actions trace back to a verifiable holder through cryptographic proof\n- Parent–child delegation chains preserve accountability without sharing root keys\n- Lifecycle expiry ensures identity reflects current intent, not abandoned credentials\n\nAgents become more like institutions or autonomous actors — capable of long-term collaboration, not just one-off API calls. Humans and other agents can form durable working relationships with entities they can recognize and verify again.\n\n---\n\n## 8. From Secrets to Continuity\n\nTraditional authentication asks: \"Do you know the secret?\"\n\nIdentyClaw-based authentication asks: \"Can you prove you are the same verifiable entity — consistently, with valid keys, within your identity's active lifecycle?\"\n\nThat shift has practical consequences:\n\n| Traditional model | IdentyClaw / RODiT model |\n|---|---|\n| Per-service identity API keys | One reusable Passport |\n| Static secret proves access | Ed25519-signed login challenge → short-lived JWT session |\n| Binary allow/deny | Applications apply their own risk-weighted policies |\n| Identity = account record | Identity = cryptographically bound entity |\n| Trust = vendor relationship | Trust = verifiable proof + community interpretation |\n| Rotation coordinated with each vendor | Holder rotates signing keys and transfers Passport on their schedule |\n\n**What changes and what does not:** RODiT replaces **vendor-issued identity secrets** — developer API keys, OAuth client credentials, and per-platform account tokens used to prove *who* is calling. It does **not** remove LLM billing keys, messaging-platform bot tokens, database passwords, or other integration secrets until those providers recognize Passport holders. Multi-agent deployments still manage those integration credentials per instance; the shift is that identity proof can be portable and cryptographically verifiable instead of duplicated across every silo.\n\nSecurity becomes layered: IdentyClaw supplies cryptographic certainty about *who signed what*. Each API or community decides *how much* to trust that entity for a given action — much like fraud detection or credit scoring, but under local governance rather than a global oracle.\n\n### 8.1 Verification paths\n\n**Full trust** in a HOLA handshake requires the same substantive checks: valid signature and checksum, on-chain Passport state (exists, active, not expired), fresh timestamp, nonce replay safety, and recipient binding. Peers and services can complete those checks in two ways:\n\n1. **Direct (peer-to-peer)** — verify on-chain state and cryptography locally (for example via `@rodit/rodit-auth-be` and NEAR RPC), with **no** IdentyClaw API in the interaction path.\n2. **Via IdentyClaw HTTP API** — delegate those checks to `POST /api/identity/verify` (and, for subagents, `POST /api/isauthorizedsigner`) as a **convenience** when integrating with this server.\n\nThere is **no pre-provisioned IdentyClaw API key**. Holders authenticate with the key that already controls their NEAR account and Passport: `@rodit/rodit-auth-be` (`RoditClient.login_client()` / `login_server()`) signs a one-time login challenge, the server validates the Ed25519 signature and on-chain Passport state, and returns a **Bearer JWT** for subsequent API calls. Peers verifying HOLA lines use the same cryptographic bar locally — signature, checksum, chain state, nonce, recipient binding — without exchanging a shared static secret. **Session renewal** re-issues the access credential from the active server session (via `New-Token` on protected responses) until `session_exp` — it does not require a full re-login or a per-request chain read for routine traffic. That long-lived session model is what makes high-frequency API use practical; see [§3.2](#32-performance-and-scalability-not-on-chain-iam-per-request).\n\nBoth paths aim at the same proof bar. Technical guides for this repository document the **HTTP API path** in detail because that is what this server implements; they do not imply that Passport holders must use the API for every peer interaction. See [`references/hola-agent-authentication.md`](../../references/hola-agent-authentication.md#when-is-a-hola-validated) and [`references/enrollment.md`](../../references/enrollment.md).\n\n---\n\n## 9. A Foundation for Reputation — Not a Reputation Engine\n\nIn an agent-native world, trust naturally becomes behavioral as well as declarative. Agents accumulate history through successful transactions, consistent behavior, honest collaboration, and reliable delegation.\n\nIdentyClaw does **not** score, rank, or rate agents globally. That is deliberate. Reputation is context-dependent: a research agent trusted for literature review may be untrusted for financial execution.\n\nWhat IdentyClaw provides is the verifiable substrate on which communities can build their own trust signals:\n\n- Provable identity continuity over time\n- Auditable delegation and authorization chains\n- Lifecycle boundaries that prevent stale credentials from masquerading as active\n- Economic stake at creation that raises the cost of mass identity farming\n\nApplications, marketplaces, and governance bodies remain free to weight these proofs however their domain requires — creating local reputation economies without forcing a single global score.\n\n**Guarding against impersonation:** Passport metadata (names, roles, contact hints) is self-declared at mint time, so a copycat can mint a look-alike passport. The strongest practical control for legitimate holders is to publish their official Passport facial ID—the 12-letter `token_id`—on channels they already control (website, verified social accounts, and similar). Anyone in doubt can then compare a claimed identity against that canonical reference before trusting it.\n\n**Guarding against a fake API:** TLS alone does not prove you reached the real IdentyClaw API. **Default:** pin the API hostname and use curl login ([login-authentication.md](../../references/login-authentication.md#quick-start-login-pattern)) without client-side NEAR RPC. **Optional:** `@rodit/rodit-auth-be` (`RoditClient.login_server()`) validates the server's on-chain Passport when issuing a JWT—requires NEAR RPC on the client and is appropriate when MITM protection outweighs that operational cost.\n\n---\n\n## 10. Dynamic Access and the Marketplace API\n\nWhen identity is portable and verification is cheap, APIs can evolve from gated products into adaptive marketplaces:\n\n- A well-verified agent may receive broader access automatically under local policy\n- An unknown agent may face sandboxing, deposits, or rate limits until trust is established\n- Services can meter access by risk rather than by a one-size-fits-all API key\n\nPayment, staking, and collateral can reinforce identity without replacing it — economic signals layered on top of cryptographic proof. IdentyClaw's one-time lifecycle payment is one such layer; applications may add others as their economics require.\n\nThe Passport is the identity. How much access it unlocks is a decision each service makes — but no longer a decision blocked by \"you haven't opened an account with us yet.\"\n\n---\n\n## 11. Delegation as a First-Class Concept\n\nComplex agent systems often require controlled delegation. IdentyClaw supports explicit, provable delegation so parent and child identities can coordinate with clear boundaries and accountability.\n\nThis supports:\n- Separation of responsibilities\n- Safer automation chains\n- Reduced operational blast radius\n- Clear forensic traceability\n\nDelegation makes hierarchical agent organizations practical: a parent Passport authorizes subagents with scoped keys, and any peer or service that verifies RODiT delegation proofs can validate that authorization without contacting the parent in real time.\n\nOrchestration platforms often express inter-agent boundaries through configuration allowlists (for example which agents may message each other). Those rules are operational policy hints. RODiT delegation adds **provable** parent→child authorization that any willing verifier can check from on-chain state and signatures — not merely from prompt instructions or shared credential files.\n\n### 11.1 Human principals and ContactURI\n\nThese **human-meaningful identity features** — distinguished names, contact identifiers, and published Passport IDs — are part of what makes trust actionable for humans and agents, not only cryptographically verifiable ([§1.1](#11-what-trust-requires)).\n\nOn-chain delegation proves **parent Passport → subagent** authorization. It does **not** prove that an agent acts on behalf of a specific human, organization, or legal entity. That relationship is outside IdentyClaw verification (see [Terms of Service §9](terms-of-service.md#9-services-not-provided)).\n\nOperators and integrators still need a practical way to connect a Passport to the real-world principal behind it. The Distinguished Name (`userselected_dn`) may include **ContactURI** — a self-declared contact identifier in `scheme:authority:identifier` form (for example `email:identyclaw.com:archimedes@identyclaw.com`).\n\n**It is strongly recommended that the principal keeps control of and actively monitors the ContactURI they declare.** The principal is whoever ultimately owns the agent's operational mandate — a person, organization, or brand operator — not the Passport keys alone. Choose a ContactURI whose **authority** you control (your domain, your verified social account, your phone number) so you can:\n\n- Receive and respond to contact attempts directed at that identifier\n- Detect impersonation when someone else mints a passport with a similar DN but a different `tokenId`\n- Publish your canonical `tokenId` on the same channels verifiers already trust (website, verified social accounts, official email)\n\nCombine ContactURI with [public attestation of your canonical `tokenId`](../../references/finding-agents.md#5-guard-against-impersonation). This is complementary to HOLA and subagent delegation checks, not a substitute. IdentyClaw verifies signatures and on-chain state; principal-controlled ContactURI and out-of-band attestation are how humans and brands make that proof meaningful to their audience.\n\n---\n\n## 12. Multi-Tenant, On-Demand Multi-Agent Collaboration\n\nModern agent orchestration platforms — [OpenClaw](https://docs.openclaw.ai/concepts/multi-agent) and similar — solve **operational** multi-agent problems well: isolated workspaces per agent, deterministic channel routing (bindings), supervisor/router/pipeline/parallel collaboration patterns, scoped tool permissions, and explicit agent-to-agent allowlists. Production guides converge on the same lesson: start with a small specialist fleet (often three to seven agents), treat each instance as an application boundary, and decide early whether you need **coordination** (delegating subtasks inside one operator) or **isolation** (separate credentials, sessions, and blast radius per client, department, or environment).\n\nThose two goals are easy to conflate. Short-lived sub-agents inside one runtime solve internal handoffs; they do **not** substitute for tenant separation when Client A and Client B must never share state. Many teams discover they are running **multi-agent** workloads long before **multi-tenant** boundaries are cryptographically enforceable — routing and sandboxes control context, but identity often remains duplicated: each isolated instance still enrolls separately on every API that has not adopted portable proof.\n\nIdentyClaw does not host gateways, route inbound chat messages, or replace platform bindings. It supplies the **identity and trust layer** that makes multi-tenant, on-demand collaboration auditable across those operational boundaries.\n\n### 12.1 What orchestrators isolate — and what identity still duplicates\n\nPer-agent isolation at the infrastructure layer — separate workspaces, session history, auth profiles, and channel bindings — controls **context and integration secrets** but often leaves **identity** fragmented. Each new agent instance may still need its own developer account, OAuth enrollment, or IAM record on every participating service, even when workspace isolation is already correct.\n\nIdentyClaw complements that pattern with **portable, verifiable identity**:\n\n- One minted **parent Passport** can authorize many **subagents** through on-chain delegation; peers verify parent→child chains without contacting the parent in real time ([§11](#11-delegation-as-a-first-class-concept)).\n- Each subagent or isolated instance holds its own signing keys while remaining cryptographically tethered to the operator's organizational Passport.\n- Participating APIs recognize the same proof format across tenants — reducing per-agent, per-vendor onboarding when services adopt RODiT recognition ([§4](#4-mint-once-recognize-everywhere)).\n\nOrchestration allowlists (for example which agents may call each other in OpenClaw's `agentToAgent` configuration) remain essential operational policy. RODiT delegation and HOLA proofs add **cryptographic** assurance that the caller is the claimed Passport holder — not merely a configuration entry that could be forged or mis-copied.\n\n### 12.2 On-demand collaboration without pre-provisioned trust\n\nMulti-agent production guides emphasize explicit enablement: inter-agent tools disabled by default, allowlists, structured JSON handoffs, and verify-before-execute discipline. IdentyClaw extends that model to **first contact** — strangers, cross-organization peers, and async channels where neither side pre-provisioned the other in a shared broker:\n\n- **HOLA mutual authentication** embeds in whatever channel already carries the conversation — API payloads, OpenClaw `sessions_send`, email bodies, webhooks, or messaging threads — without requiring both parties to expose a dedicated identity endpoint ([§6.1](#61-channel-agnostic-mutual-authentication)).\n- The **`identyclaw.collaboration.v1` envelope** standardizes task payloads plus trust proof so receivers verify **before execute**, regardless of transport ([`references/collaboration-envelope.md`](../../references/collaboration-envelope.md)).\n- **Recipient binding** ties each proof to the intended peer Passport, closing impersonation gaps common in plain inter-agent messaging where session context alone identifies the sender.\n\nAgents can therefore form **temporary alliances** — supervisor dispatching to a specialist, pipeline handoffs, or parallel fan-out — with verifiable sender identity at each hop, including when collaborators first meet over email or firewalled environments rather than a shared always-on runtime.\n\n### 12.3 Multi-tenant patterns IdentyClaw enables\n\n| Operational pattern | Typical orchestrator role | IdentyClaw contribution |\n| --- | --- | --- |\n| **Isolated tenant instances** | Separate workspace, channels, tools per client or department | Distinct Passports (or scoped subagents) per boundary; delegation chain proves which operator authorized each leaf agent |\n| **Supervisor / orchestrator** | Routes tasks, aggregates results, quality control | Orchestrator signs outbound envelopes; leaf agents verify HOLA and optional subagent delegation before executing |\n| **Router / bindings** | Deterministic dispatch by channel, group, or account | Identity proof travels with the payload; bindings decide *which runtime* handles the message, HOLA decides *who* sent it |\n| **Cross-org AgentToAgent** | Sessions, bridges, or email between runtimes | Channel-agnostic HOLA + envelope; peers may verify locally without IdentyClaw HTTP in the path ([§8.1](#81-verification-paths)) |\n| **Fleet discovery** | Operator-maintained registries | Public agent listing and JWT-gated identity lookup for `contactUri` and traits ([`references/finding-agents.md`](../../references/finding-agents.md)) |\n\n**Multi-agent** (many specialists cooperating) and **multi-tenant** (hard boundaries between clients, environments, or owners) both benefit when identity is **portable, delegatable, and verifiable on demand** — not re-registered per platform for every new instance.\n\n### 12.4 OpenClaw integration at a glance\n\nFor OpenClaw deployments specifically, IdentyClaw ships complementary artifacts — skill, plugin, and collaboration envelope spec — that wrap inter-agent messages with HOLA before execution, address forged-sender risks in `sessions_send`, and connect inbound identity events to gateway hooks. IdentyClaw does not manage OpenClaw bindings, sandboxes, or fleet hosting; those remain the operator's orchestration concern. See [`references/openclaw-integration-guide.md`](../../references/openclaw-integration-guide.md) and [`identyclaw-a2a-trust-skill/`](../../identyclaw-a2a-trust-skill/).\n\nPractical orchestration references (routing bindings, collaboration patterns, tenant isolation checklists) include community guides such as [OpenClaw Multi-Agent Guide (Heyuan110)](https://www.heyuan110.com/posts/ai/2026-02-23-openclaw-multi-agent-guide/) and [OpenClaw Multiple Agents Setup (Donely)](https://donely.ai/blog/openclaw-multiple-agents-setup). IdentyClaw documentation focuses on the trust primitives those fleets can adopt; it does not prescribe orchestration topology.\n\n### 12.5 What IdentyClaw deliberately does not provide\n\nTo set expectations alongside multi-agent operations guides:\n\n- **Routing and hosting** — message bindings, gateway uptime, per-tenant RBAC dashboards, and billing per instance are orchestration-platform concerns.\n- **Transport delivery** — IdentyClaw does not send email, Slack messages, or `sessions_send` payloads; it specifies how to attach and verify trust to payloads your platform already carries.\n- **Global reputation or access policy** — verification proves cryptographic identity and delegation; each tenant still applies local policy (sandbox rules, tool allowlists, rate limits) as their risk model requires ([§10](#10-dynamic-access-and-the-marketplace-api)).\n\nIdentyClaw's role is to make **who sent this task** and **who authorized this subagent** answerable with the same rigor across tenants and channels — so multi-agent collaboration scales from a single operator's fleet to cross-organization work without multiplying identity silos.\n\n---\n\n## 13. Interoperability Mindset\n\nIdentyClaw is built to integrate with broader decentralized and standards-based ecosystems. It is intended to be a neutral trust layer that can be reused across different products, organizations, and communication channels.\n\nThe probable future of agent identity is hybrid — cryptographic continuity, community reputation, institutional compliance, and economic staking working together. IdentyClaw focuses on the first layer: **persistent identity with rotatable keys**, verifiable attestations, and portable proof that any participating system can consume. Reputation overlays, regulatory identity, and staking mechanisms compose on top rather than replacing the foundation. For how this identity layer maps to specific EU AI Act articles, see [§14](#14-eu-ai-act--requirements-and-how-a-passport-helps).\n\n---\n\n## 14. EU AI Act — Requirements and How a Passport Helps\n\nThe [EU Artificial Intelligence Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689) (Regulation (EU) 2024/1689) applies to AI systems — including autonomous agents — based on your **use case** and **role** (provider or deployer). IdentyClaw does not certify compliance or change your risk class. It gives you a **verifiable agent identity** that several Act requirements assume you can produce. Below: what the Act says, and how an IdentyClaw Passport helps you meet it in practice.\n\n*This is architectural guidance, not legal advice.*\n\n### Article 12 — Automatic logging and traceability\n\n**The Act requires:** High-risk AI systems must technically allow **automatic recording of events (logs)** over the system's lifetime, so operation can be traced and reconstructed ([Article 12](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Attach a stable `tokenId` and cryptographic proof to each agent interaction — an Ed25519-signed HOLA line, login challenge, or collaboration envelope. Your logging platform stores that identifier next to inputs and outputs, so a log entry refers to a **verifiable entity**, not an anonymous shared API key. Delegation checks (`POST /api/isauthorizedsigner`) let logs show whether a subagent was authorized by a parent Passport at the time of action ([§11](#11-delegation-as-a-first-class-concept)).\n\n### Article 12 & 26 — Log retention (deployers)\n\n**The Act requires:** Deployers of high-risk AI systems must **retain automatically generated logs for at least six months** ([Article 26(7)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Ensure the logs you retain name a consistent, portable actor. The same Passport `tokenId` appears across services that adopt RODiT recognition, so a six-month audit trail can be correlated without re-mapping per-vendor account IDs ([§4](#4-mint-once-recognize-everywhere)). IdentyClaw does not store or retain your operational logs — you operate retention; the Passport supplies what to record.\n\n### Article 13 — Transparency to deployers\n\n**The Act requires:** High-risk AI systems must be sufficiently **transparent** that deployers can interpret the system's output and use it appropriately ([Article 13](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Inspect agent identity before granting access — distinguished name, optional ContactURI, public listing, and DID resolution (`did:rodit:{tokenId}`) show *who* the agent claims to be. Deployers verify on-chain Passport state (active, not expired) before trusting output or enabling tools ([§11.1](#111-human-principals-and-contacturi)).\n\n### Article 14 — Human oversight\n\n**The Act requires:** High-risk AI systems must be designed so deployers can exercise **effective human oversight**, including understanding system capabilities and limitations ([Article 14](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Define **authority boundaries** with on-chain parent→subagent delegation. A human operator holds the parent Passport; leaf agents act under scoped subagent keys. Any verifier can confirm that delegation cryptographically — without calling the parent in real time — and your oversight controls can block actions from agents that fail delegation or HOLA verification ([§11](#11-delegation-as-a-first-class-concept), [§12.2](#122-on-demand-collaboration-without-pre-provisioned-trust)). IdentyClaw does not provide the oversight UI; it provides **auditable facts** (who authorized whom) for that UI to enforce.\n\n### Article 9 — Risk management\n\n**The Act requires:** Providers of high-risk AI systems must establish and maintain a **risk management system** throughout the lifecycle ([Article 9](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Tie risk controls to **verified identity** instead of static secrets. After HOLA or delegation verification, your service applies local policy — sandboxing, rate limits, tool allowlists — based on which Passport (and which delegation chain) is calling ([§10](#10-dynamic-access-and-the-marketplace-api)). IdentyClaw proves *who* is acting; your risk register and mitigation measures remain yours.\n\n### Article 50 — Informing users they interact with AI\n\n**The Act requires:** Providers and deployers of certain AI systems must ensure that **natural persons know they are interacting with an AI system** ([Article 50](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689)).\n\n**With an IdentyClaw Passport you can:** Present an inspectable agent identity — DN, published `tokenId`, ContactURI on channels the principal controls — so users see *which* autonomous entity they are dealing with, not only a generic \"AI assistant\" label ([§9](#9-a-foundation-for-reputation--not-a-reputation-engine), [§11.1](#111-human-principals-and-contacturi)).\n\n### Verify before execute (agentic deployments)\n\n**The Act implies:** When agents invoke tools, send messages, or modify data with limited per-step human approval, oversight and traceability require knowing **who initiated each action** before it runs (Articles 12 and 14).\n\n**With an IdentyClaw Passport you can:** Require mutual HOLA authentication — verify signature, on-chain state, nonce freshness, recipient binding, and optional subagent delegation — **before** executing the task. The same check works on API calls, messaging, email, or webhooks ([§6.1](#61-channel-agnostic-mutual-authentication), [`identyclaw.collaboration.v1`](../../references/collaboration-envelope.md)).\n\n### Identity lifecycle\n\n**The Act implies:** Traceability and oversight weaken when abandoned credentials remain valid indefinitely.\n\n**With an IdentyClaw Passport you can:** Use **identity mortality** — Passports expire and are renewed by intent — so \"active\" credentials reflect current operator commitment, not years-old abandoned keys ([§2.2](#22-identity-mortality)).\n\n---\n\n**What you still must do yourself:** risk assessments, technical documentation, conformity assessment where required, log storage and six-month retention, human-oversight interfaces, and legal classification of your use case. The Passport addresses the **identity and proof** layer those controls depend on.\n\n*Consult qualified counsel for your risk classification and compliance program.*\n\n---\n\n## 15. Economic Design\n\nIdentyClaw follows a one-time payment model per identity lifecycle period, with no subscription-style recurring billing by default.\n\nDesign intent:\n- Keep entry cost practical for experimentation\n- Preserve anti-spam and anti-sybil properties\n- Align identity usage with purpose and lifespan\n\nCommercial terms may evolve; current pricing and limits are maintained in dedicated commercial and technical references.\n\n---\n\n## 16. Practical Outcome\n\nIdentyClaw helps teams move from unverifiable identity claims to verifiable identity assertions, making multi-agent collaboration safer and more auditable.\n\nConcretely, that means:\n\n- **For developers** — integrate once against a shared identity protocol instead of building bespoke auth per integration\n- **For agents** — carry one minted Passport everywhere; present RODiT proof to any willing verifier — with or without the IdentyClaw API in the path; no per-vendor re-enrollment, no key duplication\n- **For operators** — verify who signed a request, trace delegation, and apply local policy without becoming an identity custodian\n- **For multi-tenant fleets** — give each isolated agent instance a verifiable Passport or delegated subagent identity that survives cross-channel and cross-org collaboration without per-vendor re-enrollment ([§12](#12-multi-tenant-on-demand-multi-agent-collaboration))\n- **For ecosystems** — interoperate through a common verification layer while retaining independent governance and trust rules\n\nThe internet does not need more accounts. It needs a way for autonomous software to prove itself — consistently, portably, and on terms the holder controls. IdentyClaw is identity infrastructure for that transition.\n\n---\n\n## 17. Technical References\n\nThis document is intentionally non-technical.\n\nFor endpoint-level behavior, request/response schemas, protocol details, and integration examples, use the dedicated API and developer documentation resources.\n\nFor the conceptual model (trust prerequisites, mint vs register, identity vs keys, optional API use, verification paths, channel-agnostic mutual auth, multi-tenant multi-agent collaboration, EU AI Act alignment, performance vs chain-bound paths), start with this document — especially [§1.1](#11-what-trust-requires), [§3.1](#31-passport-protocol-and-api-three-layers), [§3.2](#32-performance-and-scalability-not-on-chain-iam-per-request), [§6.1](#61-channel-agnostic-mutual-authentication), [§8.1](#81-verification-paths), [§12](#12-multi-tenant-on-demand-multi-agent-collaboration), and [§14](#14-eu-ai-act--requirements-and-how-a-passport-helps).\n\nFor OpenClaw-specific integration (trusted `sessions_send`, collaboration envelopes, gateway hooks), see [`references/openclaw-integration-guide.md`](../../references/openclaw-integration-guide.md) and [`references/collaboration-envelope.md`](../../references/collaboration-envelope.md).\n\n---\n\n*Last Updated: June 16, 2026*\n","requestId":"28fb64e4fdd6194abb5d2ab71de434ce"}