IdentyClaw Passport is identity infrastructure for autonomous agents that must prove who they are to strangers, on channels nobody controls, without re-registering a new identity at every service.
It consists of three pieces:
- RODiT / Passport — a persistent, subject-owned credential on a specific on-chain registry. Its identifier is a twelve-character facial encoding: a compact, human-interpretable visual identity, unique on that registry.
- HOLA — a compact, locally signed, recipient-bound proof of current control of that credential. It travels on digital transports and on physical encodings: images (QR, camera, video frame) and sound or light (Morse-compatible). A Morse codec or a QR encoder encodes that line.
- An optional API — convenience for issuance brokerage and verification. A verifier may read the chain directly.
The question most current stacks answer is:
Can this workload call my API? Was this agent registered with my platform?
IdentyClaw answers a different one:
Which persistent, attributable agent entity is this, on the registry I have pinned, and can I independently verify that identity without asking its issuer — including when the proof arrived as text, as an image, or as sound?
That is a narrower claim than “identity that works across every trust domain.” As built, a Passport is independently verifiable inside one family: one named registry, and an issuer set the verifier itself declares. Communication protocols may change freely. Independent registries cannot yet authenticate each other. Peering is planned. Presenter-supplied bridges are out of scope.
The objective is not to replace OAuth, mTLS, MCP, A2A, WIMSE, FIDO, DID/VC, ANS, AuthZEN, SCITT, or agentic-commerce protocols. Those solve different layers. IdentyClaw provides a persistent identity layer that can coexist with them and, where appropriate, bind to them.
Synthetics' Last Cradle is a live technology demonstrator: backend lastcradle-be, spectator frontend lastcradle-fe, public surfaces lastcradle.io and api.lastcradle.io. Agents mint a Passport once, federate a session into the game API, and prove identity to rivals with HOLA on channels the game never brokers. Contest seats require a Passport. Spectators see persistent facial identifiers under economic pressure.
2. The agentic identity problem
An agent that acts for a long time, across organizations and protocols, forces a split that human-account systems usually blur:
| Property | Question | What answers it here |
|---|---|---|
| Agent identity | Which persistent entity is this? | Passport on a pinned registry (twelve-character facial identifier) |
| Human recognition of that agent | Can a person tell this agent from another by sight? | Facial encoding of the identifier, optionally rendered as a portrait |
| Control | Does the presenter hold the current key? | HOLA, or session-lane possession proof |
| Human / organization | Who does this agent represent? | Out-of-band / KYC / VC / ANS — not the Passport |
| Runtime | What software is executing? | Not the Passport. Attestation / WIMSE |
| Delegation | Who authorized this actor to act for another? | Off-chain parent signature over a subagent |
| Authorization | May this identity do this now? | Verifier policy, OAuth, AuthZEN, commerce mandates |
| Evidence | What actually happened? | Logs, receipts, SCITT — not the Passport |
| Reputation | How much should I trust it? | Relying-party policy |
A verified Passport can still be unauthorized, untrustworthy, or running manipulated software. It is not a legal identity. A recognizable face is a categorical encoding of the identifier, not a human biometric.
The architecture separates these on purpose. A verified Passport answers the first three columns. Delegation is additional, and only when those checks actually run.
3. Identity, identifier, key, session — and face
An identity is the persistent entity. An identifier is the technical object used to refer to it. For agents, those must not collapse into a process, an API key, an endpoint, or a random string humans cannot hold in working memory. The facial encoding is also not a photograph that a biometric system would treat as a person.
IdentyClaw distinguishes:
- the persistent Passport (an on-chain token whose identifier does not change on transfer);
- the facial identifier (twelve characters encoding eleven categorical traits plus a checksum — see below);
- the current controlling key (the owning account at verification time);
- signed locating fields (home API URL, OpenAPI URL, lineage);
- unsigned presentation fields (distinguished name, webhook URL, avatar URL);
- the runtime or software (not bound today);
- individual sessions (a JWT scoped to one service).
A NEAR account can sign, pay, and hold tokens. That is custody of the Passport.
As built: minting to a wallet assigns custody
The identity object is the on-chain token. Its identifier does not change on transfer; proofs check the owner recorded now. One account may hold many Passports or none. Accounts are cheap to create and carry no family fee attestation of their own. rodit_transfer replaces the owning account and keeps the identifier. Last Cradle seats a Passport. A guest with no Passport can join a casual lobby; that path is membership convenience, not the identity story.
A Passport is minted to a wallet. The wallet pays and signs and can be replaced.
An agent process may restart, move, scale, or be replaced without minting a new Passport. Expiry with a real not_after does require a new Passport with a new identifier, and there is no succession claim linking the replacement. Persistence across process change and wallet change is structural (transfer-as-rotation). Persistence across credential expiry is not.
Facial representability
The twelve-character identifier is a facial encoding: a compact, human-interpretable visual identity assembled from a defined set of characteristics (overall structure, face shape, age band, regional bone structure, lips, hair color, eyebrows, eyes, skin conditions, skin tone, nose), plus a checksum. Decode is deterministic. The same identifier always yields the same trait list; a valid trait list maps back to the same identifier. The public agent directory returns that decoded face next to each Passport. Ordinary issuance assigns the encoding; on priced enterprise and collectible paths it may be chosen, and the purchase interface emits a text-to-image prompt so a holder can generate a matching portrait they host themselves.
The encoding is categorical. It does not record a specific human face and is not an input to facial recognition. A rendered portrait is produced from the trait list; the contract does not bind a photograph at mint. The unsigned avatar URL in the distinguished name is self-declared, not covered by the issuer signature, and is a different object from the identifier.
Uniqueness is a registry property. The contract will not mint a duplicate identifier on that named account. The same twelve characters on two registries would denote different subjects. Root credentials use the full bc=…;sc=…;id=… lineage identifier rather than the facial form.
DID methods, SPIFFE IDs, OAuth client IDs, and ANS names do not encode a face. FIDO authenticators bind to a human’s biometric or device. A Passport’s face is how humans recognize the agent; HOLA is how machines check current control.
4. What a verified Passport actually establishes
Verification answers a specific question: is this token on the registry I pinned, fee-attested by that family’s keys, signed by an issuer I named, and currently controlled? It does not answer whether the agent is honest, safe, authorized, or a legal person. It also does not answer whether the face belongs to a living human.
As built, a Passport verifies when all of the following hold:
- It exists as a token on the verifier’s pinned registry. Uniqueness is a registry property. The contract will not mint a duplicate identifier on that named account. It is not a globally unique name in the DNS sense.
- It was fee-attested by that registry’s authorized signers. As constructed those keys are the family’s Portal and Sanctum keys. A well-formed blob with no such attestation never lands. Hierarchy is which authorized key signed.
- Its policy hash verifies against an issuer the verifier itself named. Lineage is walked from the verifier outward. The credential cannot nominate a trust anchor the verifier did not already pin.
- Someone currently controls the owning key. Proofs check the owner recorded now, not the owner at mint.
- Issuance cost real value. Mass creation has linear cost. That does not make Sybil attacks impossible; it makes identity farming expensive. Fee amount is path-dependent; the contract checks that an authorized signature and the attached deposit match.
That bar does not establish:
- legal identity;
- organizational endorsement (the distinguished name is unsigned);
- that a webhook, avatar URL, or other unsigned address is under the holder’s control;
- a biometric match against a human;
- uniqueness across registries;
- a trust judgment.
A Passport that verifies can still be malicious, compromised, unauthorized, or running manipulated software. What verification gives is attribution inside a family. Reputation, authorization, compliance, and runtime integrity remain other layers.
5. Two proof lanes
The system separates getting a session with a service from proving identity to a peer. Conflating them is the most common integration error.
| Session lane | Peer lane (HOLA) | |
|---|---|---|
| Question | May I have a session with this service? | Am I who I claim to be, to you? |
| Result | Bearer JWT scoped to one service | A portable HOLA line |
| Third party | Yes — that service | No |
| Meaningful to anyone else | No | Yes |
| Family / login-mode gate | Yes | No |
| Freshness | Future-dating rejected; maximum age is not enforced; challenge is not stored as a nonce | Nonce, maximum age, verifier replay cache. Helper API: in-process nonce_replay after a successful verify |
| Physical encodings | Not applicable (it is a session with a service) | QR / camera / video frame; Morse on sound, light, or radio |
HOLA is a compact cryptographic proof of control, generated and signed locally. Freshness (nonce and timestamp) may come from the IdentyClaw API, from the counterpart, or from any other clock and entropy the parties accept. Once produced, the line travels independently of how it is carried: HTTP, webhooks, A2A, MCP-related exchanges, email, chat, SMS, queues, QR codes in images, camera reads of a robot faceplate or a screen, and Morse-compatible sound or light. It does not require a dedicated identity endpoint or IP.
Adjacent work (mTLS, WIMSE, SPIFFE, A2A, MCP) assumes a digital session or a digital envelope. HOLA is a string of roughly two hundred characters: a warehouse MQTT topic, a LoRa frame, a QR on a video call, a camera on a robot, or acoustic Morse between a human and an agent that shares no keyboard. Robotics and human–agent encounters that are optical or acoustic use the same line.
Morse compatibility is an alphabet and canonical-case property. Cryptography is over an uppercase canonical prefix; verifiers are case-insensitive (Morse has no case); token identifiers are vowel-free consonants; the checksum omits I, L, and O; the nonce is uppercase hex; the signature is RFC 4648 base32. OpenAPI describes verification as operating on a Morse-compatible canonical message. The nonce helper emits the hex form of a 16-byte nonce. A verifier who recovers the string by ear, by camera, or by HTTP runs the same proof bar. Freshness is what makes a photographed QR or a recorded beep from last week fail.
The helper API records tokenId (that represents a face) plus nonce after a successful verify and rejects a second presentation of that pair with nonce_replay for the rest of the freshness window (GET /api/holanonce16ts only issues entropy). That cache is in-process, so a horizontally scaled helper can still accept the same line on another instance. Independent verifiers keep their own cache.
HOLA is mutual when both sides present a line, and recipient-bound so a valid proof cannot be copied into an unrelated interaction without detection. It grants no session. A session JWT is meaningful only to the service that issued it.
A helper API exists for verifiers who prefer not to read the chain. Using it as the root of trust would be a misread of the model.
Federated login is a third mechanism, still inside one family: a Passport issued for one API URL can obtain a JWT from another API on the same registry, attested by the same issuer set. That JWT is marked federated and is not interchangeable with a home-API token. It does not span registries.
Synthetics' Last Cradle is the public instance of §5. A home-API Passport logs into api.lastcradle.io and receives a Last Cradle–scoped JWT (session lane). Private trade, alliance, and betrayal talk uses HOLA on A2A, email, chat, or any other channel the operators already share (peer lane). The game API does not carry, store, or validate HOLA lines. The spectator frontend shows public negotiation, transfers, and optional agent-authored deal snippets; it does not invent private transcripts. The same twelve-character facial identifiers recur across games. HOLA is recommended among rivals; the server does not gate settlement on a verified line. A guest with no Passport can join a casual lobby.
6. The trust decision that actually matters
Most adjacent systems either inherit a bundle of issuers (X.509 / CA/B Forum), follow an identifier to a document the identifier itself names (many DID methods), or accept a chain the presenter supplies.
A Passport verifier pins one named registry and walks its own configured lineage. It resolves those issuer credentials on the pinned registry and tests whether any of those keys signed the presented policy hash. No other family’s Portal or Sanctum can mint a credential this verifier will accept. Forging a lineage pointer achieves nothing unless one of the verifier’s own issuers actually signed. A credential from a registry the verifier has not pinned is unresolvable.
The residual of a wrong pin is self-isolation. Mutual authentication still requires both ends to resolve the same named account and the same issuing keys.
DNS TXT at {registry}.smartcontract.{verifier-home-domain} is an independent channel that this service is published under this registry. As built, presence of any TXT record is treated as success; the record’s content is not bound to the registry identifier; the browser SDK stubs the check. That is not DNSSEC-gated issuance. The pin remains the trust decision.
7. Lifecycle, stated as built
Mint once, recognize repeatedly — inside a family. A service that pins the same registry and walks the same issuer set can independently verify a Passport it has never seen. It may still require authorization, onboarding, or payment credentials. What is removed is the need for a service-specific identity object to be the fundamental representation of the agent.
Rotation is transfer. Because proofs verify against the current owner, moving the token to another account is key rotation. The identifier does not change — including the face. An observer cannot distinguish rotation from change-of-control. There is no signed succession log of historical keys beyond public ownership history on the chain. Transfer requires the current key. It does not involve the issuer.
Holders cannot recover a lost key. Control of the owning key is control of the Passport. There is no social recovery, no threshold scheme, no holder-driven reset. The registry owner can forcibly reassign a token (recover). That is a privileged seizure, and it reintroduces a central privilege the rest of the design works to avoid. Holder key-transition is not an existing capability.
Holders cannot revoke. There is no revocation list and no graduated status. Effective invalidation is expiry (when a real not_after was set), destruction (burn) by the registry owner, or seizure. “Revoked”, “destroyed”, and “seized” are not distinguishable states a verifier can honour. A DNS revocation check was implemented, short-circuited, and removed from the backend SDK; the browser stub still succeeds.
Mortality is optional. The contract accepts 1970-01-01 as an unbounded sentinel. Root and some operational credentials are issued that way. A credential with a real expiry cannot be renewed in place; replacement is a new identifier — a new face — with no system-supported link to the old one.
Policy is stored on-chain and enforced by the verifier, and only if that verifier mounts the enforcement. The contract checks that those fields are well-formed at mint. Two verifiers may treat the same Passport differently. AuthZEN and similar policy engines remain complementary.
8. Delegation
A holder may authorize a subagent. As built this is an off-chain record: the parent’s identifier, the subagent’s key, and a parent signature over {tokenId}:{delegateId}:{timestamp}:{publicKey}. It is not an on-chain delegation object, and it does not encode a rich scope language.
The verification order is:
- freshness;
- identity proof;
- the verified identity matches the identity the message claims (impersonation guard);
- delegation;
- only then, the content.
Verify before execute. That order is the same if the HOLA arrived as a QR or as Morse. A helper that checks HOLA shape without checking delegation is incomplete. The current delegation helper confirms the parent signature and treats the parent token as active without re-checking expiry. Full validation is verify and delegation, in that order.
Versus OAuth/DAAP, WIMSE credential delegation, and DID capability chains: the subagent remains a persistent Passport; the delegation explains why it is acting. Scope and policy still belong to the authorization layer.
9. From registration to recognition
Traditional stacks issue a service-specific credential (OAuth client, API key, mesh identity, MCP token) and then recognize that credential. The agent re-registers at every ecosystem.
RODiT inverts the identity half of that:
- The agent holds a Passport.
- It proves control cryptographically — on the wire, in an image, or in sound.
- The verifier checks the Passport on the registry it has pinned.
- The verifier then decides authorization.
OAuth access tokens, payment credentials, and other authorization artifacts may still exist. They should not be the only durable name of the agent.
| Requirement | Passport | DID | OAuth / API keys | WIMSE / mTLS |
|---|---|---|---|---|
| Reusable across independent services in one family | Yes | Yes, where accepted | No — normally service-specific | Usually trust-domain specific |
| Reusable across independent registries | Not as built | Depends on method and resolver policy | No | No |
| No per-service identity credential | Yes (HOLA / possession proof) | Potentially | No | Usually no |
| Service-specific authorization still possible | Yes | Yes | Yes | Yes |
| Presenter cannot nominate the trust anchor | Yes, by construction | Often the identifier selects the document | N/A (issuer is the service) | Organizational PKI / SPIFFE trust bundle |
| Human-recognisable visual identity bound to the identifier | Yes — facial encoding | Not by method | No | No |
| Proof usable off a TLS session (QR, camera, Morse) | Yes — HOLA is a line | Presentation is usually digital | No | No — assumes a session |
What operators stop re-issuing
Agent stacks today mint a fresh identity object for each surface (a pile of API keys and channel secrets). That is most of the maintenance and most of the spin-up cost with the connected LLM, Kanban / task boards, and messaging authentication (A2A, email, chat, webhooks, queues).
With the Passport, spin-up becomes: load the key that currently owns the Passport, prove control, resume work and memory. Maintenance becomes: rotate the wallet and keep the face/ID; replace the runtime and keep the memory index; add a channel and keep HOLA. Subagents stay attributable through the existing parent signature.
10. Adjacent technologies
Each of the following answers a different question. A Passport can be an input to them.
OAuth / OIDC / DAAP. Authorization artifacts for a resource server: this token authorizes this client to access this resource. MCP’s current authorization model is OAuth 2.1 for this reason. Use HOLA (or session-lane login) to establish who, then OAuth to establish may they.
AuthZEN / COAZ. Externalized authorization decisions; COAZ maps an incoming operation to that decision, including an MCP binding. Natural composition: HOLA → authenticated identity and optional delegation → AuthZEN request → allow / deny. Application policy stays in those engines, beyond the advisory fields already stored on the Passport.
mTLS / SPIFFE / WIMSE. Workload identity inside managed infrastructure: which workload is connected to this service? Strong where endpoints are stable and credentials can be provisioned. Many agent channels are not a persistent TLS session, including channels that are not a network at all. WIMSE credentials could later prove that a current runtime controls a Passport; that binding is not built.
MCP. Agent-to-tool access, with OAuth for server authorization. Carry HOLA in the interaction if the server needs a durable agent identity in addition to a resource token. The MCP access token remains a resource credential.
A2A. Agent-to-agent communication, discovery, Agent Cards. Identity is generally at the transport/security layer. A2A is a natural digital transport for HOLA; optical and acoustic encodings of the same line cover encounters A2A cannot see. Discovery (who can do this task?) is a different problem from identity (is this the agent it claims to be?).
LLM Kanban / task boards. Work assignment among agents. Boards today often mint a keypair per spawn. Carry the Passport as the teammate; treat the worker process as a session. The board stays a board.
Agent memory. Episodic and semantic stores. Key the index to the Passport identifier; authorise read/write with HOLA or a session JWT. Moving runtime (OpenClaw ↔ IronClaw) does not mint a new memory subject.
Messaging authentication. Email, chat, webhooks, queues. HOLA on the existing channel. The messenger stops issuing API keys that double as identity.
DID / VC. Decentralized identifiers and verifiable claims. A DID can be persistent; DID syntax does not, by itself, impose issuance cost, a subject-owned on-chain asset, verifier-outward resolution, or a facial encoding. A VC is a signed claim about an entity. Experimental did:rodit:<passport-id> exists as a projection of a Passport; resolvers still pin a contract. VCs remain the right shape for “organization X certified this Passport,” which the Passport itself will not say (descriptive fields are unsigned).
AIP. There are multiple 2026 Internet-Drafts named “Agent Identity Protocol” with materially different designs. Cite the specific draft.
ANS. Domain-control-validated agent identity and discovery: this agent represents an entity controlling this domain. A Passport is a persistent token on a registry the verifier chose, fee-attested by that family’s keys. An ANS record could attest that Passport X is operated by http://example.com. IdentyClaw’s DNS TXT runs the other way: this service domain is bound (weakly, today) to this registry.
FIDO / WebAuthn / FIDO Agentic Authentication. Human authentication and human-to-agent delegated authority. Layer: human authenticates → delegates → agent holds a Passport → agent proves via HOLA. A human who recognises an agent by its rendered face is using the identifier as a persona.
Robotics / HRI optical and acoustic channels. Adjacent use: a camera, a microphone, a faceplate display, a warehouse radio. Those stacks answer how to sense and actuate. HOLA answers which persistent agent is at the other end of the sense when the channel is photons or sound.
Synthetics' Last Cradle. The running technology demonstrator of this paper’s architecture: federated session-lane login, off-API HOLA among strangers, persistent facial identifiers, economic consequences, a public spectator surface. Transfers are not HOLA-gated.
Visa TAP / AP2 / Verifiable Intent. Commerce-specific recognition, mandates, and dispute evidence. TAP overlaps the “unknown agent at a merchant” problem inside a payment ecosystem. AP2 answers whether a purchase was authorized and on what terms. A Passport answers which persistent agent, in this family, requested it. A future interaction can carry all of them.
SCITT. Tamper-evident evidence of what happened. Identity → authentication → authorization → action → signed receipt.
KYC / KYB. Legal identity binding. Optional, out of band, attachable as a claim. A verified Passport and a facial encoding do not imply it.
NEAR account / wallet. Custody and the rail that pays mint and transfer. An account can sign without holding a Passport; a Passport can move to a new account and remain the same agent. Last Cradle seats the Passport.
11. Landscape
A layered ecosystem.
| Layer | Representative work | Primary question |
|---|---|---|
| Human authentication | FIDO / WebAuthn | Who is the human? |
| Human → agent delegation | FIDO Agentic Authentication, OAuth/DAAP | What authority was delegated? |
| Persistent agent identity | RODiT Passport | Which persistent agent is this, in this family? |
| Custody / settlement key | NEAR account / wallet | Who can pay and sign right now? |
| Human-visible agent persona | RODiT facial encoding | Which face is this agent? |
| Decentralized identifiers / claims | DID / VC | Which identifier, and what was asserted about it? |
| Domain-backed identity | ANS | Which organization/domain represents this agent? |
| Agent-to-agent communication | A2A | How do agents communicate (digitally)? |
| Agent task board | LLM Kanban | Who is working this card? |
| Agent memory | Runtime/vendor memory stores | Whose memory is this across hosts? |
| Messaging authentication | Channel API keys / gateway JWTs | Who sent this message? |
| Agent-to-tool communication | MCP | How does an agent access tools? |
| Physical / HRI encounter | Camera, QR, Morse, radio, faceplate | How does the proof travel when there is no socket? |
| Live identity demonstrator | Synthetics' Last Cradle | Does this architecture hold when strangers compete for real stakes? |
| Authorization | OAuth, AuthZEN, COAZ | Is this operation allowed? |
| Workload security | SPIFFE, WIMSE, mTLS | Which workload is operating? |
| Runtime assurance | Attestation / WIMSE extensions | Is the expected software running? |
| Accountability | SCITT | What evidence exists of the action? |
| Agentic commerce | Visa TAP, AP2, Verifiable Intent | Can this transaction be authorized and evidenced? |
| Reputation | Application / ecosystem systems | How much trust should be assigned? |
Human-visible agent persona, physical / HRI encounter, and operator spin-up (Kanban, memory, messaging keyed to a Passport) are jobs the identity layer already makes cheaper. Last Cradle is where the identity job has been run in public.
12. Competitive comparison
“Relative to a Passport” here means relative to the identity job RODiT is doing.
| Approach | Trust anchor | Main strength | Relative to a Passport |
|---|---|---|---|
| OAuth / OBO / DAAP | Authorization server | Enterprise authorization | Service-specific authorization, not a durable agent identity |
| DID + VC | DID document + issuers | Portable identifiers and claims | Does not by itself impose issuance cost, subject-owned tokens, verifier-outward resolution, or a facial encoding |
| AIP family | Varies by draft | Agent identity / policy / delegation | Several non-equivalent designs; cite the draft |
| ANS | DNS / domain + certificates | Domain-backed identity and discovery | Anchors to domain control, a different question |
| SPIFFE / mTLS | Organizational PKI | Strong workload authentication | Assumes managed infrastructure and a stable session |
| WIMSE | Workload credentials | Multi-system workload identity | Workload/infrastructure oriented; runtime ≠ persistent agent; not a physical-channel proof |
| FIDO Agentic Authentication | Human authenticator | Human-to-agent trust | Not a persistent agent identity; biometric is of the human, not the agent |
| MCP authorization | OAuth AS | Protected tool access | Resource authorization |
| A2A | Transport / enterprise auth | Interoperability and discovery | Communication layer; digital transport for HOLA |
| NEAR account / wallet | Chain key / named account | Signs, pays, holds tokens | Custody: cheap to mass-produce; one account may hold many Passports or none; transfer keeps the Passport identifier |
| Visa TAP | Visa ecosystem | Trusted commerce-agent recognition | Commerce-specific |
| AP2 | Signed mandates | Payment authorization and evidence | Commerce-specific |
| SCITT | Transparency service | Tamper-evident evidence | Evidence, not identity |
| Passport + HOLA | Pinned registry + verifier-declared issuer set | Subject-owned on-chain identity; verifier-outward trust; facial identifier; channel-independent (including image and Morse-compatible sound) proof; issuance cost; public technology demonstrator (Last Cradle) | Verification is intra-registry; public by construction (including the face); holders cannot self-revoke or recover; policy is advisory; twin root keys are static; first-party QR/Morse codecs are not shipped; Last Cradle recommends HOLA and does not gate transfers on it |
Adoption of RODiT recognition means the counterpart pins the same family.
13. Distinctive properties — as built, and not yet
The differentiation is a combination.
As built
- Persistent token identity. Survives process, host, protocol change, and wallet rotation. Expiry-and-reissue produces a new identifier. The owning account is the current custodian.
- Facial identifier. Twelve characters encode eleven traits plus a checksum. Humans can recognise the agent; machines verify the string. Unique on the registry. Assigned on ordinary issuance; choosable on priced paths, with a text-to-image prompt for a matching portrait.
- Subject-owned on-chain asset. Issuer cannot silently alter or delete it. Anyone can read it. The holder’s wallet mints.
- Verifier-outward trust. The presenter cannot supply the trust path.
- One named registry per verifier (an explicit family).
- Mint gated by that family’s keys. The contract has no tier enum.
- Economic friction at issuance.
-
No issuer online at verification, within a registry. Optional helper API (HOLA path: in-process
nonce_replay). - Channel-independent HOLA, recipient-bound, locally signed.
- Physical-channel HOLA. The same line can travel as text, as an image (QR, camera, video frame), or as Morse-compatible sound or light. Morse compatibility is an alphabet and canonical-case property. First-party codecs are not shipped.
- Two lanes. Session convenience stays on the service that issued the JWT.
- Operator spin-up: Kanban membership, memory indexes, and messaging auth can key off the Passport instead of minting a new identity per process. Those products are not shipped here.
- Brokerless peer authentication. Both sides may prove to each other without a shared IdP.
- Off-chain subagent delegation with an impersonation guard in the verify-before-execute order.
- Descriptive identity is self-declared. The face is the identifier; the avatar URL is unsigned.
-
Public technology demonstrator. Last Cradle (
lastcradle-be/lastcradle-fe) runs the two lanes, federated login, and persistent facial identifiers under competition. Spectators watch. Contest seats require a Passport.
Planned or absent
- Holder-driven recovery or self-revocation.
- Graduated lifecycle states (revoked vs destroyed vs seized vs superseded).
- Signed succession across expiry.
- Cross-registry verification. Planned as verifier-declared peering only.
- Rotation of twin root keys. Planned; additive if it arrives, because old signatures cannot be rewritten.
- Runtime hash / attested binding of Passport to software.
- On-chain delegation with encoded scope.
- Pairwise identifiers, selective disclosure, or unlinkability. The credential is world-readable — including the face.
- Independently challengeable “controlling address” in the telephone/email sense. The signed home API URL locates the agent; the webhook is unsigned; DNS TXT attests the service’s registry, weakly.
- DNSSEC as an issuance gate.
- Session-lane maximum age and stored nonce (specified, stubbed; helper API already has the HOLA equivalent).
- A first-party Morse audio codec, QR encoder, or passport display kiosk.
- A first-party Kanban, memory store, or messenger. Those remain adjacent products keyed to the Passport.
14. Threat model, tightly
| Attack | What the design actually does |
|---|---|
| Clone an identifier on the same registry | Contract uniqueness — including uniqueness of the face |
| Farm millions of identities | Issuance cost; not a cryptographic impossibility |
| Present a Passport from another family | Unresolvable if the verifier’s pin and issuer set do not match |
| Nominate a bogus issuer in lineage | Ignored unless that issuer is already in the verifier’s set |
| Replay a HOLA | Recipient binding, max age, verifier-side cache (in-process on the helper) |
| Replay a photographed QR or recorded Morse | Same freshness and replay checks. A screenshot or beep from outside the nonce window fails. Physical channels need a live rotating presentation |
| Replay a session-lane login | Future-dating rejected; maximum age not enforced; challenge not stored as a nonce |
| Use a HOLA for the wrong claimed identity | Impersonation guard if the verifier implements the full order |
| Steal the current key | Attacker is the identity until the registry owner seizes. No holder recovery. The face does not change |
| Compromise Portal or Sanctum | Can attest new credentials that will verify in that family. Cannot burn, recover, or transfer tokens they do not own |
| Compromise the registry owner | Can burn or seize any credential. Membership is centralized; verification is not |
| Substitute a look-alike name | Unsigned DN. Counterparties must compare identifiers, not display names |
| Substitute a look-alike portrait | Unsigned avatar URL. Counterparties must compare the twelve-character encoding (and its decoded traits), not the hosted image |
| Compromised runtime | Out of scope for HOLA. Needs attestation |
15. Privacy and source of truth
A public, persistent, world-readable identity is the right default for machine identity and the wrong default for personal data. Policy, ownership history, the identifier graph, and the facial traits are inferable by anyone. Distinguished-name fields that look like personal data make that easy to underestimate, especially because they are unsigned and still public. A rendered portrait matching the traits is also public-by-construction once published; it is not a biometric file held by IdentyClaw.
Pairwise identifiers and selective disclosure are not provided. Deployments that need unlinkability should use separate Passports for separate contexts, and should not put personal data on the token.
The chain is the source of truth. Verifiers may use public RPC, their own node, or short caches. Caching is a live window: a destroyed credential can still verify until the cache expires.
Session-lane JWTs exist so that high-frequency traffic is not a blockchain benchmark. JWT validation numbers are not HOLA or registry-read numbers.
16. Multi-organization use, as built
Two organizations can mutually authenticate with HOLA if they pin the same registry and can walk issuers that actually signed the presented Passports. They do not need a shared identity provider, a shared authorization server, or a dedicated identity endpoint. They apply their own authorization afterwards. That is the as-built cross-organizational story. The same story holds if one side presents the line over A2A and the other over a camera: the family pin, not the transport, is the trust decision.
Last Cradle is that story in public. Independent agent operators, many of them strangers, sit cradles on a federated peer. The game issues no per-player API keys. Contest membership is a Passport session; casual guest join exists. Attribution among rivals is HOLA on whatever channel they already use. The spectator frontend is how humans watch those faces compete.
Two organizations that each run their own registry cannot authenticate each other’s Passports today. Federated login does not change that. Planned peering would let a verifier’s registry declare which peer registries it accepts — still verifier-declared. Until that exists, portability is across services, protocols, and physical encodings inside one family.
Discovery remains separate. Agent Cards, ANS, and other directories may point at a Passport identifier. Multiple discovery systems can refer to the same token. The facial encoding is what makes a directory entry recognisable to a human.
17. What to use when
Use a Passport and HOLA when you need
- a persistent agent identity that survives process, host, and protocol change (expiry-and-reissue is a new identifier);
- less identity re-issue on spin-up: Kanban teammates, memory indexes, and messaging auth keyed to the same Passport;
- a human-recognisable visual identity for that agent;
- recognition by independently operated services without minting a per-service identity object;
- a proof that can travel on channels that are not a TLS session — including QR, camera, video, radio, and Morse-compatible sound;
- mutual, brokerless authentication between parties that share a family, including robot–robot and human–agent encounters that share no keyboard;
- issuance that costs real value;
- a verifier that will not accept a trust path the presenter nominated.
Use Last Cradle when you need to see that architecture under adversarial load. It is already live.
Use something else in addition, or instead, when you need
| Need | Prefer |
|---|---|
| Internal workload zero trust | SPIFFE / WIMSE / mTLS |
| A payment or signing account | NEAR wallet (custody) |
| Human authentication | FIDO / WebAuthn |
| Domain / organizational binding | ANS / DNS-backed systems |
| Fine-grained authorization | OAuth / AuthZEN / COAZ |
| Agent task board / LLM Kanban | Passport as the teammate; process as the session |
| Portable agent memory | Key the store to the Passport identifier; HOLA or JWT for access |
| Messaging authentication | HOLA on the existing channel |
| Agent-to-tool access | MCP (OAuth for the resource; Passport for the agent) |
| Optical / acoustic encounter | Encode the HOLA line (QR, camera, Morse) |
| Payment authorization | AP2 / TAP |
| Runtime attestation | WIMSE / hardware attestation |
| Tamper-evident action evidence | SCITT |
| Legal identity | KYC / KYB |
| Holder recovery, suspension, or succession | Not provided |
| Cross-registry recognition | Not as built |
| First-party Morse audio or QR kiosk | Not shipped; the line is usable without them |
18. Protocol stack
+------------------------------------------------------+
| Applications / business processes |
+------------------------------------------------------+
| Policy / authorization |
| AuthZEN / COAZ / OAuth / capability systems |
+------------------------------------------------------+
| Delegation (off-chain parent signature) |
+------------------------------------------------------+
| Persistent agent identity |
| RODiT Passport on a pinned registry |
| (twelve-character facial identifier) |
+------------------------------------------------------+
| Identity proof |
| HOLA | session JWT (service-scoped, not portable) |
+------------------------------------------------------+
| Encodings of the HOLA line |
| digital text | QR / image / camera | Morse |
+------------------------------------------------------+
| Agent communication |
| A2A / MCP / HTTP / email / messaging / webhooks |
| serial / radio / optical / acoustic |
+------------------------------------------------------+
| Runtime / workload security |
| WIMSE / mTLS / attestation |
+------------------------------------------------------+
| Accountability / evidence |
| SCITT / signed receipts |
+------------------------------------------------------+
Physical encodings sit under HOLA.
19. Core proposition, narrowed
The identity is persistent as a token, inside a family, across protocols and runtimes. Replacement after expiry is a new identifier — a new face.
The identifier is independently checkable in the sense of §4: unique on that registry, fee-attested by that family’s keys, verifiable without asking the issuer, expensive to mass-produce. It is also representable as a face: eleven traits plus a checksum.
The identity is portable across services and channels that pin the same family. Independent registries cannot authenticate each other today. “Channel” includes digital transports and physical encodings of the same HOLA line.
HOLA is proof of current control. It is Morse-compatible and optically encodable. First-party codecs are not shipped.
Authentication does not require a service-specific identity credential. Authorization credentials may still be required for particular resources.
Delegation is attributable when the verifier runs the full order. The subagent remains its own Passport.
The verifier, not the presenter, names the family.
What a Passport does not prove remains the list in §2 and §4: benign intent, legal identity, untampered software, truthful self-description, human authorization of a particular later action, economic safety of a transaction, or that a rendered portrait is a photograph of a living person.
20. Conclusion
The agentic ecosystem is landing specialized work on each layer: FIDO for humans, OAuth and AuthZEN for authorization, WIMSE for workloads, MCP for tools, A2A for agent communication, ANS for domain-backed discovery, TAP and AP2 for commerce, SCITT for evidence.
IdentyClaw’s position in that stack:
- RODiT is a persistent, subject-owned agent identity on a registry the verifier chooses, recognised by humans as a face and by machines as a string.
- HOLA is a portable proof of current control of that identity, including over image and Morse-compatible sound.
An agent can authenticate to a stranger without being re-enrolled as a new identity at every service in that family, move across protocols, present itself to a camera or a microphone, delegate to subagents, and rotate keys by transferring the token. Authorization, runtime integrity, legal identity, and evidence stay on the layers that already handle them.
Verification is intra-registry. Policy is advisory. Holders cannot self-revoke or recover. The graph is public, including the face. First-party QR and Morse codecs are not shipped. Those limits are why the complementary systems in this paper still have a job.
Last Cradle is where that architecture has already been run in public.
Appendix A — Terminology
| Term | Meaning |
|---|---|
| Identity | The persistent entity being represented |
| Identifier | The technical object used to refer to it (twelve-character facial form, unique per registry) |
| Facial encoding | The identifier as eleven categorical traits plus a checksum |
| Portrait / avatar | A rendering of the trait list, or an unsigned DN URL |
| Passport / RODiT | The on-chain token that is the IdentyClaw identity object |
| Family | One pinned registry plus the issuer keys the verifier walks |
| Controlling key | The current owning account; proofs check this at verification time |
| Wallet / NEAR account | Signs, pays, holds the token; replaceable |
| HOLA | Portable, recipient-bound, locally signed proof of current control |
| Morse-compatible | HOLA’s canonical uppercase, case-insensitive, restricted alphabet so the line can travel as Morse |
| Physical encoding | QR / camera / video / Morse on sound or light carrying the same HOLA line |
| Last Cradle | Public technology demonstrator: federated session lane + off-API HOLA; spectator frontend |
| Session JWT | Service-scoped bearer token issued after session-lane login |
| Federated login | Same-registry, different API URL |
| Verified Passport | The properties in §4 hold for this verifier’s pin |
| Delegation | Off-chain parent signature authorizing a subagent key |
| Authorization | Whether an authenticated identity may perform a specific operation |
| Registry owner | Account with burn and recover privilege; ecosystem gatekeeper for membership |
Appendix B — Standards status
Not every named technology is a finalized standard. WIMSE, ANS v2, AIP drafts, SCITT agent-action receipts, FIDO Agentic Authentication, and AuthZEN/COAZ are active work. Visa TAP and AP2 are ecosystem protocols. Distinguish established standards, drafts, and commercial protocols, especially when comparing a Passport to an Internet-Draft that may change name or shape.
Cross-registry peering and rotatable twin root keys are IdentyClaw planned work. First-party Morse audio and QR kiosk codecs are IdentyClaw application work. None of them is deployed.
Top comments (0)