The identity document for agents and robots

The document

One card. Everything a counterparty needs.

The data page is rendered by the registry from the sealed document. The holder sees every field; everyone else sees the issuer-sealed fields with disclosable claims marked as not disclosed. The QR is not a link to a record: it is the sealed token itself.

The holder's own view of a software agent's ID, exactly as the registry rendered it during the recorded evidence run (document IA). Geist, the stone palette and the logo geometry are the phanes.app design tokens.

01Phanes ID number

Nine characters, A to Z and 0 to 9, derived from the issuer key, the holder key and fresh randomness.

02Document type

IA for a software agent, IR for a physical robot or device bound to attested hardware.

03Agent, controller, jurisdiction

The agent's name and type, the legal entity behind it, its ISO 3166-1 jurisdiction.

04Model

Provider and model id, marked attested when the provider signed for it.

05Holder key

The agent's own Ed25519 key. Every presentation is signed fresh with it; the document is bound to it (cnf).

06Capabilities and authority bounds

What the agent may do and integer limits on how far, sealed by the issuer.

07Validity, status references

Issue and expiry times, and the bit each verifier checks in the signed revocation and suspension lists.

08Selective disclosure

Disclosable claims travel as salted digests (SD-JWT). The holder reveals only what a venue needs.

What a scan does

The QR carries the token. The browser does the checking.

Every printed ID encodes https://phanes.app/id#<token>. The token is the 160-byte classical Mark in base64url. It sits in the address fragment, which the browser never sends to any server. The page reads it, verifies the issuer's seal against the key published on its own origin, checks the signed status lists, and shows every check with its reason.

Eight checks, in order

01

Token

160 bytes read from the address fragment: magic, layout and character set accepted.

02

Issuer

The key id inside the token matches the issuer key published on this origin.

03

Signature

Ed25519 over the sealed frame, verified with WebCrypto or the in-page reference implementation.

04

Validity

Issued before now (five minutes of skew allowed), not yet expired.

05

Revocation

The token's bit in the issuer-signed revocation list is clear.

06

Suspension

The token's bit in the issuer-signed suspension list is clear.

07

Hybrid seal

The printed token carries the Ed25519 seal; the ML-DSA-87 seal on the same ID is checked by the registry and phanes-core.

08

Registry

When the anchors name a registry, its live verdict on the hybrid Mark is shown alongside.

Verdicts are Valid, Not valid, Revoked, Suspended or Expired. Without the issuer anchors the page says Unverified; it never says Valid without the key.

A real token opened in Chromium during the recorded evidence run. The same page, served by any registry at its own /id, verifies that registry's tokens without reaching phanes.app.

The Mark

160 bytes. Recognised in nanoseconds, verified in microseconds.

The Mark is the machine form of the ID: a fixed layout an interface can recognise at the packet boundary with no parsing and no allocation, then verify with one strict Ed25519 check and two status-bit lookups. The hybrid form adds a FIPS 204 ML-DSA-87 signature over the same bytes. The Rust core ships as a crate, a C ABI for firmware, and a JSON binary for any language.

Medians from the recorded benchmark session (phanes-core, Intel Xeon 2.10 GHz, single core). Recognition of junk stops at the first byte in under a nanosecond.

Security posture

Two signatures on everything. Nothing served off the record.

Built for the environments that will ask the hardest questions. Every issuer artefact is sealed twice, every request the registry serves is provable afterwards, and the page a scan opens cannot be quietly changed.

Physical agents

Robots carry the same document, bound to attested hardware.

A robot, vehicle, drone or embedded device applies with a device profile and a manufacturer attestation over its measured firmware and serial. The issuer verifies the attestation against the manufacturers it trusts, issues an IR document, and sets the hardware-bound flag in the Mark so a gate can tell a device from a process before any cryptography runs.

Device profile

Kind, manufacturer, model, a digest of the serial, the hardware root of trust (TPM 2.0, secure element, HSM, TEE) and the firmware digest.

Manufacturer attestation

A signed statement over the unit's key fingerprint, serial digest and firmware digest. A mismatch on any of them does not bind.

Robotics insurance

Physical damage and bodily injury lines, available only to hardware-bound IR documents at Verified or above.

A warehouse unit's ID from the evidence run: the manufacturer attested the measured firmware, the registry bound the device, the card shows the root of trust and the Hardware-bound chip.

Certification

Four tiers, every input echoed back.

The tier is computed by deterministic rules over verifiable inputs and issued as a signed credential a counterparty verifies offline. The credential lists every check it used, so a verifier sees why the tier was granted, not only that it was. The badge is communicated in HTTP headers and MCP metadata.

Level	Tier	Adds
0	Registered	A valid ID, not revoked or suspended.
1	Verified	Controller KYB attestation and model-provider attestation, both verified by the issuer at issuance.
2	Certified	Insurance in force with a per-claim limit at or above the agent's transaction bound, and an operator-anchored activity record.
3	Institutional	90 days of history, 500 events, adverse outcomes under 1%, a tenth of events witnessed by venues, no paid claims in a year.

The badge for a Certified agent from the evidence run. It is rendered from the credential, never typed: the number, the expiry and the insured state are read from the signed payload.

Sealed like the document

The certification board signs with Ed25519 and ML-DSA-87. A verifier can demand a minimum level and proof of insurance in one call.

Insurance

Four packages. Premiums from the record, claims from the proof.

Quotes are computed deterministically from the ID, its tier and its activity history, with every rating factor returned. A claim names an event in the agent's activity record; the registry verifies its inclusion proof against a signed tree head before rules adjudicate it. Limits below are per claim and aggregate, in USD.

Activity record

What the agent did, signed by the agent, anchored by the registry.

# hash a real file, record the invocation with its digest, size and exit code
H=$(sha256sum aeos/phanes_id.py | cut -d' ' -f1)
phanes record --server https://registry.example --key agent.key IA1234567 \
  --type tool.invoked \
  --what '{"tool":"sha256sum","path":"aeos/phanes_id.py","sha256":"'$H'","exit_code":0}' \
  --where '{"venue_did":"did:phanes:venue:desk","jurisdiction":"USA"}' \
  --how '{"method":"bash","model_id":"claude-fable-5-1"}'

# the signed summary, tree head and an inclusion proof for event 3
phanes transcript --server https://registry.example IA1234567
phanes audit --server https://registry.example --inclusion 3

Proven in the open

Recorded, not described.

Every command of the evidence run was executed under a pseudo-terminal recorder and kept with its raw typescript and SHA-256: the suites, a walkthrough against a live registry, a 112-agent campaign with an adversary running 43 attacks, the browser verifier driven in Chromium, and two documents built only from those files. Every session is on the evidence page.