Security policy

Last updated: November 2026

How to reach us

Email security@yumankind.com (preferred). If you don't get an acknowledgement within three business days, follow up at hello@yumankind.com.

The canonical reporting channel is published in our security.txt per RFC 9116.

What to include

A description of the vulnerability and the impact you believe it has.
Reproduction steps — ideally a minimal proof-of-concept.
The relevant component (mobile app, Prson API, website, login SDK, etc.) and the version or commit you tested against.
Any logs, screenshots, or HAR captures that help reproduction.
Your name or handle if you'd like to be credited publicly.

Our commitments

We acknowledge receipt within 3 business days.
We provide an initial triage and severity assessment within 7 business days.
We keep you updated at least every 14 days until resolution.
We do not pursue legal action against researchers acting in good faith under this policy.
With your permission we credit you in our public release notes once the issue is fixed.

Scope

In scope

The Prson mobile app (net.prson.app on iOS and Android).
The Prson API at api.prson.net (Cloudflare Workers) and the sign-in signaling service at signaling.prson.net.
The websites app.prson.net, prson.net and agents.prson.net.
Identity, signature, verification and sign-in flows — including the offline-verifiability claims we make about them.

Out of scope

Denial-of-service against shared infrastructure (Cloudflare, Firebase Authentication, Apple, Google). Reporting service-wide quota issues is welcome; attacking them is not.
Social engineering of Yumankind staff or end users.
Findings that require physical access to an unlocked, paired device.
Self-XSS or issues requiring the victim to paste attacker-controlled code into their own console.
Best-practice or theoretical issues without a demonstrated impact.
Vulnerabilities in third-party software we depend on, unless our configuration meaningfully exacerbates the issue.

Coordinated disclosure

Please give us a reasonable window to fix valid issues before publishing details. Typical timelines:

30 days for low / medium severity issues.
60 days for high severity issues.
90 days for issues that require client or infrastructure rollouts (e.g., key-format changes that need every wallet to migrate).

If we agree on a longer window we'll say so in writing. If we go silent, you are free to publish after the agreed window has expired.

Priority-one categories

Prson makes very specific claims about cryptography. Reports demonstrating any of the following are triaged first:

Minting, altering, or revoking a property signature without possession of the identity key or the notary key.
Recovering raw values (birthdate, document number, selfie bytes, etc.) from server-side data alone.
Binding a reality-proof capture to an identity that did not actually capture it, or replaying one capture as the response to a different challenge.
Reading or changing another wallet's or account's data through the Prson API.

Encrypted reports

If your finding is sensitive enough to warrant encryption in transit, mention this in a brief plaintext email and we will respond with an appropriate public key and continue from there.

Security architecture & compliance posture

For researchers and partners evaluating Prson, the load-bearing properties of the platform are:

Keys never leave your device. Identity keys derive from a 24-word recovery phrase; device keys live in the Secure Enclave / Android StrongBox and are non-extractable. We operate no key custody.
Hashes, not values, on the server. Verified properties are stored as salted commitments with signatures; the raw values stay on the device. Each commitment is SHA-256 over a random 16-byte salt that only the wallet keeps, the property type and the value, so short values (a birthdate, a phone number) can't be found by trying candidates, and the same value on two of your identities gives two unrelated commitments. To keep one email or phone to one holder we use a separate keyed hash (HMAC) whose key stays on our server. Chip-read document fields are kept as keyed hashes and randomly salted digests. Verification selfies are not sent to us.
Verifiable without our servers. Notary signatures (rotating keyring, published at /.well-known/jwt-vc-issuer and did.json) let any party verify proofs, properties, and credentials offline.
Unlinkable by design. Identifiers shared with relying parties are pairwise — derived per domain — so independent verifiers cannot correlate the same person across sites.
No wallet usage analytics. The app carries crash diagnostics only; no behavioural tracking of wallet use.
On-device biometrics. The level-6 face match between a live selfie and the chip photo runs on the phone, not on our servers; Prson checks the device attestation that covers the result. No biometric templates are stored server-side.

The full architecture — key model, verification ladder, unlinkability, certified capture, and the standards we implement — is documented publicly in the Prson trust-architecture white paper.

Vulnerability disclosure follows RFC 9116 security.txt. Conformance documentation for enterprise and regulatory review is available to partners on request at hello@yumankind.com.

Thank you

Privacy and authenticity are load-bearing for everything Prson is trying to build. We're grateful to researchers who help us hold the claims up.