did:web
A did:web identifier points at a document you publish on a domain you control. ~alter fetches that document over HTTPS at the well-known location the method defines, then asks you to sign a one-time challenge with a key the document itself authorises for authentication. The domain is yours, so the proof rests on you rather than on any registry.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Publish, edit, or delete anything on your domain.
- •Read pages on your domain other than the DID document itself.
- •Sign anything other than the single challenge you are shown.
- •Reach services that accept the same DID elsewhere.
- •Surface your did:web pairing to any third party without a separate consent row scoped to that recipient.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- The did:web identifier you provide, and the HTTPS location it resolves to.
- The DID document at that location, checked for schema validity and for naming itself correctly.
- A signature over a single-use challenge, verified against a verification method the document authorises.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Page content, posts, or markup elsewhere on the domain.
- Verification methods the document does not authorise for authentication.
- Service endpoints listed in the document, which are read past rather than followed.
- Your private key or seed, neither of which is ever requested or transmitted.
- Other DIDs published on the same domain.
Where it lives
The attested identifier and tier badge sit in ~alter's pairing ledger keyed to your ~handle. Because you can change the document at any time, the pairing re-checks on a schedule rather than assuming it holds forever. Revoking removes the identifier from your pairing surface immediately.
How to revoke
Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter unpair did-webPairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.