Skip to main content

Identity Authority (IA)

An Identity Authority (IA) is a service in the Zapf ecosystem that verifies a user's ownership of a Legacy Identity Provider (LIDP) account and issues cryptographic attestations proving that ownership.

Role of an IA​

The core function of an IA is to bridge the Web2 and Web3 identity models.

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 proof by:

  1. Facilitating the OAuth flow (or OTP verification) with the LIDP.
  2. Generating a NIP-44 encrypted evidence payload containing the verification proof.
  3. Signing a Kind 35522 (IA Attestation) event.
  4. Publishing that attestation to its own Nostr relays.

Trust Model​

Zapf operates on a Federated Trust Model.

  • The Zapf protocol itself (the Nostr event schema) is permissionless.
  • Anyone can run an IA server.
  • Wallet clients and apps choose which IAs they trust to accurately verify LIDP identities.

For example, the official Zapf app trusts the zapf.app IA. If an independent developer runs a "Community IA", users of a different NWC wallet could configure their wallet to trust that Community IA's pubkey.

Multi-IA Stacking​

Because verification relies entirely on standard Nostr events, users can stack attestations from multiple IAs to increase their trustworthiness across the network.

A user's connection event (Kind 35521) can embed "s" tags from multiple different IAs, all attesting to the exact same LIDP identity. This provides resilience: if one IA goes offline or is compromised, the identity remains verifiable via the other IAs.

Furthermore, Zapf's Evidence Sharing mechanism allows users to take the verifiable evidence generated by one IA and present it to another IA without having to re-authenticate with the underlying LIDP (for OAuth-based providers).

IA Responsibilities​

To be a fully compliant IA, the service must:

  • Maintain high uptime for its public Nostr relay.
  • Actively manage revocations (publishing Kind 5 deletion events if an identity changes hands or expires).
  • Enforce strict identifier normalization (e.g., lowercasing emails) before signing to prevent spoofing.