Sign in with MATA: sovereign SSO that never phones home
Sign in with MATA is sovereign single sign-on: a wallet on the person's device signs a token, and mid-verify checks that token on the relying party's own server. Verification reads the token and local configuration. It does not call MATA, and it does not store a password.
What is sign in with MATA?
Sign in with MATA is sovereign SSO. A wallet on the device signs a token, and mid-verify checks it on the relying party's server. Verification makes no call to MATA and stores no password.
Sovereign means the relying party can verify alone
Most SSO still has a landlord. The site redirects to a provider, the provider says the person is who they claim, and a password or a social account lives in that provider's database. Sign in with MATA reverses the dependency. The person holds a key. The site you are building checks the signature itself. MATA is the network that identity belongs to; the check does not need MATA to be reachable at the moment of sign-in. ragconverter.com uses this for its own sign-in, via the mid-verify crate, so a converter that promises documents can stay local does not then hand identity to a password vendor.
The wallet signs, and the token carries its own proof
The browser side is a small client, served from the site's own origin rather than a CDN, because a compromised CDN would then be a compromised sign-in. It asks the MATA wallet - an extension, or the native wallet via its URL scheme - to sign a statement. The wallet returns a JWT. There is nothing for the person to copy. Someone without a wallet is sent to create an identity. The token includes the audience (the exact site origin), a nonce the server just issued, the device key, and the roster of devices the person currently trusts. A DID looks like did:mata followed by a public key. It stays the same as devices are added and revoked.
Four checks, and none of them leave the server
mid-verify runs four cryptographic checks and then stops. The genesis key inside the DID must have signed the genesis roster. Each later roster entry must be signed by a device that was already in the previous roster, with versions only moving forward. The device that signed this particular token must still be in the current roster. The outer JWT signature must match that device's key. Audience, nonce, and expiry are checked before any of that. Every input is inside the token or in the server's own configuration. The crate does no network I/O. A site can verify a sign-in with MATA offline.
What you still have to hold, because the crate will not
The verifier is a pure function. Replay protection is the relying party's job, and skipping it is how a captured token becomes a login. ragconverter.com issues a 32-byte nonce, keeps it for five minutes, and deletes it on first use. The audience is the exact origin https://ragconverter.com, with no wildcard and no default - a token minted for another site must fail here. After a successful check, the server records the DID and the roster version it has seen. A later sign-in whose roster version went backwards is refused, which is how a revoked device presenting an old token dies. A DID that shows up with a different genesis roster than the one first anchored is refused too: that is a different identity wearing the same name. None of this is a password table.
A script still needs a key, and the dialog is honest about Google
A wallet cannot sit inside CI. After a fresh sign-in with MATA, ragconverter.com mints an API key, shows it once, and stores only a BLAKE3 hash. The key stands in for that DID. Revoking it does not require a password reset, because there was no password. The sign-in dialog also offers Google, loaded only when the dialog opens, for people who want that path. Google is a provider you call. MATA is the path where your server is the verifier. The same pattern is what to copy if you want sovereign SSO on your own product: add mid-verify, issue your own nonce, set the audience to your origin, and keep the roster mark yourself. The libraries around this stack, including the ones that keep the converter in the browser, are Remade with Rust. The API those keys unlock is described in a RAG conversion API for developers.