Sign in with MATA, and the Key Stays in the Wallet

Sign in with MATA is how a person proves they hold a key, and how this site accepts that proof without renting an identity provider. The button on the portal says those words. Behind it, the wallet signs a nonce the server just minted, and mid-verify checks the token on that same server. No directory is queried. No certificate authority is asked who the person is. The check is the SSO, and the key never has to leave the wallet to perform it.

That is the shape worth adopting. A sovereign sign-in is an SSO a household can run because the verifier is a library, not a landlord. dldeploy uses it for the portal. The same contract already runs at RAG Converter, which is why the server side could share an implementation. The identity the wallet speaks is the one MATA treats as the person's own. The family that publishes the verifier is Remade With Rust.

What sign in with MATA asks the wallet to do

The browser half is small and local. Three files from @matanetwork/sovereign-id 0.1.1 are served from this origin, at /mid/, because loading an identity library from a CDN would make a CDN compromise a sign-in compromise. signIn talks to the wallet extension over window.__mata_mid__ and postMessage, and falls back to the mata-mid:// scheme for a native wallet. It returns a JWT. Nobody pastes a signature into a box.

A nonce this site issued

Before the wallet signs, the server mints a nonce: 32 bytes from the operating system's random source, written as hex, remembered for five minutes. Sign in with MATA puts that nonce in the token. The server consumes the nonce before it checks the signature, so a replay cannot burn attempts and a caller cannot learn which half failed. A nonce that was never issued, already used, or older than five minutes is refused. The memory of those nonces does not survive a process restart. That is a limit, written down, not a second store.

A check that never calls home

verify_mid_response runs with a config this site fills in. The expected audience is the real origin, https://dldeploy.com in production, never a wildcard. A wildcard audience would accept a token minted for some other site. The expected nonce is the one just consumed. The wallet's issued-at time may differ from ours by at most two minutes. Sign in with MATA fails closed on any of those. There is no JWKS fetch, no resolver, and no back-channel. The language of the verifier is Rust.

Why a sovereign sign-in is the SSO worth adopting

An identity provider SSO rents the login. The provider can see the sign-in, change the terms, or go away, and every application that trusted the rent goes with it. Sign in with MATA inverts the dependency. The application issues a challenge. The person signs it with a key they hold. The application checks the signature with a library it ships. Adopting that SSO means adopting a verifier, not a tenant account.

The audience is this site, not every site

A token that is good everywhere is a token that was stolen everywhere. Sign in with MATA binds the token to one audience, this origin. Another site that copied the JWT would fail the audience check, and this site would also fail the nonce check, because the nonce was already consumed. That is the whole of the replay story. It does not require a session cookie shared across the web.

One DID also has to keep presenting the same genesis roster. If a later sign-in shows a different genesis for a DID this server has already seen, it is refused. The roster is part of who the wallet says it is, not a decoration.

A revoked device cannot walk back in

check_rollback runs against a durable roster mark, not against the memory that dies on restart. A device that was revoked, and that comes back presenting an older roster, is refused even after a deploy. Skipping that check would leave a stolen-device replay open. Sign in with MATA treats the check as mandatory. The error is a roster rollback, not a vague unauthorized.

This is also why the sovereign version of SSO ages better than a rented one. Revocation is a mark the application stores, compared locally. It is not a phone call to a vendor that still has to agree the device is gone.

What the page holds after sign in with MATA

A good check mints a bearer key. The string starts with dld_ and then 64 hex characters, 32 random bytes. It is shown to the browser once, in the sense that the plaintext exists only to be handed over. The server stores the BLAKE3 hash. A fast hash is the right tool: the key is random, so there is no short password to grind. The key lives one day. After that, sign in with MATA is how a person gets another.

A key the server stores only as a hash

The browser keeps the key in localStorage. A cookie would be third-party, because the API origin is not the page origin. From then on the key is the only credential the page presents. The capability on that caller is narrow: use the dldeploy portal. It is not a grant over every device in the house.

The device side of identity is a different key. rusty_esp_mid is how a board mints its own did:mata. A pure Rust alternative to a vendor account is that argument at full length. Sign in with MATA is the person at the keyboard. The chip's key is the thing on the shelf. The Own vision is where those two stay distinct on purpose.

The other button, and the houses this SSO is for

The portal also offers Sign in with Google. That path yields did:google, and a session minted that way is not re-minted through the wallet. A Google identity cannot own a device here. The sovereign button is the one that can. Deploy an ESP32 at home in an afternoon is the afternoon that button is for: a person signs in, a board is flashed, the household adopts it. The MATA Home integration is the home computer that adoption is being built toward. Smart home access on your home computer is the access a rented login would have kept in someone else's app.

An application that wants this SSO copies the shape, not a secret. Issue a single-use nonce. Ask the wallet to sign it. Verify with mid-verify, audience pinned to your origin, rollback checked against a mark you store. Mint your own session key and keep only its hash. Serve the wallet library from your origin. Sign in with MATA is that sequence, already the one this site runs. The Learn index is the rest of what the household can do after the person is in.