Identity as architecture
A contributor-owned identity is the target, not a claim about today’s service.
Status: Clio trust log with Ma’atara integration in progress.
Current source
Tested local foundations, not a deployed identity service.
Current source derives canonical did:maatara identifiers from ML-DSA-65 owner public keys, checks shared vectors and wrong-key failures, and verifies an owner-signed OIDC account-link statement server-side. Every contributor and issuer signing path in the trust source is ML-DSA-65 only — the P-256 path has been removed, not relabelled, and an unrecognised algorithm is rejected rather than accepted. Browser code now generates and holds that key: /contribute runs real ML-DSA-65 key generation and canonical did:maatara derivation locally, in the visitor's own browser, and wraps the key behind a passkey or a passphrase before anything touches storage. That identity is still local only — there is no account to link it to yet, so it cannot sign anything Clio would accept.
A personal Veritas chain per contributor, built on Ma’atara’s own chain operations, and a separate signed Clio institutional receipt for each accepted event are now implemented and tested against production WASM, alongside the pre-existing shared institutional EvidenceLog. A signed migration record links the frozen SHA-256 clio-local-evidence-v1 checkpoint to the new profile, and both verifiers still work. None of this is deployed, externally anchored, independently timestamped, or immutable. A contributor can now reach the identity step itself, locally; the personal chain and institutional receipt described here are not reachable yet, because nothing accepts a submission from one.
Remaining work
Browser custody now runs locally; account linking and deployment are still ahead.
Clio’s browser now generates and wraps an ML-DSA-65 owner key locally, at /contribute, using the tested source foundation to derive and verify the contributor’s canonical did:maatara. That identity is not linked to anything yet. Google, Microsoft, Ma’atara OIDC, or another provider will authenticate account access only, then link to that DID through the owner-signed statement the server already verifies — but the account service, and the route that lets a browser read a login ticket before signing it, are not built. OIDC must not derive, replace, or silently recover the identity.
Recovering a local identity from its saved phrase and kit file now works entirely client-side, demonstrated at /contribute. Recovering an account does not, because no account exists yet to recover. No route lets an operator do that recovery either. A did:maatara owner key cannot be rotated in place at all — only superseded by an entirely new identity — and no route yet accepts that supersession statement or exports a portable verification package for a published record; an issuer key today changes only when a redeploy supplies a different one, not through any route. A Clio service did:web still publishes issuer keys and a public profile that references the owner DID; it is not interchangeable with the owner DID.
Privacy and migration
The browser now stores only wrapped private material in IndexedDB, demonstrated at /contribute; the plain key exists in memory only after a visitor unlocks it, and only in that browser tab. New Veritas blocks contain versioned commitments and stable references, not raw museum records or private data — confirmed by checking what each block’s own hash actually binds. Legacy evidence remains verifiable under its existing rules, and a signed migration record now links the final legacy checkpoint to the new profile.
Read the architecture overview for the current boundary and acceptance work.