Sign in with MATA Is an SSO You Verify Yourself

Sign in with MATA is the button on dldeploy.com. The person holds a wallet. The wallet signs a token over a nonce the site just issued. mid-verify checks that token on the server that asked for it. There is no JWKS URL, no DID resolver, and no call back to MATA to ask who this is.

That is sovereign SSO. The identity is a key on the device. The relying party is the site. The verifier is a library: dldeploy's portal server depends on mid-verify 0.2.1, and the crate forbids unsafe code. Remade with Rust is the program that publishes the mID crates. ragconverter.com already runs the same session shape. After the signature checks, the API hands back a bearer key and stores only a hash.

If you are the person pressing the button, start with what is Sign in with MATA. This page is for someone who wants that button on their own product. The browser half of the button is in the Freedom Guide. The longer relying-party argument, including the JavaScript packages, is Sign in with Sovereign ID.

Trust is a DID the person holds, did:mata:, not an account an identity company can suspend. Security is a signature checked in process, plus a nonce that dies on first use. Incentive is an SSO with no monthly-active-user meter, so adopting it does not tax the site that grows. The Electronic Frontier Foundation has the file on identity companies that see every login because the login had to pass through them.

Why Sign in with MATA Does Not Rent an Identity Provider

OAuth taught sites to register, collect a client ID, and pay when the login count crossed a line. The company in the middle had to see the event to bill for it. Sign in with MATA takes that company out of the request. The NIST digital identity guidelines describe an authenticator bound to the person, and a verifier that checks a proof instead of looking the person up in someone else's directory. mid-verify is that verifier. It is a function call, not a tenant.

dldeploy shows a second button, Sign in with Google. That path is a different provider, and this article is not about it. Sign in with MATA is the path mid-verify handles. A product can offer both. The sovereign one still works when no identity company is in the round trip. The Federal Trade Commission keeps writing up products that held more identity data than the login required. A site that verifies locally has less to hold, on purpose.

The same primitive on a chip is mID on the chip. The website button and the device grant are one idea: a key signs, a peer checks, and a vendor console is not the source of the name. Era 2 is the era where that peer is a person you chose, not a region you rented.

mid-verify Is How Sign in with MATA Is Checked

The outer token is a JSON Web Signature in compact form, ES256, the shape in RFC 7515. mid-verify does not fetch a key for it. Everything cryptographic travels inside the token: the genesis roster, the roster chain, and the verification method of the device that signed. The site passes in four things of its own: the audience it expects, the nonce it issued, how much clock skew it will tolerate, and the current time. dldeploy tolerates 120 seconds of skew. The function reads no clock and opens no socket. Tests can pass a fixed time. Production passes the wall clock.

The four checks inside mid-verify

First the genesis key, decoded from the DID, must have signed the genesis roster. Then each later roster entry must be signed by a key that was already in the previous roster, and the versions must climb. Then the device that signed this login must still be in the current roster. Then the outer signature must match that device's key. Fail any step and the login fails with a typed error, not a vague rejection from a vendor. Sign in with MATA succeeds only when all four hold.

A Sign in with MATA nonce works once

dldeploy mints the nonce itself: 32 bytes from the operating system's random source, hex, kept for five minutes. It is consumed before the signature is checked. A captured token cannot be presented again. A caller also cannot use a replay to learn which half of the check failed, because the nonce is already gone. That store is memory on the portal. A restart forgets outstanding nonces, which is the right failure: those attempts simply end.

The audience is the real site, not a wildcard

The audience is the site origin, and dldeploy requires it. There is no default. A missing origin refuses to boot, because a wrong audience is an authentication bypass. In production that origin is https://dldeploy.com. The wallet sets the token's audience from the site that asked. mid-verify demands an exact match. A wildcard would accept a token minted for any other site. Sign in with MATA on dldeploy does not use one.

A Sign in with MATA Session Still Belongs to the Site

mid-verify answers "did this key sign this token for this site, just now?" The site still decides what that person may do afterward. dldeploy grants the portal capability and nothing wider. Your product would grant your own. Sovereign SSO does not arrive with a role system. It arrives with a DID you can recognize tomorrow.

A revoked device cannot walk the roster backward

The site remembers the highest roster version it has accepted for that DID, and it remembers the genesis roster hash from the first time it saw the DID. A later login with a different genesis is refused. A later login whose roster version is older than the mark is refused, including after a deploy, because the mark is durable. That is how a revoked device, still holding an older signed roster, fails Sign in with MATA. First sight of a DID has no mark yet, so the check passes and the site records the version it just saw.

The portal keeps a hash, not the wallet

When Sign in with MATA succeeds, dldeploy mints its own bearer key, shows the plaintext once, and stores only a BLAKE3 hash. The key lives for a day. The browser keeps it in local storage because the API origin is not the page origin, so a cookie would be a third-party cookie. The wallet key never becomes that bearer key. A leak of the portal's table leaks hashes of keys the portal minted, not the person's signing key, and not a MATA password. The website never received one. Your digital identity is the longer account of where that signing key stays.

Another product can run the same mid-verify

The library is the part you adopt. The nonce store, the audience, and the roster mark are the part you own, because they are about your site. dldeploy wrote them in its portal server rather than calling out to an identity tenant. A kit in the same repo, mid-signin, packages those same duties — single-use nonces, the genesis anchor, rollback, routes — for a site that wants them ready-made. Either way the hot path is yours. DLDeploy on MATA Home is what a person does after this login: flash a board that reports to the Home Computer. The login that opened that page was Sign in with MATA, checked by mid-verify, on the site itself. Rebuilding identity as a primitive is the same refusal one layer down: a library in the process, not a meter in someone else's region. Ship notes for that family go to futureweb.news.