Sign in with MATA: mid-verify Checks the Key on Your Side

A sign-in button is usually a lease. The person presses it, a company far away decides the signature is real, and the product learns who they are only because that company answered. Sign in with MATA is the other shape. The person holds a did:mata. The product checks the signature itself. The crate that does the check is mid-verify, and the door that already uses it for the household is dldeploy.com.

mid-verify 0.2.1 is the current release on crates.io, published 14 October 2026, dual licensed MIT or Apache-2.0. DLDeploy's portal depends on that version. The wider identity crate is mID. The browser half is Sovereign ID. The argument for a key you hold, rather than a badge you rent, is your login should not belong to someone else.

The check never leaves the house

mid-verify is a pure function. You hand it the compact token and a small config: the audience you expect, the nonce you issued, how much clock skew you allow, and the time as you see it. It returns the person's DID, a hash of the genesis roster, the head roster version, and the claims they chose to disclose. It does not read a secret store, and it does not place a call. The source is Remade-With-Rust/mid.

That is the whole sovereign SSO claim in one sentence. Single sign-on still means one key opens many doors. The door that accepts the key is yours. mata.network is the mesh those keys live on, described in MATA.NETWORK in the wild. The verifier does not need that mesh to be awake in order to say yes.

Four steps, all local

The DID string is the genesis public key, encoded so the server can read it without a directory. mid-verify checks four things, in order.

The genesis roster is signed by that key. Each later roster entry is signed by a key that was already in the roster before it, and the version numbers only move forward. The device that signed this particular token is still in the current roster, so a key the person has removed fails here. The outer token is an ordinary ES256 signature over that device key, and the audience, nonce, issue time, and expiry have to match the config the server passed in.

A product team does not stand up a key server to learn any of that. The token brought the chain with it.

The three traps DLDeploy closes

mid-verify will not remember a nonce for you, and it will not remember yesterday's roster. Those are the relying party's job, which is why a drop-in kit named mid-signin exists for a new site. DLDeploy calls mid-verify directly and closes the three gaps in its own portal.

The nonce is 32 random bytes, kept for five minutes, and thrown away on first use. It is consumed before the signature is checked, so a captured token cannot be tried twice and a caller cannot tell which half failed. The audience is the real site origin, never a wildcard: a token minted for another site does not open this one. The server stores the genesis hash the first time it sees a DID, and it stores the highest roster version after that. A later sign-in with a different genesis is refused. A later sign-in with an older roster, the shape a stolen device still has after the person revoked it, is refused too. Clock skew is two minutes. Skipping the rollback check is treated as a bug, because that is the hole a removed device would use.

Where Sign in with MATA already opens a door

dldeploy.com is the household mesh: boards that stay on the LAN. The person who sets them up should be the same person on the next visit, without a vendor account in the middle. Sign in with MATA is that continuity. The field note for the product is dldeploy in the wild, and the seam into the home is DLDeploy on MATA Home.

DLDeploy is the household sign-in

Start Now on the site opens a sign-in on the page the person is already reading. The page half is Sovereign ID, the @matanetwork/sovereign-id package, served from DLDeploy's own origin. An identity script loaded from a third-party CDN would make that CDN part of the sign-in. Vendoring it keeps the ceremony on the house.

The wallet signs a token for this origin and this nonce. The portal server runs mid-verify. On success the person receives a session key. The server stores a BLAKE3 hash of that key, not the key, and the capability they hold is the portal capability from the same identity family. The account remembers which boards were set up. It does not remember the Wi-Fi.

A rented provider can still sit beside the button. The signature Sign in with MATA trusts is the one mid-verify checked on the portal. That is the adoption point: the sovereign path is not a slogan next to someone else's OAuth. It is the path the household product actually takes.

The same verifier on ragconverter.com

ragconverter.com already verifies Sign in with MATA through mid-verify. Its own notes call the check local, with a server-issued single-use nonce and no network call while the token is examined. Documents a person converts on their machine should not require a campus login to prove who asked. The field note is ragconverter in the wild. Two products, one verifier, no shared identity vendor between them. That is what sovereign SSO looks like once a second door exists.

Why a product should adopt this SSO

Single sign-on became a habit because the alternative was a password on every site. The habit came with a landlord. If the landlord locks the account, delays the token, or prices the monthly active user, the product stops knowing its own people. mid-verify is the piece you embed so the habit stays and the landlord leaves.

A rented button is a lease

The person who signs in with a key they hold can add a device, remove one, and carry the same DID to the next product that speaks mID. The roster chain is how removal sticks: yesterday's device key is no longer in the head roster, and an old token that pretends otherwise fails the version check the server kept. The portfolio case for building on that grammar is The Importance of Remade With Rust. The map is Vision.

What a builder adds, and what they skip

Add mid-verify 0.2.1, or the mid-signin kit if you want the nonce store and the routes already shaped. Issue a nonce. Set the audience to your origin. Persist the genesis hash and the roster version. Put Sovereign ID on the page, from your origin. You skip the client id, the redirect allowlist, the token back-channel, the JWKS endpoint, and the resolver HTTP call.

Then point the button at a real product. The household one is dldeploy.com. The document one is ragconverter.com. The mesh the key belongs to is mata.network. Read next: mID, Sovereign ID, dldeploy in the wild.