← Back to home

The Prson Trust Architecture

Technical white paper · June 2026 · Bruno Silva, Yumankind OÜ · Download the full paper (PDF)

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, decrypt a user's messages, or recover a lost wallet. This is not a policy — it is an architectural inability.
  • Data minimisation as physics, not promise. Raw identity values (document fields, birthdates, selfies, bank figures) stay on the user's device. The server stores salted hashes and signatures over them — enough to verify, never enough to reconstruct.
  • 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; issuance and presentation speak OpenID4VCI and OpenID4VP; document signatures are PAdES; provenance is C2PA-compatible. 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 — a pseudonymous identity with no verification. Credentials issued at this level say so, honestly (verified_human: false).
  • Levels 1–3 — progressively verified contact points and liveness signals (e.g. verified email, phone, selfie capture).
  • Level 4 — a government identity document has been captured and checked.
  • Levels 5–6 — the document's NFC chip has been read and its issuing-state signatures verified cryptographically, with biometric correspondence between the chip portrait and the live holder. This is the "verified human" tier.

Each verified property (name, birthdate, phone, address, website domain, bank facts) is stored as a salted 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.

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 salted document hashes, with a dispute window and cooldown rules — the mechanism sees hashes, never 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, bank balance at least X) — without revealing the underlying value. For amount-style facts the raw figure exists only on the device; the server can sign the predicate because it can re-check a salted commitment, not because it knows the number. 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 inside the app on a device whose integrity is attested by the platform (Play Integrity / App Attest) — emulators, rooted devices and tampered builds are refused at the gate in production.
  • Each artefact is hashed (SHA-256) at capture; the media carries an on-device C2PA-compatible signature from device-held keys, gated on the capturer's verified-human status.
  • 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 — sign a document, 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

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: OpenID4VCI (pre-authorized code flow) — any standards-compliant wallet can receive a Prson credential; issuer metadata at /.well-known/openid-credential-issuer. Issuer keys resolve both via did:web and via the HTTPS issuer metadata with an embedded x5c certificate chain, so DID-aware and eIDAS-style x5c-only verifiers validate the same credential.
  • 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.
  • Independently validated: the full presentation flow runs green end-to-end against the EUDI reference verifier, and the wallet has been exercised against the OpenID Foundation conformance suite's wallet tests — passing the happy-path tests, refusing the adversarial ones, with every finding remediated.
  • Identity assurance: the verification ladder is designed to map onto NIST SP 800-63 (document + biometric levels structured against IAL2 evidence requirements; phishing-resistant, hardware-bound authentication consistent with AAL2) and onto the eIDAS 2.0 / EUDI architecture direction. We state these as design alignments, not certifications; conformance documentation is available to partners under NDA.
  • Jurisdiction: Yumankind OÜ is an Estonian (EU) company; processing runs in EU regions; GDPR applies as home turf, not as an afterthought. 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;
  • reconstruct a user's document data, birthdate, selfie or bank figures from what our servers store;
  • 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.