This document describes how the IdentyClaw Passport system actually works: the problem it addresses, the design decisions that still shape the running system, the trust model those decisions produce in code, the lifecycle a Passport follows today, and an assessment of where that architecture is strong and where it is exposed.
It is not a line-by-line implementation audit. Hosts, ports, versions, and source paths are omitted because they change per environment and per release and they obscure the reasoning. Mechanisms, field names, and trust consequences are not omitted. Where a running behaviour diverges from the model the rest of the system still assumes, that divergence is stated in place rather than parked in an appendix.
Design intent is cited only where it still governs what was built, or where a stated direction exists and has not been built yet.
Scope. Eight identity components: the NEAR smart contract that acts as registry; the SDK that both issues and verifies; two signing services (Portal and Sanctum); three operator/purchase interfaces (root, server, client); and the IdentyClaw API that brokers client issuance and assists verification. A ninth, separate system is cited where it proves those mechanisms in public: Synthetics' Last Cradle, the live technology demonstrator (lastcradle-be / lastcradle-fe, public surfaces lastcradle.io and api.lastcradle.io). It is a federated peer that consumes Passports.
Machines and autonomous agents need to prove identity to parties they have no prior relationship with, over channels nobody controls, without a central authority mediating every interaction.
Conventional answers fit poorly. X.509 assumes a CA hierarchy and a revocation infrastructure that must be online and trusted. API keys are bearer secrets with no verifiable provenance and no policy attached. OAuth assumes a common identity provider both sides accept. All three require the verifier to trust an intermediary at the moment of verification.
The Passport design takes a different position: the credential itself is a publicly readable, independently verifiable object, and the subject owns it. Anyone can read it, nobody can alter it, and proving control of it requires no cooperation from its issuer.
Nine decisions do most of the architectural work. Each is stated as it is built, then the consequence that follows — including the costs, and including the places where the running system is softer than the decision sounds.
A Passport is a token on a specific blockchain contract, owned by the subject's own account. It is not a record in a vendor's database, and not a signed blob the subject merely holds a copy of. After mint, metadata is never rewritten; the only mutable facts are owner and existence.
Consequence. The issuer cannot silently alter or delete it, the subject can prove ownership without the issuer's participation, and any party can read it without asking permission. The cost is that the credential's existence, policy, and ownership history are public — which suits machine identity, and would not suit personal data. Transfer of the token to another account is also the only key-rotation mechanism (§4).
The identity object is the token. The owning NEAR account signs, pays, and holds it; one account may hold many Passports or none, and accounts are cheap to create in bulk. Transfer replaces the owning account and keeps the identifier, so custody can change without renaming the entity. Proofs check the owner recorded now. Last Cradle seats a Passport.
Policy — validity window, rate limits, permitted routes, network and geographic constraints — is stored on-chain. The contract validates that those fields are well-formed at issuance (dates, URLs, CIDR, JSON, identifier format, DN shape) and then treats their meaning as opaque. It also checks a fee attestation from its authorized-signer set and that the attached deposit matches the attested fee. Enforcement of the policy itself is the verifier's job, and only happens if that verifier actually runs the SDK middleware that consumes the claims.
Consequence. Verification is a read, not a transaction: no gas, no chain write in the authentication path. This is what makes the system usable at API request rates. The cost is that policy is advisory — it binds only verifiers who choose to implement it, and only as correctly as they implement it. See §7.2. Issuance is a different gate: the contract requires a fee attestation from the authorized Portal/Sanctum keys. It does not, and need not, encode tiers. See §6.
A presented Passport names its issuing lineage in serviceprovider_id. A verifier does not follow that pointer to discover keys. Instead it splits its own configured lineage, resolves each id= component on the registry it has pinned, derives the corresponding public key from that credential's owning account, and tests whether any of those keys signed the presented credential's policy hash.
Consequence. A credential cannot nominate its own trust anchor. Forging a lineage claim achieves nothing unless one of the verifier's own issuers actually signed the policy. This inverts the usual certificate-chain vulnerability, where an attacker supplies both the leaf and the path to a root. It is the single strongest property in the design. It is also why a credential from a different registry is not rejected on policy grounds — it is unresolvable (§5.3, §8.1).
Each descent is supposed to issue only a subset of the authority the issuer holds. As built, attenuation is path-dependent.
On the public client path, the IdentyClaw API is the broker: it prices the request, copies several policy fields from its own credential onto the child (home API URL, CIDR, JWT duration, not_before), refuses routes the broker itself does not have, and refuses privileged operations. It does not uniformly refuse a broader validity window or a higher rate limit than it holds. The signing service then attests whatever the broker forwarded, after rewriting lineage.
On the server path, Sanctum attests values the operator interface submitted. Membership is enforced because Sanctum login itself requires an existing Passport; the contract does not. On the root path there is no parent to attenuate against — the ceremony creates the parent.
Consequence. Authority usually decreases down the chain, so compromising a leaf yields no more than that leaf was granted. The guarantee is only as good as the issuing path's discipline, and the paths are not equivalent. Compromising a signing service yields the ability to attest — bounded by whatever that service actually checks — plus the ability to produce a valid fee attestation for a specific token identifier. It still cannot mint without a wallet that pays the fee, and it cannot spend, burn, or transfer existing credentials. See §3 and §6.
The issuer's serviceprovider_signature covers a canonical hash of the fields that constrain behaviour and locate the credential: identifier, validity window, rate limits, CIDR and geo constraints, JWT duration, permitted routes, lineage, OpenAPI URL, and the subject's home API URL. It deliberately excludes the distinguished name and the webhook callback URL.
Canonicalization is bit-for-bit: keys ordered, values typed as the signer typed them, hashed, then Ed25519. Independent implementations that diverge here fail loudly. Independent implementations that diverge in enforcement fail quietly (§7.2).
Consequence. Holders get latitude over cosmetic and operational fields without invalidating the issuer's attestation. The cost is direct: descriptive identity carries no issuer endorsement at all. Cryptography binds a key to an identifier, never to a name, a brand, or an organization. §5.5 develops this. A second, smaller cost: unsigned fields can change nothing on-chain (metadata is immutable), but a verifier that trusts userselected_dn or webhook_url because "the Passport verified" is trusting something the signature never covered.
Passports can expire. Metadata cannot be renewed or extended in place. Continuing past a real not_after means issuing a new Passport with a new identifier.
The contract also accepts 1970-01-01 as an unbounded sentinel on both not_before and not_after. Verifiers treat that sentinel as "no bound". Root and some operational credentials are issued that way. Mortality is therefore a policy choice, not a structural invariant.
Consequence. When a real expiry is set, no stale credential accumulates indefinitely, and an immutable credential means a signature that was valid once stays valid without re-attestation. When the sentinel is used, the credential lives until it is destroyed. In either case, identity continuity across replacement is not a system feature — it becomes the holder's problem, solved out-of-band. §7.3.
The system separates getting a session with a service from proving identity to a peer.
| Session lane | Peer lane | |
|---|---|---|
| Question answered | "May I have a session with this service?" | "Am I who I claim to be, to you?" |
| Result | A bearer JWT scoped to one service, carrying policy as claims | A portable HOLA line |
| Requires a third party | Yes — that service | No |
| Meaningful to anyone else | No | Yes |
| Family / login-mode gate | Yes | No |
| Freshness | Challenge timestamp, future-dated signatures rejected; maximum age is not enforced | Nonce plus timestamp, maximum age enforced, replay cache on the verifier |
Consequence. Each lane can be optimized for its job: sessions are cheap and stateful, peer proofs are self-contained and channel-agnostic. Conflating them is the most common integration error, and the failure is silent — a session token proves nothing to a third party, and a HOLA line grants no session. The peer lane is not brokered. A helper API exists; the verifier may decline it and read the chain directly. The peer lane is a line of text, which is what makes physical encodings possible (§2.9). The same split is what lets a task board, a memory store, or a messenger treat the Passport as the actor and the process as replaceable. Those products are not identity issuers in this model.
A related but different mechanism lives inside the session lane: federated login. A Passport issued for one API URL can obtain a JWT from another API in the same family, on the same registry, attested by the same issuer set. The JWT is marked as federated and is not interchangeable with a home-API token. This is not cross-registry federation (§5.3, §8.1).
The public technology demonstrator of that split is Synthetics' Last Cradle. Agents mint a Passport once, obtain a Last Cradle JWT by federated login, and play /api/game/* under that session. Private deals use HOLA on side channels the game API does not carry, store, or verify. Contest seats require a Passport; the spectator frontend shows public negotiation and settlement without faking private HOLA transcripts. The same twelve-character identifiers recur across games. That is mint-once, two-lane recognition under economic pressure — as built, not as a slide. What Last Cradle does not do is enforce HOLA: the server recommends verify-before-execute; rivals who skip it can still settle a transfer. The identity story is in the architecture of the game, not in a server-side HOLA gate.
Descendant Passports identify themselves with a twelve-character string. That string is not an opaque nickname. Positions 0–10 encode indices into eleven closed facial-trait categories (overall structure, face shape, age band, regional bone structure, lips, hair colour, eyebrows, eyes, skin conditions, skin tone, nose). Position 11 is a checksum over those indices. Even and odd positions use different consonant-only charsets, so adjacent letters never repeat from the same set and vowels never appear. Decode is deterministic: the same identifier always yields the same trait list, and a valid trait list maps back to the same identifier. The contract rejects a mint whose identifier is not in this form. The public agent directory returns the decoded face next to each tokenId. After authentication, the holder’s own identity endpoint returns the same categories plus checksumValid.
The encoding is categorical, not a biometric and not an input to facial recognition: it does not record a photograph of a living person. Privacy policy and the purchase UI both state this. The unsigned AvatarURL in the distinguished name is a self-declared image. A rendered portrait that matches the traits is produced from the encoding; the contract does not store it. Ordinary issuance assigns a random valid encoding. Priced enterprise and collectible paths let the purchaser choose the traits; the purchase interface emits a text-to-image prompt so a holder can generate a matching portrait they themselves host.
Consequence. Humans can recognise an agent by sight — a trait list, or a portrait generated from that list — while machines verify the same object as a twelve-character string. Look-alike names remain possible because the distinguished name is unsigned (§2.5, §5.5). Look-alike faces on the same registry cannot mint: uniqueness is a contract property of the identifier. The face is world-readable and correlated with the identity graph (§2.1). The same twelve characters on two registries still denote different subjects (§8.1). Root credentials use the full bc=…;sc=…;id=… lineage identifier rather than this form.
A HOLA proof is a compact slash-separated string. Cryptography is computed over an uppercase canonical prefix from HOLA/ through API.IDENTYCLAW.COM/. Verifiers normalise letter casing on input, so transmission is case-insensitive. The remaining alphabet is chosen for lossy physical channels: token identifiers are vowel-free consonants; the checksum omits I, L, and O; the nonce is uppercase hex; the signature is RFC 4648 base32 (A–Z and 2–7). Morse has no case and cannot distinguish homoglyphs; those constraints are what “Morse-compatible” means in the protocol. OpenAPI describes verification as operating on a Morse-compatible canonical message. The nonce helper is named for Morse; as built it emits the 32-character uppercase hex form of a 16-byte nonce, which is the Morse-encodable encoding of that nonce, not a dit-dah renderer.
Consequence. Any channel that can carry a short string can carry a proof of current control — HTTP, email, chat, MQTT, serial, radio, a QR code in an image, a camera reading a robot faceplate or a screen on a video call, or acoustic Morse. Robotics and human–agent encounters that are optical or acoustic use the same line. There is no dedicated identity endpoint and no requirement for IP. Freshness (nonce and maximum age) is what makes a photographed QR or a recorded beep from last week fail.
A first-party Morse audio codec, a QR encoder in the API, and a passport display kiosk that rotates a live HOLA as a scannable image are not shipped. They would be encodings of the existing line. A verifier who recovers the string by ear, by camera, or by HTTP runs the same proof bar.
| Component | As-built responsibility |
|---|---|
| Smart contract | Registry and source of truth. Holds credentials, validates field shape at mint, verifies a fee attestation against its authorized-signer set, collects the attested deposit, provides public reads, transfers, owner-only burn, and owner-only recover (forced reassignment). Has no notion of root/server/client, and no policy semantics. |
| SDK | The reference implementation of both sides: issuing-time helpers and, more importantly, the verification pipeline, session JWT, permission middleware, and optional rate-limit enforcement. Its correctness is the security of every verifier that uses it. The browser build omits DNS-based checks and must not be treated as authoritative. |
| Portal signing service | Attests client-tier credentials. Hosts the root ceremony endpoint, which is compiled in but mounted only when explicitly enabled, and when mounted is unauthenticated. Produces both the policy signature and the fee signature. Does not submit chain transactions. |
| Sanctum signing service | Attests server-tier credentials. Login to it is itself a Passport session, which is what enforces "you already hold a credential" before a server credential can be attested. Does not host the root ceremony. Does not submit chain transactions. |
| Root operator interface | Human-operated ceremony client. Asks Portal to generate the twin identifiers and attest the Sanctum half; attests the Portal half locally with a Sanctum key the operator supplies to that client; then submits a batched mint from the ceremony wallet. |
| Server operator interface | Human-operated issuance for the server tier. The operator's wallet pays and submits; Sanctum only attests. The form does not attenuate: operator-supplied routes, CIDRs, and lifetimes go through as submitted. Operators who hold no Passport cannot complete login and therefore cannot mint. |
| Purchase interface | Public self-service issuance for the client tier. Talks to the IdentyClaw API, not to Portal directly. Ordinary purchases receive an assigned facial identifier; priced enterprise/collectible paths let the purchaser select the eleven facial traits (§2.8) and copy a text-to-image prompt for a matching portrait. |
| IdentyClaw API | Two distinct jobs: policy broker at client issuance (pricing, route gating, privileged-operation denial), and optional verification convenience for peers who prefer not to read the chain themselves. Also the session-lane login service, HOLA helper, and subagent-delegation helper. |
| Last Cradle (demonstrator) | Federated peer, not an identity component. Backend: Passport login, game JWT, public roster of roditId s, settlement. Frontend: spectator arena, enroll, prizes. HOLA stays off-API. Proves the two lanes, federated login, and persistent facial identifiers under competition. |
Two structural points matter more than the table.
Signing services never submit transactions. They return two attestations — a policy signature over the canonical hash, and a fee signature over fee, fee-account, and token identifier. The contract accepts a mint only if that fee signature verifies against its authorized-signer set. As constructed, those keys are the Portal and Sanctum keys. A well-formed Passport with no such attestation will not mint. The fee signature does not cover policy fields, and the named owner need not be the transaction signer. All three mint interfaces collect owneraccount_id as a form field; the connected wallet is the payer and submitter, and those two accounts often differ. In the intended flows a wallet still submits, so no signing service needs chain funds or contract authority. Compromising one yields the ability to attest and to authorize a mint of a specific identifier at a specific fee. It does not yield the ability to burn, recover, the registry, or transfer a credential the attacker does not already own. On the client path the fee signature is not bound to the intended owner, so the attestation is a capability to mint that identifier; the first valid wallet to submit wins.
Tiering is a convention, not a contract enum. The contract sees a flat set of credentials. Root, server, and client are distinguished by which authorized key attested them and by which lineage verifiers walk. A separate, unrelated "tier" appears on the purchase path — personal / enterprise / collectible — and exists only to price client issuance. Keeping the contract free of hierarchy is what lets the same registry hold every layer; the gate is the authorized-signer set, not a type field. See §6.
Naming implies a security boundary between Portal and Sanctum. As built they are sibling services of similar shape: same SDK, similar custody, similar exposure. The real privilege difference is which key each holds and who is allowed to call them (Portal's client-attest path is authenticated; its root path, when enabled, is not; Sanctum's server-attest path requires an existing Passport session). Either the operational boundary should be made substantially different, or the vocabulary should stop implying that it already is.
Once per deployment, a paired root of trust is created: two credentials whose lineage references each other, so neither is self-signed in isolation and either can serve as an entry point when a verifier walks outward. One token is the Portal root, the other the Sanctum root. Each serviceprovider_id lists both identifiers, in opposite order. Token identifiers at this tier use the full bc=…;sc=…;id=… form, not the twelve-character facial form used for descendants.
The ceremony is hosted by Portal, not Sanctum. The disable flag is on Portal, not on the ceremony UI; the UI always calls the endpoint and fails if it is off. When enabled, the endpoint does not require a Passport session. Portal generates both identifiers and attests only the Sanctum twin (policy and fee) under Portal's configured key, which must already be an authorized signer on the registry. The ceremony client attests the Portal twin locally with a Sanctum key the operator supplies to that client — as built, pasted into the browser — then submits a batched mint of both tokens. The named owner is typically the Sanctum implicit account from the form; the connected wallet pays. Custody is then transferred to the two service accounts. No new keypair is generated in the ceremony: it reuses the keys already in the Portal store and the key the operator pasted. There is no threshold, no split custody, and no rotation of those keys. Exposure is determined entirely by how the ceremony is conducted. Rotation is planned, not built (§8.2).
Each descent reverses the id= component order in lineage so the chain remains walkable from any tier, and each descent is expected to narrow authority.
Server credentials are attested by Sanctum to operators who can already log in with a Passport. Client credentials are issued through the public purchase path: the API brokers attenuation and pricing, Portal attests, the purchaser's wallet mints. The API generates the twelve-character identifier for ordinary purchases; named identifiers are accepted only on the priced enterprise/collectible paths.
The credential lives on-chain; what the holder must protect is the key of the owning account. Control of that key is control of the Passport: there is no separate recovery secret and no holder-driven account-recovery flow. A new wallet plus rodit_transfer is rotation; the twelve-character identifier does not change. The registry owner can forcibly reassign a token (recover). That operation is privileged seizure. Intended custody ranges from an operator's local key store to a managed secret store for services.
Two lanes, per §2.7.
In the session lane, a holder proves key possession against current chain state using a login challenge pair (Unix timestamp and its ISO form). The service checks: the Passport exists on the pinned registry; the signature verifies against the current owner; lineage resolves to one of the verifier's own issuers (verify_rodit_isamatch); the credential is within its validity window (or unbounded); the registry is DNS-attested against the verifier's own home URL; and login-mode policy accepts the relationship. On success it issues a time-bounded EdDSA JWT carrying policy as claims so the service need not re-read the chain per request. Permission and rate-limit middleware then consume those claims — if the service mounted them.
The login challenge is documented as single-use. As built, the timestamp endpoint returns wall-clock time and does not record challenges, and the signature check rejects future-dating but does not enforce maximum age. A previously valid login signature therefore remains replayable. The helper API's HOLA path records used nonces and rejects nonce_replay (§7.5).
In the peer lane, a holder constructs a HOLA line addressed to a specific recipient (or to a broadcast recipient), with a fresh nonce and timestamp, and sends it over whatever channel the parties already share. “Channel” is not restricted to digital transports. The same line can be pasted into HTTP or chat, encoded as a QR in a still or a video frame, or tapped as Morse on sound, light, or radio (§2.9). The recipient recovers the string and verifies it — against the chain directly, or via the helper API. The helper applies a maximum age, a recipient check, and an in-process nonce replay cache (nonce_replay). The peer lane does not consult login mode. Optical or acoustic recovery uses the same proof bar.
Last Cradle is the public deployment of this split: session lane on the game API, peer lane off-API among rivals, facial identifiers on the spectator surface.
A credential holder may authorize a subagent. The wire form carries the subagent's key, the parent's identifier, and a parent signature over {tokenId}:{delegateId}:{timestamp}:{publicKey}. The as-built verification order is normative and matters: establish freshness, verify the identity proof, confirm the verified identity matches the identity the message claims, check delegation, and only then act on the content. That third step is the impersonation guard. A collaboration envelope that carries a technically valid HOLA for one Passport while asserting it comes from another must fail here.
The governing principle is verify before execute — never act on content whose provenance you have not yet established. The test helper that checks HOLA shape without checking delegation is not this bar. Neither is the delegation helper on its own: it confirms the parent signature and currently treats the parent token as active without re-checking expiry. Full validation is verify and delegation, in that order.
Because proofs verify against the current owner, transferring a credential to a different account is also the key-rotation mechanism. Rotation and change-of-control are the same operation, which is economical but means they cannot be distinguished by an observer. The Passport identifier does not change. There is no platform-mandated schedule and no issuer involvement.
The twelve-character facial identifier persists across that transfer. Subsequent HOLA and session-lane proofs verify against whoever owns the token now. Minting to an account assigns custody of an already-specified identity object.
Three as-built paths: expiry, which is passive and automatic when a real not_after was set; destruction (burn) by the registry's owner, which is active and privileged; and seizure (recover) by the registry's owner, which reassigns rather than ends the identity. There is no holder-driven revocation, no graduated status, and no renewal. A DNS TXT revocation check existed in the backend SDK, was short-circuited, and has been removed. The browser SDK still stubs the same check as always-true. Effective revocation today is destruction or seizure, plus whatever a verifier chooses to infer from expiry.
Four anchors, in decreasing order of strength:
{registry-name-without-suffix}.smartcontract.{domain-of-the-verifier's-home-URL}. Presence of any TXT record is treated as success; the record's content is not bound to the registry identifier. Browser verifiers skip this check and return success.
Issuance and acceptance are governed by different mechanisms: the registry's authorized-signer set gates who may fee-attest a mint, while these four anchors gate who may be believed. Conflating them leads to the incorrect assumption that being issuable implies being trusted.
There is no certificate. Lineage is a structured pointer of the form bc=…;sc=…;id=…;id=… naming the blockchain, the registry, and the credentials in the chain — plus a signature by the issuing tier over a canonical hash of the credential's policy fields.
The verifier splits its own lineage into components, resolves each bc=…;sc=…;id=… to an on-chain credential on the pinned registry (the sc= in the string is used to compose the lookup key, not to select which registry is queried), derives the corresponding public key from that credential's owning account, and tests the presented credential's signature against those keys. Determinism is essential: canonicalization must be reproducible bit-for-bit across independent implementations, or every signature fails.
The configured registry is not compared with the signed sc= in a locally stored copy of the verifier's own credential. Fetching that credential from the pin and then comparing sc= to the pin is tautological. See §6.
Three distinctions that login actually uses:
Family means: same pinned registry, and a lineage signature that verifies against one of the verifier's own issuer keys. Without family, session-lane login fails resolution (RODIT_FAMILY_MISMATCH), not policy.
Partner vs peer (session lane only). After a signature verifies against one of the verifier's issuer keys, the SDK classifies the relationship by whether the presented credential's lineage lists that same issuer id:
LOGIN_MODE then filters: partner (the default) accepts PARTNER only; p2p accepts PEER only; promiscuous accepts both. Some comments and some operator-facing documents invert these two words. The runtime classification and the mode names above are the ones login actually uses. HOLA does not consult this gate.
Federated login is a third thing, still inside one family. A client whose home API URL differs from the service it is logging into can obtain a JWT from that service. The JWT carries the service's URL in a dedicated claim so the client can detect a substituted endpoint. Federated JWTs are not valid at the home API, and home JWTs are not valid at the federated peer. The test scaffold exercises this path. Last Cradle is the public instance: a home-API Passport logs into api.lastcradle.io, receives a Last Cradle–scoped JWT, and cannot spend that JWT at the home API. It does not create a trust path between registries.
The consequence worth stating plainly: partner mode is not cross-registry federation, and neither is federated login. Both distinguish organizations or APIs within a shared registry and a shared issuer set. There is no verification path between two registries at all (§8.1). A service cannot accept a credential from a registry it has not pinned, or one attested by an issuer outside its own lineage — such a login does not merely fail policy, it fails resolution. And since a service's trust in its registry is itself attested against the domain that service is published under, a missing DNS TXT causes every login to fail, not just unusual ones — except in the browser SDK, which skips the check.
This gate applies only to the session lane. The peer lane does not consult it: strangers can prove identity to each other regardless. Proving who you are and being authorized to use someone's service are different questions.
All of the following, together: a valid cryptographic proof; the credential exists on the pinned registry; it is within its validity window (or unbounded by sentinel); it has not been destroyed; the proof is fresh and not replayed (HOLA: yes; session lane: future-dating only); the lineage resolves to a trusted issuer; the proof is addressed to you (HOLA); DNS attestation of the registry succeeds (server SDK); and, for a delegated identity, the delegation checks out.
A signature check alone does not meet this bar. Verifying that some key signed something well-formed establishes well-formedness, not trust. Partial verification that looks successful is more dangerous than no verification, because it produces false confidence. The browser SDK's DNS stubs and the HOLA test helper that skips delegation are in this category.
A verified credential with a company name or a rendered face on it still only proves the bar in §5.4. Bind keys to identifiers cryptographically; leave real-world identity to parties who can attest to it.
Verifier-anchored trust resolution. §2.3 is the standout property. Most credential systems accept a chain supplied by the presenter; this one refuses to, which eliminates an entire class of chain-substitution attack by construction rather than by validation.
The operator chooses one family. A verifier pins a single named account and therefore a single Portal/Sanctum pair. No other registry can mint a Passport that this verifier will accept. Choosing which family to operate with is the trust decision the design asks the operator to make. Unlike a typical X.509 client, the operator does not inherit every CA/Browser Forum root in a bundle.
A process pointed at the wrong named account will not believe a real Passport from the right one, and a correctly pinned peer will not believe a Passport minted on the wrong one. Mutual authentication still requires both ends to resolve the same named account and the same issuing keys. The failure mode of a wrong pin is self-isolation: joining a family the operators did not intend, while still serving the same URL. A misbehaving issuer in another family cannot mint credentials that correctly pinned peers will accept. Noticing that drift is operator hygiene: compare the configured named account to the signed sc= in a locally stored copy of this process's own credential, and treat DNS TXT as authorization of this account on this domain. Those checks do not add a cryptographic root; they help the operator stay in the family they chose.
Minting is gated by the family's keys. The contract accepts a mint only if the fee attestation verifies against its authorized-signer set. As constructed, those keys are the Portal and Sanctum keys — the same keys that sign lineage. A well-formed blob with no such attestation never lands on chain. Root, server, and client are distinguished by which of those keys attested the Passport, which verifiers then walk from their own pin (§2.3). Keeping hierarchy off the contract lets one registry hold every layer without encoding an org chart in consensus. A compromised Portal or Sanctum can attest credentials that will verify, because they hold both keys. A fee-signed mint whose policy blob was swapped for nonsense can be stored and will fail at use. The amount of the fee is not a single contract rule — root, server, and public client paths price differently; the chain only checks that the authorized signature and the attached deposit match.
No trusted third party at verification time. A verifier needs the registry and nothing else. No issuer must be online, no revocation responder must answer, no identity provider must agree. Verification survives the issuer's disappearance. The property holds within a registry; spanning registries is planned, not built (§8.1). The optional helper API does not change the property, because it is optional.
Compromise is bounded by design. Signing services hold no funds and no registry authority; issuance authority is supposed to narrow downward; the holder's wallet is the only thing that can create a credential. There is no component whose compromise yields general forging power over existing identities. (It can yield forging power over new attestations from that tier. That is still bounded.)
Authentication costs no chain writes. Notarize-but-enforce-off-chain (§2.2) is what makes on-chain identity viable at request rates instead of a curiosity.
Portable proofs with no broker. The peer lane works on any channel the parties already share, with no central dependency, so it degrades gracefully and cannot be cut off by a single operator. Because the proof is a Morse-compatible line rather than a TLS session, that includes optical and acoustic encodings: a robot camera, a kiosk QR, a video-call screen, or Morse on sound or light, without a second protocol (§2.9).
Facial representability. The persistent identifier is itself a visual identity. Eleven traits plus a checksum decode to a human-recognisable face description, unique on the pinned registry, without storing a photograph (§2.8). Humans can tell agents apart by sight; machines still verify the string. Rotating the owning account leaves that face in place.
Immutability simplifies reasoning. A credential's meaning never changes. There is no version skew between what an issuer attested and what a verifier reads, and no cache-invalidation problem for policy. RPC caching still creates a liveness window (§7.6), not a meaning window.
Honest about its limits. The model states plainly that descriptive identity is self-declared. Many systems blur this and let verifiers infer organizational identity from a certificate. Being explicit is the safer engineering choice.
Economic friction as a Sybil brake. Issuance costs real value, so mass credential creation has linear cost — a simple and effective control that requires no heuristics. On the public path the broker computes the price from lifetime, rate, and purchase-tier; the contract then requires the attached deposit to match the attested fee.
Federated login inside a family. Sibling APIs on the same registry can accept each other's Passports without sharing session tokens and without letting the presenter nominate a registry. That is the right shape for multi-API deployments, and it does not weaken §2.3.
A public technology demonstrator exists. Synthetics' Last Cradle (backend lastcradle-be, spectator frontend lastcradle-fe) is a running federated peer: Passport required for contest seats; session-lane JWT for game actions; HOLA for private deals the server never brokers; facial identifiers that persist across games and are visible to spectators. The game recommends HOLA and does not gate transfers on a verified line.
These are properties of the design as built, not defects waiting for a cleaner compile. They persist however well the surrounding code is written. Where the running system is weaker than the design it still documents, that is called out explicitly. Choosing a family, and gating mint on that family's keys, are not in this list; they are strengths (§6).
There is no revocation list, no status responder, and no graduated states. The backend SDK no longer performs a revocation check of any kind. Effective revocation means destroying or seizing the credential, and that requires registry-owner privilege. Three problems follow.
Holders cannot revoke their own credential. A holder who knows their key is compromised has no way to invalidate it and must escalate to the registry owner — exactly when speed matters most. Second, "revoked", "destroyed", and "seized" are not distinguishable states a verifier can honour, so suspended pending investigation or valid for audit but not for new sessions cannot be expressed. Third, it reintroduces a central authority at the one point the rest of the design works hard to avoid one; the registry owner can unilaterally end or reassign any identity.
A DNS-based revocation channel was the intended softening of the first problem. It was implemented, then short-circuited, then removed from the backend SDK. What remains of it is a browser stub that always succeeds. Reintroducing DNS as the revocation channel would also reintroduce a non-chain trust dependency with its own TTLs and its own controllers, which partially contradicts the premise that the chain is the source of truth. The same critique applies to DNS-based registry attestation in §5.1, though there its role as a deliberately independent channel is a defensible reason to accept the dependency — provided the record's content is actually bound, which today it is not.
Because the chain does not enforce, identical credentials get different treatment from different verifiers. A verifier that never mounts rate-limit middleware has no rate limits; one that misreads route grants has the wrong access control. The system's effective security is the minimum across all verifiers, not the average, and no component can observe or attest to another's enforcement. In practice this concentrates risk in the SDK: it is the de facto policy enforcement point, and a subtle weakening there propagates silently to every dependant. Independent reimplementation is also risky — divergence in canonicalization breaks interoperability loudly, but divergence in enforcement breaks security quietly.
Attenuation at issuance does not close this gap. The public client path refuses unknown routes and privileged operations, but it does not uniformly cap lifetime or rate against the broker's own credential. A verifier that trusts "the issuer would never have signed that" is trusting a discipline the issuing path does not fully implement.
Expiry with no renewal and no linkage means a long-lived agent presents as a series of unrelated identifiers over time. Reputation, allowlists, audit trails, and prior authorizations do not carry across. The architecture offers no mechanism to prove "this new credential succeeds that old one" — the intended answer is out-of-band attestation, which is exactly the mechanism whose weaknesses §5.5 concedes. For agents intended to operate for years, this is likely the most operationally disruptive property in the design, and a signed succession claim from the expiring credential would address it cheaply.
The unbounded sentinel makes the disruption uneven rather than universal. Credentials issued with 1970-01-01 do not force rotation at all. The design therefore has neither a structural mortality guarantee nor a succession mechanism. Operators who want one must impose the other by policy, with no system support for linking the replacement.
Key possession is the whole of control. There is no recovery path, no social recovery, no threshold scheme. The only remedy is registry-owner seizure and reissuance — again centralized, and requiring the owner to adjudicate ownership claims out-of-band, which is a governance problem with no technical support. Transfer-as-rotation (§4) helps only the holder who still controls the current key.
The helper API already implements nonce replay protection on HOLA verification. After a line verifies, the API records tokenId plus the uppercase nonce for the remainder of that line's freshness window; a second presentation of the same pair fails with nonce_replay. Issuing a nonce ( GET /api/holanonce16ts) is not that store — it only supplies entropy — and a verifier who skips the helper must keep an equivalent cache of its own.
Anti-replay still requires verifier-side state. The helper's cache is in-process. Per-process state means a horizontally scaled verifier can accept the same HOLA on different instances; shared state reintroduces a central component in the peer lane's otherwise decentralized path. The architecture does not resolve this tension, and leaves each deployment to choose which property to give up. Presence of the API check is not a resolution of that tension; it is the in-process choice, shipped.
Login signatures are checked for future-dating and not for maximum age, and the challenge is not stored as a nonce. That gap is a missing check on the session lane. The helper API already runs the corresponding check on HOLA.
Reads must reach the chain. Caching improves availability but trades away freshness, creating a window in which a destroyed or expired credential still verifies. As built, RPC and session-validation caches are configurable and short. The trade-off is unavoidable given §2.2; what matters is that the window is a deliberate parameter with a stated bound, not an accident, and that verifiers who disable the cache know they have chosen latency over that window.
Every credential, its policy, and its ownership history are world-readable, and the identifier is a globally formatted twelve-character facial encoding that is unique only within a registry. The face is therefore public too: anyone can decode the traits, and anyone can render a look-alike portrait from them. This is right for machine identity and for human recognition of agents (§2.8), and it is the same publicity already required by independent verification. It means credential graphs, activity correlation, organizational structure, and the visual persona are inferable by anyone. Any use touching personal data inherits a privacy exposure that cannot be configured away. Distinguished-name fields that look like personal data make that exposure easier to underestimate, especially because they are unsigned (§2.5) and still world-readable. A rendered avatar hosted at an unsigned URL can also be swapped without invalidating the Passport; counterparties who treat the picture as the identity, rather than the twelve-character encoding, are trusting the wrong object.
The root ceremony creates the twin identifiers on which every downstream attestation depends, in a single operation, signing with keys that already exist in the Portal store and the ceremony client, with no threshold or multi-party structure. Its exposure is determined entirely by how the ceremony is conducted — an operational property the architecture cannot constrain. For a root of trust, threshold or split-custody generation would move a critical guarantee from procedure into structure.
Compounding this, the twin root keys are static: they cannot be rotated, so exposure accumulates over the deployment's entire life and compromise is unrecoverable. Rotation is planned (§8.2). Until it exists, the ceremony key's lifetime is the deployment's lifetime.
The ceremony endpoint's default-off flag is real in shipped configuration. The residual risk is that enabling it currently mounts an unauthenticated route that can attest a new root of trust.
Root-key rotation has a stated direction because the keys are static today (§7.8). Registry peering is a different kind of change: it extends the current single-registry model rather than patching a defect. Physical encodings of HOLA (§8.3) are encodings of an already-built line. All three belong even in an as-built description. Neither peering nor root rotation is implemented; first-party QR/Morse codecs are likewise not shipped.
As built, verification is intra-registry. A verifier resolves issuing keys from its own lineage and looks everything up on the registry it has pinned, so a credential from a different registry cannot be evaluated — not rejected on policy grounds, but unresolvable (§5.3). Two independently operated deployments, both correct, cannot authenticate each other. Federated login does not change this: it spans API URLs, not registries.
That is the current model. "No trusted third party at verification time" (§6) holds within a registry; the registry itself is the trusted third party for everyone using it, and its owner — who can also destroy or seize any credential (§7.1) — is effectively an ecosystem gatekeeper. Named-account membership is the membership check. The system decentralizes verification while centralizing membership. Interoperability today requires everyone to converge on one registry, which is a governance and business dependency rather than a technical one. Migrating registries invalidates every existing credential simultaneously, since identifiers carry no registry-independent meaning. Identifiers are unique only within a registry; the same identifier on two registries denotes different subjects, and the format does not signal which registry.
The planned evolution is to let registries establish trust relationships with one another, so that a credential issued on one registry can be verified by a service anchored to another. That is what allows membership to scale without every participant converging on a single registry.
The important property is that this can be done without weakening the guarantee in §2.3, provided the trust relationship is declared on the verifier's side. If a verifier's registry names the peer registries it accepts, then the verifier's anchor set is still determined entirely by its own configuration and its own registry's declarations — the presenter still supplies no part of the path. That is the failure mode §2.3 exists to prevent: a chain a credential nominates. Bilateral peering preserves verifier-anchored resolution; presenter-supplied bridging would not. Federated login, which already exists, is the intra-registry version of the same idea.
Two consequences deserve attention while the design is open. Peering makes identifier-scoping acute rather than theoretical: identifiers unique within a registry can collide across peered registries, so a federated identifier needs to be registry-qualified — and since the registry name already travels inside the signed lineage, the material for that qualification exists. Second, peering is a trust graph, so its semantics must be decided deliberately: whether trust is transitive, whether it is symmetric, and whether a peer's attenuation limits are honoured. Non-transitive, explicitly declared, asymmetric peering is the conservative starting point, because transitivity would let a distant registry's decisions propagate into a verifier that never agreed to them.
The intent is to make the twin root keys rotatable, replacing today's static keys (§7.8).
Immutability constrains the shape of any solution. Existing credentials carry permanent signatures made by the old root key, and no metadata can be rewritten, so rotation must be additive: retired root keys have to remain resolvable for as long as credentials they attested are still in use. The practical implication is that rotation bounds future exposure but cannot retroactively contain a past compromise — a rotated-away key stays trusted for the credentials it already signed.
Mortality (§2.6) is what would make this tractable — and the unbounded sentinel is what makes it less so. Because credentials can expire and cannot be renewed, a retired root key only needs to remain resolvable until the last credential it attested expires, after which it can be dropped entirely. Credentials issued with the unbounded sentinel have no such horizon. A deployment that adopts rotation therefore gains a concrete reason to stop using the sentinel for anything downstream of the root: maximum credential lifetime becomes the upper bound on how long a compromised root key remains dangerous.
QR display, Morse audio, and camera-based recovery encode the existing peer-lane line (§2.9). They do not require a new credential type, a new signature scheme, or a dedicated identity endpoint. A passport display kiosk that rotates a live HOLA as a scannable image, and first-party Morse or QR codecs, are not implemented. Building them would make the line easier to present in warehouses, on robot faceplates, and in human–agent video encounters. Freshness remains the operational constraint: a static sticker is not a live proof.
Ordered by ratio of risk reduced to work required, given the system as built. Implementation tracking (do not restate these specs in the backlog): security-compliance-improvements-plan.md items 67–77. Grant sequencing: near-agent-economy-funding.md Phase 1.
sc= in a locally stored copy of this process's own credential
An IdentyClaw Passport is a publicly readable, immutable, subject-owned credential on a specific registry, carrying its own policy and a signed pointer to whoever attested it. The persistent identifier is a facial encoding: eleven traits plus a checksum, unique on the registry, recognisable by humans and verifiable as a string by machines. The owning wallet signs and pays and can be replaced. Trust is established by resolving the issuer pointer outward from the verifier's own configuration and checking a signature over the credential's policy fields. Proof of current control is a HOLA line: locally signed, recipient-bound, Morse-compatible, whether it arrived over HTTP, a QR in an image, or sound. Issuance flows down tiers, usually narrowing authority at each step, and always completes with the subject's own wallet. The registry notarizes; verifiers enforce — when they actually run the enforcement. Synthetics' Last Cradle is the public technology demonstrator of that split: federated session on one API, HOLA among rivals on channels nobody controls, the same face across games.
The architecture removes the trusted third party from the verification path and prevents an attacker from supplying their own trust chain. Each verifier names one family rather than inheriting a bundle of issuers. The exposures are the mirror image: correctness depends on every verifier implementing policy properly, and the lifecycle operations credential systems normally provide — revocation, suspension, renewal, recovery — either require a central privilege the design otherwise avoids, or do not exist.
As built, session-lane freshness is weaker than the peer lane's; mortality, revocation checking, and the Portal/Sanctum privilege split are all less structural than the surrounding vocabulary suggests. Planned evolution is consistent with the original design: registry peering to extend verification beyond a single registry without letting presenters influence the trust path (§8.1), and root key rotation to bound the lifetime of the system's most critical secret (§8.2). What remains structurally unresolved is the credential lifecycle itself — a holder who loses control of a key, or needs to invalidate a credential quickly, or needs to carry an identity across expiry, still depends on either central privilege or out-of-band coordination.