Identity binding — part of dtp-wot/1

Status: draft · 2026-09-30 · normative; extends wot-model.md §2.5

On Nostr, trust points at a pubkey (p). On X, trust points at an X user id (i=user:id:X). A trust statement about an X account becomes a hop only when, for the observer, user:id:X is bound to the npub that controls it. This document defines when that happens, in two modes:

The mode is a query parameter (bindingMode). The same mode on the same data gives the same answer in every runtime.

1. Inputs#

Only user:id:<digits> subjects bind. post:id, e, and other i subjects never bind.

2. Witness statements#

For each author A and X, A's witness is A's newest active v=1 statement about user:id:X that passes every row below (tie on created_at → lower event id). One witness per author.

Witness-only statements: a verifier service (for example X OAuth plus a signed Nostr challenge) can publish with c=identity:attest. That context is not in Chain(32009, identity), so the statement witnesses a bind without becoming a trust hop or trust evidence.

3. Claim states#

A 10011 alone never creates a candidate. Anyone can claim any X id; a claim only confirms a candidate that someone the observer trusts has witnessed.

4. Bind decision#

bind(R, X, ℓ) — the npub X is bound to when the root R counts statements made by authors at level ℓ. It is a pure function of the root's walk up to level ℓ, the witnesses, the claims, the mode, and the own evidence.

Because ranking starts with the lowest level, a bind made at level ℓ never changes at deeper levels: the nearest eligible witness decides. In strict mode a nearer false hint is skipped, so a correct farther witness can still bind.

5. Situations, side by side#

From one root's point of view. "Claims" means P's 10011 names X.

6. Hop rules#

A qualifying author A at level ℓ has a selected statement e about subject s (wot-model §4.3). Both modes, with bind(R, X, ℓ) from §4:

• If A has statements about both p:P and a bound user:id:X, one of them counts (wot-model §4.3 tie-break).
• For a query about user:id:X, the evidence at hitting degree d includes statements about p:P only when bind(R, X, d − 1) is P.

7. Different observers, different routes#

Carol and Dave both trust X's account and hint different npubs. P2 is the real owner and published a 10011; P1 did not.

Lenient keeps each person's view; a wrong witness misleads exactly the people for whom that witness is the nearest. Strict gives up hops for accounts without a 10011 and closes that door.

8. Result provenance#

Trust and rating results about user:id:X carry an additive binding field (resolver-api.md):

{
  "mode": "strict",
  "pubkey": "<hex>",
  "source": "own-bio",
  "confirmed": true,
  "witnessEventId": "<id>",
  "witnessDegree": 2,
  "claimEventId": "<id>"
}

source is one of own-bio, own-post, own-statement, witness, none (own-bio / own-post occur only in the extension's local heap; servers hold no X data).

witnessDegree is the degree of the witness statement, counted like the result degree: level(A) + 1 for witness author A. The root's own statement (own-statement) has witnessDegree: 1; a witness by a level-1 author has 2. It is present exactly when witnessEventId is: for sources own-statement and witness, and on a strict-mode unbound result with a cutCandidate, where both describe the cut candidate's witness. A bind used at level ℓ always has witnessDegree ≤ ℓ + 1.

Which level's bind a result reports. A connected result at degree d reports bind(R, X, d − 1), the bind its evidence was counted under. A disconnected result reports bind(R, X, ℓ*) at the level of the walk's last hit check (wot-model.md §6.1): D − 1 at maxDepth, the last non-empty level when the frontier ran out, or completeDepth when a budget stopped the walk. Unbound results carry source: "none" and, in strict mode, the top cut candidate and the reason (no-claim, false-hint) so the UI can explain it.

9. Publishing rule#

A client SHOULD attach an npub hint to its trust statements only from own evidence (Bio or linking post), or from a bind that is confirmed by a 10011. It SHOULD NOT re-publish a bind it learned only from someone else's hint: that turns a second-hand guess into what looks like a first-hand witness for the next observer.

Attention today attaches its winning npub, which can come from another issuer's hint (primaryNpubFromRow → eventNpub). See conformance gap G9.

10. Runtimes#

Both servers bind the same way. When Attention uses a server, the user's own X observation (Bio / linking post) counts only once it is published as the user's own witness (§9): Attention attaches that npub as the hint when the user trusts the account. Until then only the local heap can use it.

11. Security notes#

• Lenient risk: a trusted but careless or malicious witness can bind an X account to the wrong npub for the people who trust that witness most closely. The damage is limited to their webs of trust and visible in binding provenance.
• Strict cost: X accounts whose owners never published 10011 stay terminal, including accounts with an npub in their Bio. Fewer hops, especially early in adoption.
• Both modes: a 10011 alone, or a hint from outside the observer's web of trust, never binds. Distrust statements are not vetoes of a bind.
• A verifier service is just an issuer. Observers who trust it (directly or through their web of trust) get its binds; there are no server-wide aliases outside this model.