Security

Our approach

Systems of this kind are only as good as the trust others can place in them, and trust of that kind is demonstrated rather than asserted. Our security rests on three principles.

Open The protocol specification and the reference verifier are public. Security does not depend on hiding how the system works.

Provable Directory state is publicly auditable, the signing root is held under a threshold scheme that no single party controls, and attestations can be verified offline. Wherever something can be proven, a counterparty should not have to take our word for it.

Adversarial A public bug bounty and independent audits invite the world to try to break the system. We would rather be tested in the open than trust that we got everything right.

How the system is secured

Layered keys High-frequency signing keys are kept separate from the low-frequency root, held in certified hardware, and never exposed to the application layer. The root is held under a threshold scheme across independent parties in more than one jurisdiction, so that no single person can exercise it.

Public transparency log Every change to the set of accredited issuers, and to the custody of the root, is written to an append-only, hash-chained log that anyone can audit. This lets a verifier confirm the state of the directory independently, rather than trusting an assertion.

Offline verifiability An attestation can be verified without contacting the issuer, which makes verification resilient to single points of failure.

Names designed against confusion Human-readable names are convenient for people and a target for deception. Registration enforces normalisation and detection of look-alike characters, reserves recognised names, and surfaces how long a name has existed, so that a recently created imitation is visible as such. The length of time a name has been held is treated as a signal a verifier can rely on.

What you see is what you sign For any consequential action, the confirmation a person sees describes that exact action in clear, fixed terms, and that description is what is cryptographically authorised. Authority is bound to the single action it was granted for and cannot be reused for another.

Infrastructure hardening Dependency and container scanning, a maintained software bill of materials, current transport security, network isolation, least-privilege access, and protection of public endpoints against abuse · maintained as a baseline and tested continuously.

Independent verification

We treat security as a process, not a one-time event.

• A public bug bounty invites anyone to attempt to forge a verification or break the system's binding properties, with real and credibly paid rewards.
• Independent security and cryptographic audits by recognised firms produce reports that we publish.
• Audits are repeated after every material change to the protocol.

Responsible disclosure

If you believe you have found a security issue, we want to hear from you before anyone else does.

• Email: security@idn.global
• Our disclosure policy and key are published at /.well-known/security.txt
• We commit to acknowledging reports promptly, working with you on a fix, and crediting you if you wish.

Please do not publicly disclose an issue until we have had a reasonable opportunity to address it.

What we do not claim

We are deliberate about the limits of what any system can promise. We do not claim that a fully compromised personal device, or a person acting under coercion, can be prevented in the moment; we design so that such events can be detected, contained, and recovered from quickly through revocation and out-of-band confirmation. We do not rely on secrecy for security. Every claim on this page is meant to be one an outside party can check.