Identity / Product overview
Ma’atara Identity
Create your cryptographic identity and control how supported applications use it. The Identity Portal handles local key custody, recovery and explicit approval of product access.
- Access
- Browser at id.maatara.io
- Identity
- Ma’atara decentralised identifier (DID)
- Key custody
- Locally unlocked, encrypted browser storage
- Recovery
- Current 24-word recovery phrase
What it provides
Identity creation and recovery
Create keys in your browser, register public identity evidence and restore an existing identity using its current recovery words.
Application approval
Review a supported application’s destination, requested permissions and expiry before approving a session or device authorisation.
Device management
Inspect recorded device authorisations and remove a product device’s future authorised access. The list is not a record of every sign-in session.
Encrypted settings access
Approve an application’s access to its specified settings. This flow does not give that application your root or content keys.
How to use it
- Create an identity, or restore the identity you already use. Store your recovery words privately offline.
- Open a supported product. Its sign-in or device setup sends you to the Portal to review the request.
- Unlock locally and approve the displayed access. Return to the requesting product to continue.
Use a browser with persistent local storage. A supported passkey can protect the local encryption key; otherwise setup uses a separate passphrase. Keep recovery words available before clearing storage or changing browsers.
Access and trust boundaries
A temporary session returns a signed proof and public identifier for the requested service. Device authorisation grants permissions to the application’s own device key and may transfer encrypted content keys. These approvals have different effects; the approval screen identifies which is requested.
Private identity keys are unlocked and used locally. Services receive public evidence, signatures, authorisation records and the encrypted data required for the requested operation. Browser key custody does not establish non-extractable hardware signing; a compromised browser can expose unlocked material.
Removing a device cannot erase keys or content it already received. Google or Microsoft sign-in cannot recover your cryptographic keys. Identity and authorisation records are not anonymous.
Current limits
- Content recovery requires the corresponding recovery records and content-key history. Lost historical keys and unsaved content cannot be recreated.
- Root-key rotation controls are currently disabled. Restore does not revoke another browser or replace a compromised root key.
- Recovery pairing depends on an existing browser retaining the required recovery material; it is not available for every account.
- The separate Windows client is a pilot. Browser access does not imply hardware-backed signing or desktop file watching.