Skip to main content

Identity Authority (IA)

An Identity Authority (IA) is a service that verifies a user's ownership of a legacy account (like Discord, X, or Email) and issues cryptographic proof of that ownership on the Nostr network.

Role of an IA​

An IA bridges the gap between traditional social platforms and the permissionless Nostr network.

When a user wants to link their Discord account to their Nostr public key, they cannot simply claim it — other network participants need proof. An IA provides this by:

  1. Facilitating the identity verification flow (bot-assisted challenge for Discord/Telegram, or direct challenge-token for web-based LIDPs) with the provider.
  2. Recording proof of the verification (the public post URL and challenge token).
  3. Signing a cryptographic attestation and publishing it to the network.

Trust Model​

The protocol operates on a Federated Trust Model:

  • Zapf is an open protocol — anyone can run an independent IA server. There is no central gatekeeper.
  • Wallet clients and apps choose which IAs they trust to accurately verify identities.

For example, if an independent developer runs a "Community IA", users of a different wallet could configure it to trust that Community IA.

Multi-IA Stacking​

By linking verifications from multiple sources (like Discord and X), users build an un-spoofable, portable identity that stays with them across the entire internet.

A user's Identity Connection can reference proofs from multiple different IAs via e tags, all attesting to the same legacy account. This provides resilience: if one IA goes offline or is compromised, the identity remains verifiable via the others.

Verification evidence is stored inside the Kind 35522 evidence tag. Since verification is backed by a publicly accessible URL (the post the user made), any IA can independently re-verify by fetching that URL — no user interaction required.

IA Responsibilities​

To be a fully compliant IA, the service must:

  • Maintain high uptime for its public relay.
  • Actively manage revocations if an identity changes hands or expires. When revoking an active session, also remove the Identity routing record from the store.
  • Enforce strict identifier normalization (e.g., lowercasing emails) to prevent spoofing.
  • Communicate the activation requirement to users: publishing Kind 35522 and returning it to the client does not activate routing. Routing only becomes live after the user signs and publishes Kind 35521 and sends the activation signal to the IA. The IA must expose an activation mechanism for this purpose; the specific interface is implementation-defined. If the user declines or abandons the signing dialog without completing activation, no routing link is created and the session is cleaned up.