AT Protocol integration
How a wallet account connects to an AT Protocol account, what that connection stores and where, the permissions requested, and what disconnecting actually does. See the platform overview for the identity model behind this.
Current status
The complete connection is integration-tested in the development stack. Connection, key and audit state are currently in memory; production use still requires hardened outbound networking, durable encrypted storage, server-side grant revocation and production Wallet-session binding.
Connecting an account
From the wallet, open Connected accounts and enter an AT Protocol handle. Verifable resolves the handle to its Personal Data Server (PDS) and sends the person there to approve the connection — the approval screen and the account it names both belong to the person's own PDS, not to Verifable. Verifable never asks for your password. This flow does not use app passwords.
Once approved, the connected-account surface shows the account's handle, its AT DID, its PDS endpoint, and the exact permissions that were granted.
What is stored where
OAuth tokens and DPoP key material are held server-side only in the development backend-for-frontend—never in browser storage or sent to the browser. The present store is process-local, so a restart removes the connection. The connection is not durably stored yet.
The AT DID is kept as the durable key for the connection. A handle change or a PDS migration on the AT Protocol side does not break the connection: both are handled by re-resolving the DID, since the handle and the PDS endpoint are presentation data, not identity.
Permissions
The connection requests two things, described in plain language before approval:
- Confirm which AT Protocol account is being connected.
- Read public feeds and profile, and publish posts and replies when the person chooses.
The connected-account card always shows exactly what was granted — not a paraphrase of the request, the actual grant.
Disconnecting
Disconnecting from the connected-account surface removes the server-held tokens and keys for that connection. Wallet data — passports, credentials, everything the wallet held before connecting — is untouched. The grant itself can also be revoked directly at the person's PDS, independently of Verifable. Calling that PDS revocation endpoint as part of Verifable's own disconnect flow remains a production hardening gate.
Failure states
The Wallet shows the connection's current state and the available next step:
- Network unavailable — "Your wallet and work remain available. The connected network service cannot currently be reached."
- Reauthorization required — the grant has expired or been narrowed and needs approving again at the PDS.
- Handle changed — the AT DID still resolves; the wallet updates the displayed handle.
- Account migrated — the AT DID now resolves to a different PDS; the wallet re-resolves and updates the endpoint shown.