Security

1What we do#

• Encryption in transit. The website, API, MCP server and webhooks use HTTPS only; monitors accept only https webhook URLs. Our database provider encrypts stored data at rest.
• Hashed credentials. API keys are random 32-character secrets shown once; we store their SHA-256 hash and, for keys issued from an account, an encrypted copy (AES-256-GCM) that the account holder can reveal only after confirming their e-mail address. Sign-in link tokens and session tokens are stored only as hashes. Claim verification tokens and owner manage links are also stored only as hashes. IP addresses are stored only as salted, truncated hashes, for rate limiting.
• Least privilege. The application connects to its own database with its own role, limited to Jid's data and separate from other services. Secrets are held in our hosting provider's encrypted environment settings, not in source code.
• Payments. Card details are entered on Stripe's pages and never reach our servers.
• Signed outputs. Badges' JSON statements are signed with Ed25519; webhook deliveries are signed with a per-monitor HMAC-SHA256 secret and a timestamp; incoming Stripe events are signature-checked and processed once.
• Abuse controls. Rate limits per key and per hashed IP, a bot check on the sign-in, claim, dispute and design partner forms, and daily limits on claims and reports per connection.
• Integrity of the record. Facts are append-only and each cites the SHA-256 hash of the raw source file it came from, so a change to a value is always visible as a dated event.

2Verifying a signed statement#

Fetch the statement from /badge/<id>.json. Serialise its "statement" object as JSON with keys sorted recursively and no whitespace, and verify the Ed25519 signature (base64url) against the public key with the matching key id at /.well-known/jid-keys.json. Check that the current time is before expires_at. A valid signature shows that Jid issued the statement; it does not make the statement a certificate (see the Claims and Badge Terms).

3Your part#

Keep API keys, manage links and webhook secrets out of client-side code, public repositories and shared prompts. Verify the Jid-Signature header and timestamp on every webhook. If a credential may have been exposed, tell us at security@jid.com and we will revoke it.

4Reporting a vulnerability#

E-mail security@jid.com with a description of the issue, the steps to reproduce it and its likely impact. We will acknowledge your report, keep you informed, and tell you when it is fixed.

If you act in good faith under these rules, we will not take legal action against you for your research:

• test only against your own API key, your own claimed file or data you are authorised to access;
• do not access, change or delete other people's data, and stop and tell us if you encounter any;
• do not run denial-of-service, load or volume tests, spam forms, or test against the sources we read;
• do not use social engineering or physical attacks;
• give us a reasonable time to fix the issue before disclosing it publicly.

We do not currently run a paid bug bounty.

5Incidents#

If a security incident affects your personal data or your credentials, we will tell you without undue delay and notify regulators where the law requires.

Service availability, the freshness of every registry feed and notes on any incident are published on the status page (/status).

6Certifications#

Jid has no security certifications or audit reports (such as SOC 2 or ISO 27001) of its own. Our infrastructure providers hold their own; see the Subprocessors page (/subprocessors).