← Back to home

The Prson Trust Architecture

Technical white paper · June 2026, corrected November 2026 · Bruno Silva, Yumankind OÜ

This page is the current edition. The June PDF was withdrawn because it predates these corrections (verification levels, how values are hashed, where data is processed, which standards are live); a new PDF edition will follow.

Abstract

Prson is a non-custodial identity wallet and proof network: it lets a person prove facts about themselves — I am a real, unique human, I am over 18, this photo was really taken by me, here, now, this signature is my verified legal name — to anyone, without surrendering their identity or becoming trackable across services.

This paper describes how. It is deliberately complete: the security of the system rests on cryptography and protocol design, not on secrecy. Every signature we produce can be verified by anyone, offline, against public key material we publish at well-known URLs — including every claim made on this page.

1. Design principles

  • Non-custodial by construction. Private keys are derived from a mnemonic phrase only the user holds. Our servers cannot sign as a user or recover a lost wallet. This is not a policy — it is an architectural inability.
  • Data minimisation. Selfies and the raw values of verified details stay on the user's device. To check a passport or ID card chip, the phone sends the chip data to Prson once; we keep keyed hashes, the issuing country, document type and expiry, and our signed statement — not the name, birthdate or document number. For other verified details the server keeps a commitment to each value under a random salt that only the user's wallet holds, and a signature over it, so a short value such as a birthdate or phone number can't be found by trying candidates. To find the same value twice (one email, one holder) the server uses a separate keyed hash whose key never leaves it.
  • Unlinkability by design. Two services that both verify the same person learn nothing they can correlate. Every identifier that leaves the network is scoped to one audience.
  • Verify, don't trust. Every artefact — a verified property, a certified photo, a signed PDF, a login credential — is independently verifiable against published keys, with no API call to us required.
  • Standards at the edges. Credentials are IETF SD-JWT-VC; presentation speaks OpenID4VP (issuance to other wallets over OpenID4VCI and PAdES document signing are not live on the current platform). Proprietary protocol exists only where the standards don't reach yet, and is documented.

2. Keys: who can sign what

A wallet starts from a BIP-39-style mnemonic. From it, the wallet deterministically derives a wallet root and, per identity the user creates, an identity keypair (Ed25519). Because derivation is deterministic, importing the mnemonic on a new phone re-creates the same identities and keys — recovery without any custodian.

Separately, every device holds a device key generated inside the phone's secure hardware (Secure Enclave / StrongBox). It is non-extractable and never leaves the device — not even to the user. Sensitive operations require both factors: the identity key proves who, the device key proves from where, and the binding between them is registered and signed at identity creation.

A third key family exists on our side: the notary keyring — company keys that countersign verification outcomes. The keyring is multi-key with documented rotation; every signature records which key (kid) produced it, and the current public keys are always published at /.well-known/jwks.json and as a DID document at /.well-known/did.json (did:web:app.prson.net). A notary signature asserts exactly one thing: "Prson's verification process observed this, at this time." It cannot fabricate a user's signature, because it isn't the user's key.

3. Verification levels: an honest ladder

Identities carry an explicit verification level rather than a binary "verified" badge, so a relying party can demand exactly the assurance it needs and no more:

  • Level 0 — not verified. Credentials issued at this level say so, honestly (verified_human: false).
  • Levels 1–4 — checks done on the phone: a live selfie (L1), plus fingerprint (L2), plus Face ID (L3), plus a photo of an ID document (L4). Prson can't check these itself. With a fresh Apple App Attest or Google Play Integrity attestation they are shown as "checked on a genuine device"; otherwise as "self-declared". They are never called "verified human".
  • Level 5 — the passport or ID card chip was read and checked by Prson: the issuing country's signature, the chip's anti-cloning check (Active Authentication, or Chip Authentication run by Prson's server through the phone), and that the document hasn't expired. This is "verified human". It proves someone held that genuine document at that moment; on its own it doesn't prove they are its holder.
  • Level 6 — level 5 plus a face match between a live selfie and the photo stored on the chip, with a liveness check. The match runs on the person's phone, not on Prson's servers. Prson checks a fresh App Attest or Play Integrity attestation covering the result, so it knows a genuine Prson app on a genuine phone produced it, against that exact chip photo.

Each verified property (name, birthdate, phone, address, website domain) is stored as a hash plus a notary signature, with per-type expiry. The raw value remains on the device and is disclosed only when — and to whom — the user chooses. The hash is a commitment, SHA-256 of a random 16-byte salt, the property type and the value; the wallet keeps the salt and hands it over only together with a value it reveals. Each identity gets its own salts, so the same value on two of a person's identities gives two unrelated commitments. Prson finds duplicates with a separate HMAC under a server-side key that is never published or shared. Fields read from a document chip are signed as digests with a random salt per value.

4. One person, one identity — without surveillance

Proof-of-personhood fails in one of two directions: either duplicates are possible (bots win), or uniqueness is enforced through a global identifier (surveillance wins). Prson splits the difference architecturally:

  • A government document can anchor one identity in the network. Duplicate claims are detected through a server-internal registry of keyed document hashes (HMAC with a secret only the server holds). The registry keeps those hashes, not the document contents.
  • That registry is never exposed. What a relying party can request instead is a domain-scoped unique-human credential: a notary-signed statement that "one unique, document-verified human holds this id at your domain". The id is derived with a keyed one-way function over the document anchor and the requesting domain — stable for that domain (sybil-resistant account keys), cryptographically uncorrelatable with the id the same person has anywhere else.

The result: a dating app can guarantee every profile is a distinct real human, and a marketplace can do the same — and neither can tell, even by colluding, that any of their users are the same person.

5. Selective disclosure and pairwise identity

Credentials are SD-JWT-VCs: the notary signs a credential in which individual claims are hidden behind salted digests, and the holder reveals only the claims they choose, per presentation. Holder binding uses a confirmation key (cnf.jwk) that the wallet derives per relying-party domain via HKDF — so the same user presents a stable key to the same site (a usable account identifier) and unrelated keys to different sites.

Beyond full claims, the wallet signs predicates — yes/no facts from a public catalog (over 18, document valid, EU national) — without revealing the underlying value to the relying party. Every predicate leaving the network is audience-bound: signed for one domain, unreplayable at another, carrying pairwise identifiers only.

A deliberate consequence of this design: the wallet app contains no analytics or advertising SDKs. Crash reporting is the only telemetry, and it can be switched off in Settings.

6. Certified capture: photos and videos that prove themselves

Generative AI has made "seeing" worthless as evidence. Prson's answer is to make authenticity a property of capture, not of forensic guesswork afterwards:

  • Capture happens live in the Prson camera — there is no gallery picker. The phone signs the capture hash with a hardware key attested by the platform (Android Keystore attestation / App Attest), and the proof records whether that attestation checked out, so a verifier can see if it came from a genuine Prson app on a genuine phone. Device motion during capture is recorded too.
  • Each artefact is hashed (SHA-256) at capture and signed on the device by the capturer's identity key.
  • These checks make AI-generated or replayed media much harder to pass off as a live capture. They run on the phone, so they raise the cost of faking; they don't make it impossible.
  • The notary countersigns a manifest binding the content hash, capture time, and (when the user consents) location — so the proof asserts who, when and what, not just "looks real".
  • For freshness, challenges work like a cryptographic "hold up today's newspaper": a verifier issues slots to fulfil (a photo of X, a verified property, a predicate), responses are captured live against that challenge, and multiple people can answer different slots of the same challenge, each attributed to their own identity.

Verification is offline-capable and public: anyone with the proof package can re-hash the media and check both signatures against the published keys — on our web verifier or with their own tooling, years later, whether or not we still exist.

7. Sign in with Prson

The login SDK lets any website or app authenticate users with the wallet. The protocol's notable properties:

  • Peer-to-peer delivery. The credential travels over an end-to-end encrypted channel established directly between the user's wallet and the relying page (WebRTC, NaCl box to an ephemeral key). Our signaling infrastructure relays opaque ciphertext and cannot read presentations.
  • Phishing-resistant domain binding. The domain shown to the user in the wallet is pinned to the page's browser-enforced Origin at session creation; the credential's audience and a one-shot nonce are bound into a holder-signed KB-JWT. A presentation for one site is useless anywhere else.
  • Acceptance tiers. A site chooses what it accepts: fully anonymous (a stable per-site key, no identity claims), pseudonymous level-0, or verified levels 1–6 — including document-backed claims and the unique-human id.
  • Short-lived credentials, live renewal. Presentations expire in minutes; the wallet renews live sessions and can revoke them ("sign out everywhere") instantly.
  • Verifier-side independence. Relying parties verify everything server-side with an open verifier library against our published JWKS — no callback to Prson in the login hot path.

The same machinery is reachable for native apps (app-to-app flows with OS-verified return links) and as standalone wallet-action links for one-shot requests — prove a fact — without a login session. In every variant the same rule holds: results are delivered only to the domain the user saw and approved.

8. Legally meaningful signatures: PAdES PDF signing (coming)

Not available in the current app. PDF signing ran on the platform we have retired and hasn't been brought to the current one yet. This is how it works, and will work again: a verified user can sign any PDF with a document-signing key derived from their own mnemonic. The signature is a standard PAdES B-T signature with an RFC-3161 timestamp, and the certificate chain ends at the Prson Identity Root CA — a three-tier CA whose root key is kept offline. The certificate's common name is the signer's notarised legal name: it can only be issued after the name has been re-verified against the cryptographic transcript of the signer's chip-read government document.

Signatures verify in standard PDF readers. The root and issuing certificates are published at /.well-known/identity-ca.cer, revocation at /.well-known/identity-ca.crl. The private key never leaves the device: the cloud prepares the byte range to sign and assembles the final document, but the signature itself is computed on the phone. The PDF is processed transiently and never stored by us.

9. Standards and regulatory posture

  • Credential format: IETF SD-JWT-VC, with published VCT schemas.
  • Issuance: the Prson wallet receives its credentials from the Prson API. Issuing to other wallets over OpenID4VCI is not live on the current platform. Issuer keys resolve via did:web and the /.well-known/jwt-vc-issuer metadata; the credentials don't carry an x5c certificate chain yet, so verifiers that only trust x5c (such as EUDI reference verifiers) refuse them for now.
  • Presentation: OpenID4VP 1.0 Final with DCQL and direct_post, including verification of signed request objects under both the x509_san_dns and x509_hash schemes, pinned to trust anchors bundled in the wallet.
  • Tested against: the presentation flow was run end-to-end against the EUDI reference verifier, and the wallet against the OpenID Foundation conformance suite's wallet tests, on the earlier platform (with x5c-signed credentials). Those runs need repeating on the current one.
  • Identity assurance: the verification ladder is mapped onto NIST SP 800-63: level 5 checks strong evidence cryptographically; level 6 adds a device-attested biometric comparison against the chip photo, which is not certified presentation-attack detection, so we make no IAL2 claim. Authentication is phishing-resistant and hardware-bound, consistent with AAL2. We state these as design alignments, not certifications; conformance documentation is available to partners under NDA.
  • Jurisdiction: Yumankind OÜ is an Estonian (EU) company and GDPR applies as home turf. Stored files (proof photos and videos, mail) are kept in EU-jurisdiction Cloudflare R2 buckets. The API runs on Cloudflare's global network with Cloudflare D1 databases, sign-in uses Firebase Authentication (Google), and some features send text to OpenAI for processing. Subprocessors are listed in the privacy policy.

10. What we deliberately cannot do

The strongest privacy statement is a list of inabilities. By construction, Prson cannot:

  • sign, spend, or present anything as a user — we hold no user private keys;
  • see a user's selfie, or read their name, birthdate or document number from the chip records we keep (keyed hashes and digests only);
  • tell two relying parties that they share a user, or build a cross-site profile of anyone — the identifiers we issue are pairwise by design;
  • quietly alter a verification outcome in the past — every artefact is signed, key ids are recorded, and old signatures keep verifying against the published key history;
  • read login presentations in transit — they are encrypted end-to-end to the relying page's ephemeral key.

11. Verify everything yourself

Questions, audits, or claims you'd like to challenge: hello@yumankind.com. We treat "prove it" as a feature request we've already shipped.