Manav.id
Architecture

We don't watch. We let you prove.

Every primitive in Manav is a published standard from W3C, IETF, NIST or the OpenID Foundation. No blockchain. No token. No proprietary cryptography. A CISO's security review starts and ends with names they already trust — and this whole page is open precisely because none of it is the secret.

The principle
Most identity products try to detect bad actors. Detection requires surveillance.

Manav inverts the model. We require consensual signed evidence from the legitimate actor at every meaningful risk threshold. The bad actor cannot produce the signature; the action fails; no one had to be watched. Everything that follows is the cryptographic machinery that makes "prove" work without leaking who you are.

Open by design
We can publish the entire design because the design was never the secret.

A system that has to hide how it works is already broken — this is Kerckhoffs's principle, the oldest rule in cryptography. Manav holds to it: the standards, the receipt schema, the verification algorithm, and our signing key are all public. The only secret is the private key sealed in your device's secure enclave, which never leaves it and which we never see. An attacker who reads every byte of this page learns nothing that helps them forge a receipt. So we show you all of it.

The four primitives

Manav is built on four independently-standardised primitives. Each is labelled by maturity so the build-vs-wait decisions are explicit.

#PrimitiveStandard / sourceMaturity
1Public-key signatures (passkeys)W3C WebAuthn L2 / FIDO2Production-ratified
2Selective disclosureIETF RFC 9901 (SD-JWT)Production-ratified
3Zero-knowledge proofsNIST PEC + ZKProof initiativeEmerging
4NullifiersSemaphore protocol (PSE)Production-deployed, not standardised

1. The receipt format

Every Manav-signed action produces an offline-verifiable receipt: a small JSON object that binds the action's canonical hash to a per-context pseudonymous key plus the issuer's Ed25519 signature. The receipt verifies against the issuer's published key without any callback to Manav.

{
  "action": {
    "type":        "urn:manav:action:wire-transfer",
    "title":       "Approve $42,000 vendor wire",
    "payloadHash": "sha256:a83f9c2b..."
  },
  "actor": {
    "contextKey":  "pk_acme_4f81...",  // per-context pseudonym
    "keyAlg":      "ES256"
  },
  "webauthn": {
    "alg":         "ES256",
    "counter":     42,
    "challengeId": "chl_b9f0..."
  },
  "signedAt":      "2026-05-19T18:22:10Z",
  "manavSig":      "ed25519:5c8a..."
}

The receipt format is filed as IETF Internet-Draft draft-manav-receipts-00, with intended Standards Track status via the OpenID Foundation working group.

2. The delegation chain

For autonomous AI agents acting on behalf of a human across many actions, the human signs one scoped delegation; the agent then signs each individual action under that delegation. The chain verifies offline to the originating human's passkey ceremony.

{
  "delegateKey":    "ed25519:9a3f...",
  "scope": {
    "actions": ["urn:manav:action:wire-transfer"],
    "constraints": {
      "amount":         { "currency": "USD", "max": 50000 },
      "beneficiaries":  ["urn:vendor:greenleaf"]
    }
  },
  "notBefore":      "2026-05-19T00:00:00Z",
  "notAfter":       "2026-05-23T23:59:59Z",
  "maxChainDepth":  1,
  "revocationId":   "del_acme_4f81..."
}

Every agent action carries the delegation receipt plus the agent's own signature. Verification recursively walks the chain to the originating human ceremony. Scope is enforced by the verifier, not by the agent. Cascade revocation: revoking a delegation invalidates all sub-delegations and any future action receipts under them.

The delegation-chain extension is filed as draft-manav-delegation-chain-00 alongside the receipt format.

3. User verification, what counts as a Manav signature

Our marketing copy leans on "Face ID" because it's the most familiar mental image. The protocol does not. What a Manav ceremony requires is a WebAuthn assertion with user verification satisfied, and the W3C spec leaves "how" up to the authenticator. This matters in three real situations: the camera is broken, the user has a disability that makes biometrics unworkable, or the device has no biometric sensor at all (kiosks, hardware keys, older laptops).

What WebAuthn accepts as user verification

  • Face recognition, Face ID, Windows Hello face, Android face unlock. The familiar default; not the protocol's requirement.
  • Fingerprint, Touch ID, Android fingerprint, Windows Hello fingerprint. Same passkey, same Secure Enclave, different sensor.
  • Device PIN or passcode, the same PIN that unlocks the phone or laptop. Counts as uv:true under WebAuthn L2 §5.4.6. The assertion is cryptographically identical to a biometric one.
  • Hardware-key PIN + touch, YubiKey, Google Titan, SoloKey. Touch satisfies "user presence"; the key's PIN satisfies "user verification". The canonical accessibility answer.
  • Apple Watch unlock, on macOS, an unlocked Watch on the wrist is a recognised user-verification surrogate, useful when the Mac's camera is dead.

Cross-device flow (CTAP 2.1 hybrid)

If the device the user is signing on can't do user verification at all, say a desktop with a broken camera and no fingerprint sensor, the browser displays a QR code. The user scans it with their phone, satisfies UV on the phone (Face ID, fingerprint, or PIN), and the signed assertion travels back to the desktop over Bluetooth. The passkey doesn't even need to be on the broken device. Synced passkeys via iCloud Keychain or Google Password Manager make this seamless across the user's devices.

Enrol two, always

The honest production answer is at enrolment time, not at signing time. Manav's reference issuer refuses to mark an actor as production-ready until at least two authenticators are on file, typically phone passkey plus hardware key, or phone plus laptop platform passkey. "Camera broken" then reduces to "use the other one I already enrolled." This mirrors Apple's iCloud Keychain requirement for a recovery contact and Yubico's standing recommendation for a backup key.

Accessibility

For users for whom biometrics aren't usable at all, vision conditions that prevent Face ID, motor conditions that prevent reliable fingerprint capture, hardware security keys with PIN entry are the canonical answer. These have been usable for high-assurance authentication for over a decade, are supported by every major OS, and produce a WebAuthn assertion indistinguishable from a biometric one to the relying party. The receipt downstream does not record which verification method was used; it records that user verification succeeded.

4. Enrol once, prove forever, verify offline

Manav's privacy posture is enforced by where data lives and who is in the loop.

Enrolment, the one moment we see you

A user proves humanity once via a KYC partner (Persona, Onfido, or a government IdP). Manav issues a root credential signed by Manav's master key. The credential contains a public key, an issuance date, a jurisdiction, and an expiry, nothing more. No name. No date of birth. No biometric template. The credential itself lives encrypted on the user's device; Manav cannot read it.

Use, the moment we see nothing

Every interaction happens between the user and the relying party. The user derives per-context keys, generates selective-disclosure presentations, optionally emits nullifiers, and signs receipts, all locally. Manav is not in this path. No callback to our servers. No log entry on our side.

Verification, anyone, offline, without trusting us

Every Manav-issued credential and every Manav-attested receipt is signed by Manav's master Ed25519 key. We publish this key (and its rotation schedule) at a stable /.well-known/manav-keys endpoint. Any relying party can verify a Manav signature with no live connection to us. A Manav outage does not break verification. A Manav breach does not forge receipts.

5. What we publish, and what we don't

"Don't give away enough to reverse-engineer it" is the wrong instinct for a protocol — there's nothing in the design to reverse-engineer, and pretending otherwise is the security-through-obscurity trap. The real line isn't design versus secret. It's cryptographic design, which is safe to publish in full, versus operational tuning, which we withhold only because exposing it would let an attacker calibrate evasion. Neither one is load-bearing for the security proof — your private key is.

Published in fullHeld back
The primitives and standards — this entire pageThe liveness / presence-scoring model and its thresholds
The receipt and delegation-chain schemasAnti-abuse rate limits and anomaly thresholds
The verification algorithm and our published Ed25519 keyKYC-partner internal decisioning at enrolment
The "minimum necessary" disclosure schemas per use caseInfrastructure topology and key-custody (HSM) specifics beyond the public rotation schedule

The asymmetry is the point. Everything on the left is published because hiding it would add no security — the math holds whether or not an attacker has read it. Everything on the right is withheld not because it protects the design, but because it's a tuning surface: a published rate-limit threshold is just a target to stay under. An attacker who memorises this entire page still cannot produce a valid signature without the user's enrolled device. The secret was never the architecture.

6. Honest tradeoffs

A defensible architecture document names its own weaknesses.

  • The enrolment bottleneck. Someone, once, has to confirm the keypair belongs to a unique human. That party, Manav itself or a KYC delegate, sees the human at that moment. We can minimise what's stored, but the trust bottleneck does not disappear.
  • Key recovery. If a user loses every authenticator they enrolled and has no recovery contact configured, they're locked out unless we provide recovery. Recovery introduces a trust party, which weakens the privacy story. Manav default: enrol at least two authenticators (see §3), recovery is opt-in, and the mechanism is the user's choice.
  • Schema discipline. Selective disclosure is only as good as the attributes the verifier asks for. We publish opinionated "minimum necessary" schemas per use case and refuse to issue credentials with unbounded attribute sets.
  • Nullifiers are not yet a ratified standard. The primitive is production-deployed (World ID, Sismo) but not W3C/IETF blessed. Where a relying party requires ratified-only primitives, Manav offers SD-JWT one-time-use fallbacks.
  • Cross-employer fraud detection. Detecting one human working two jobs across separate employers requires private set intersection. Production-grade PSI at this scale is research today; intra-employer detection is shippable now.

References

Every claim in this document is grounded in a primary source. The full bibliography: