Skip to main content

Evidence Sharing & Cross-IA Verification

Because Zapf operates on a federated multi-IA model, users may want to have their Legacy Identity Provider (LIDP) account verified by multiple different Identity Authorities at once (to increase trust and resilience).

Asking a user to repeatedly click "Log In with Discord" across five different IA websites is terrible UX. Evidence Sharing solves this by allowing users to securely transfer the cryptographic proof of their OAuth session from one IA to another.

How it Works: The evidence Tag​

When a user performs the initial OAuth flow with the first IA (e.g., zapf.app), that IA acquires an Access Token from the provider (like Discord).

Instead of hoarding that token, the IA constructs an evidence JSON object containing the token and metadata. It then encrypts this object using NIP-44 directed at the user's Nostr public key.

This encrypted string is attached to the IA's Kind 35522 Attestation:

["evidence", "nip44_encrypted_payload_only_readable_by_user"]

The Cross-IA Verification Flow​

If the user wants a second IA (e.g., community.ia) to also attest to their Discord identity without doing another OAuth flow:

  1. Decrypt: The user's client decrypts the evidence payload from the first IA's Kind 35522 using their own private key.
  2. Re-encrypt: The client re-encrypts that exact same JSON evidence payload—this time addressing it to the public key of the second IA (community.ia).
  3. Submit: The client submits this freshly encrypted payload to the new IA's endpoint.
  4. Verify: The second IA decrypts the payload, extracts the raw Discord Access Token, and makes an API call to Discord (e.g., GET /users/@me).
  5. Issue: If Discord confirms the token is valid and returns the correct discord_id, the second IA instantly signs its own Kind 35522 Attestation and publishes it.

The user now has two valid attestations from two different IAs, having only clicked "Login" once.

Limitations: OTP-Based Providers​

[!WARNING] Evidence Sharing only works for OAuth providers (like Discord, X, GitHub) that issue long-lived, portable Access Tokens.

LIDPs that rely on One-Time Passwords (OTP)—such as Email and Phone (RCS)—do not generate portable tokens. The verification event is ephemeral.

Because there is no valid token to put inside the evidence payload, OTP-based LIDPs cannot share evidence. If a user wants to prove their Email address to a second IA, they must execute a fresh OTP flow directly with that specific IA.