Security.
How to report something, what we promise in return, and the reason you do not have to take our word for any of it.
Report a vulnerability
Email [email protected]. The machine-readable version of this page is at /.well-known/security.txt.
Tell us what you found, how to reproduce it, and what you think the impact is. You do not need a polished write-up and you do not need to prove exploitability — we would rather hear a vague concern early than a perfect report late.
What we commit to
- We acknowledge within [CONFIRM: e.g. 2 business days] and tell you whether we think it is a real issue within [CONFIRM: e.g. 10 business days].
- We keep you informed until it is closed, including when the honest answer is that a fix is slow.
- We credit you if you want credit, and stay quiet if you do not.
- We publish. Material issues get written up on our status page whether or not anyone outside noticed. A security page that only describes hypothetical process is worth nothing.
Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will say so to anyone who asks. Good faith means: you stay within the scope below, you do not access, modify or retain anyone else’s data, you do not degrade the service for others, and you give us reasonable time before disclosing publicly.
[CONFIRM with counsel: the exact safe-harbour wording, and whether it binds across the jurisdictions IOAI operates in.]
Scope
- In scope. This website, the open verification and identity endpoints, the published descriptors, and the settlement and attestation logic. [CONFIRM: exact domains and endpoints.]
- Out of scope. Findings that require physical access, social engineering of staff, denial of service, or third-party services we do not run. Reports generated by a scanner with no analysis attached.
- Especially welcome. Anything that lets an attestation verify when it should not, that makes two distinct-looking parties provably the same or vice versa, or that breaks the independence of an anchored record. Those are the failures that matter most here, because the entire product is the claim that they cannot happen.
Bounties
[CONFIRM: whether a paid bounty programme exists. If it does not, say so plainly here rather than leaving researchers to guess — an ambiguous bounty policy gets you fewer reports, not cheaper ones.]
The structural answer
You are not required to trust our security posture.
Everything above describes how we behave. It is a promise, and promises are exactly what this infrastructure exists to stop mattering.
Attestations verify independently, with no account and no permission from us. Anchored records carry inclusion proofs anyone can check. If we were compromised tomorrow, an attacker could damage the service — they could not retroactively make a false proof verify, and they could not quietly rewrite what the network already recorded.
That property is worth more than any policy statement on this page, and it is the one we would want you to test first.