Capability Tokens — Access Control For A Distributed Cloud
Capability tokens are distributed cloud access: scoped mID grants you can revoke, not passwords parked on a server that NIST told you to leave.

🪩 The Disco Party is MATA's distributed cloud.
Capability tokens are how distributed cloud access works when there is no server that owns the guest list. A password is a shared secret you hope a vendor stores well. A capability is a signed grant: who, what, until when, how much. The verifier checks it locally with mID. No OAuth hop. No MAU fee. No /token endpoint that can go dark and take the mesh with it. Revoke the grant and the token is a souvenir.
NIST has been describing this posture for years as zero trust: authenticate every request, grant least privilege, assume the network is hostile. A distributed cloud is that guidance with nowhere to hide a session table. What Is A Distributed Cloud is the architecture. Sign in with Sovereign ID is the human button. This article is the grant that button produces.
Why Capability Tokens Beat Passwords For Distributed Cloud Access
Passwords on a server assume a server. A distributed cloud is a mesh of machines nobody owns centrally. If access lives in a users table in Virginia, you did not leave the old world. You rented it. Capability tokens travel with the request. Any replica that knows the issuer keys can decide. That is distributed cloud access you can run on a laptop, a wasm module, or an ESP32 verifier.
Trust is the Digital Freedom primitive that is identity. Capability tokens are Trust made transferable. Security is the encryption around the payload the token unlocks — AES-256-GCM on the entry, not "HTTPS and a cookie." Incentive is payouts gated by the same grants: a host gets paid to serve a shard only when the caller presents a live capability. The NIST Zero Trust Architecture is the public spec. The Disco Party is the party that implements it.
The Electronic Frontier Foundation has the file on password dumps. The Privacy Rights Clearinghouse has the timeline. Capability tokens that never sit in a central table cannot appear on that timeline as "we lost the hash file."
How Capability Tokens Enforce Distributed Cloud Access
mID issues and verifies. SpaceDB's KeyDirectory seam is mID. The application never invents a second token format. House rule: one primitive, many altitudes. The Importance of Remade With Rust is why that primitive is a remade crate, not a JWT microservice you host on AWS "just for now."
Scoped Grants — Capability Tokens With A Small Mouth
A grant names an action and a resource, not "this user is logged in." Read this CID. Write this prefix until Friday. Spend this settlement budget. Distributed cloud access that starts as admin=true will end as a breach blog. Capability tokens stay small on purpose. The IETF HTTP semantics already taught the web to be precise about methods. Grants are that lesson for a mesh.
Revoke Without A Password Reset Ritual
Revocation is a capability event. Burn the grant. Peers stop honoring it. You do not email a reset link to a doorbell. You do not wait for a session TTL because you were scared to expire a cookie. Distributed cloud access that cannot revoke is a lease you cannot end. mID makes the end as cheap as the start.
Local Verify — Capability Tokens Need No OAuth Broker
The verifier is a library. mID checks the signature in process. No JWKS fetch on the hot path. No client ID. That is how a SpaceDB replica — the local-first database — authorizes a peer that just appeared on iroh. The NIST Secure Software Development Framework wants authn/authz you can audit in one crate. Capability tokens are that crate.
Capability Tokens Turn Distributed Cloud Access Into Digital Freedom
Digital Freedom is Trust, Security, and Incentive — nothing else. Capability tokens are Trust you can hand to a friend and take back. The Freedom Guide is the walkthrough. What Is Digital Freedom is the why. Remade With Rust is the catalog.
Distributed Cloud Access Is Not A Session Cookie
Cookies assume a browser and an origin. A mesh has peers, chips, and background jobs. Capability tokens work for all three. If your design starts with Set-Cookie, you are building a website, not a distributed cloud. Both can exist. Do not confuse them.
Least Privilege Is The Default, Not A Compliance Slide
NIST already wrote the slide. Capability tokens write the code. Give a host the right to store a shard, not the right to list your vault. Give a game client the right to a stream, not the right to your bank. The Federal Trade Commission keeps fining companies that collected "just in case." Distributed cloud access does not get a "just in case."
Remade Primitives, Disco Party, Digital Freedom
mID and mata-cap are Remade-With-Rust primitives. They become a disco party when capability tokens are the only distributed cloud access the mesh understands. They become Digital Freedom when Trust, Security, and Incentive — identity, encryption, payouts — are grants you hold, not passwords a vendor can reset. Start at the Disco Party and the Learn index. Ship the grant. Delete the users table.
The key that issues the grant lives on the chip. What idle machines do once they are allowed in is idle devices earn. The web-side verifier is Sign in with Sovereign ID.

