Standards & Specifications
Kimosabe.AI does not invent crypto or protocols. We anchor every security-critical decision to a public, peer-reviewed specification so reviewers, auditors, and integrators have something familiar to grade us against.
This document lists the specs we adopt, what part of each we use, and where each lands on the roadmap.
1. Cryptography & messaging protocol
| Spec |
Source |
What we adopt |
Phase |
| WebCrypto API |
W3C |
All in-browser crypto primitives (AES-GCM-256, ECDH P-256, HKDF-SHA-256, PBKDF2-SHA-256). No third-party crypto libs in the hot path. |
1 ✅ |
| NIST SP 800-132 |
NIST |
PBKDF2 parameters: SHA-256, 600,000 iterations, 16-byte random salt for password & recovery-code key wrapping. |
1 ✅ |
| NIST SP 800-38D |
NIST |
AES-GCM with 96-bit random IV per message, 128-bit auth tag. |
1 ✅ |
| X3DH |
Signal Foundation |
Asynchronous key agreement using identity + signed prekey + one-time prekeys. Replaces our current naive ECDH-only handshake. |
2 |
| Double Ratchet |
Signal Foundation |
Per-message forward secrecy and post-compromise security. |
2 |
| Sesame |
Signal Foundation |
Multi-device session management (web + future native client share identity). |
4 |
| Sealed Sender |
Signal Foundation |
Hides the sender identity from the server for direct messages, then groups. |
3 |
| MLS — RFC 9420 |
IETF |
Group end-to-end encryption. We adopt MLS instead of rolling Signal-style Sender Keys. |
2 |
| HPKE — RFC 9180 |
IETF |
Hybrid Public Key Encryption envelope for attachments and prekey-wrapped payloads. |
2 |
2. Identity & authentication
| Spec |
What we adopt |
Phase |
| NIST SP 800-63B AAL2 |
Password rules + recovery-key entropy (~120 bits) meet AAL2 memorized-secret + look-up-secret guidance. |
1 ✅ |
| WebAuthn Level 3 (W3C) / Passkeys |
Optional second factor on top of password + recovery key. Re-wraps the private key under a passkey-derived secret. |
2 |
| OpenID Connect Core 1.0 |
Federated identity attestation — prove control of an external handle (Mastodon, GitHub) without uploading it. |
3 |
| SCIM 2.0 (RFC 7644) |
Workspace user provisioning for the future Business tier. |
5 |
3. Public API surface
| Spec |
What we adopt |
Phase |
| OpenAPI 3.1 |
Single source of truth for the Agent SDK contract. See docs/agent-sdk.openapi.yaml. |
2 |
| Matrix Client-Server API |
Reference shape for sync, event schemas, and pagination. We do not aim for wire compatibility — only inspiration. |
2–3 |
| JSON:API 1.1 |
Response envelope conventions for non-Realtime endpoints. |
2 |
| AsyncAPI 2.6 |
Document the Realtime channel contract for agents and third-party clients. |
3 |
4. PWA & platform
| Spec |
What we adopt |
Phase |
| W3C Web App Manifest |
Installability, icon set, theme color. |
1 ✅ |
| Service Worker (W3C) |
Offline shell + queued sends. Ciphertext-only IndexedDB cache. |
1 ✅ |
| Push API + Web Notifications |
Encrypted push: server delivers ciphertext envelope; the SW decrypts in the browser. No plaintext to push providers. |
2 |
| Web Share Target Level 2 |
"Share to Kimosabe" from the OS share sheet. |
2 |
| Storage Access API |
Resilient session restoration in privacy-restricted browsers. |
2 |
5. Compliance & security posture
| Standard |
What we adopt |
Phase |
| OWASP ASVS 4.0 — Level 2 |
Baseline security checklist for every release. CI gate. |
1 (in progress) |
| OWASP MASVS 2.0 — Level 2 |
Mobile baseline once the native client lands. |
4 |
| NIST SP 800-175B / FIPS 140-3 algorithm choices |
All primitives are FIPS-friendly: AES-GCM-256, ECDH P-256, HKDF-SHA-256. |
1 ✅ |
| SOC 2 Type II readiness |
Controls mapping; formal audit at Business-tier launch. |
5 |
| GDPR Art. 25 / 32 |
Privacy by design and data-minimization posture documented in SECURITY.md. |
1 ✅ |
| CCPA / CPRA |
"Do Not Sell or Share" honored by default — we never sell. Right-to-delete = delete-account edge function. |
1 ✅ |
| EARN IT / LAED watch |
Track US legislation. We will not weaken E2EE under any policy regime; if forced, we will sunset rather than backdoor. |
Ongoing |
6. Accessibility
| Spec |
What we adopt |
Phase |
| WCAG 2.2 AA |
Color contrast, focus visibility, keyboard nav, prefers-reduced-motion. CI gate via axe-core. |
1 (in progress) |
| ARIA Authoring Practices 1.2 |
Patterns for menu, dialog, listbox, switch. |
1 ✅ |
7. Documentation & engineering process
| Standard |
What we adopt |
| Keep a Changelog 1.1 |
CHANGELOG.md format. |
| Semantic Versioning 2.0 |
Public artifacts (Agent SDK, manifest schema). |
| Conventional Commits 1.0 |
Commit messages — drives automated release notes. |
| C4 model (Brown) |
Architecture diagrams in ARCHITECTURE.md. |
| ADR (Nygard) — MADR template |
Material design decisions land in docs/adr/NNNN-*.md. |
8. What we explicitly do not adopt
- Telegram MTProto. Not peer-reviewed for E2EE-by-default. We use Signal/MLS instead.
- PGP / OpenPGP for messaging. Lacks forward secrecy; key-management UX is hostile.
- Custom "rolled" ratchets. We adopt published, reviewed designs only.
- SMS-based 2FA. SIM-swap risk; Passkeys + recovery key cover the same surface better.
Update policy
This document is reviewed every release. New specs land here only after an ADR
in docs/adr/ argues for adoption and identifies which phase consumes it.
