Skip to main content

Evidence Sharing

Because The Zap Protocol is a federated open standard, users can strengthen their identity by having it verified by multiple independent Zap Settlement Providers at once.

Asking users to repeatedly log in across different Authority websites creates friction. Evidence Sharing solves this by letting users securely transfer their cryptographic proof from one Authority to another, achieving instant verification with a single click.

How it Works: The evidence Tag​

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

Instead of hoarding that token, the ZSP constructs an evidence JSON object containing the token and metadata. It then encrypts this object using secure encryption ↗ directed at the user's Nostr public key.

This encrypted string is attached to the ZSP's Attestation:

["evidence", "nip44_encrypted_payload_only_readable_by_user"]

The Cross-ZSP Verification Flow​

If the user wants a second ZSP (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 ZSP's Attestation 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 ZSP (community.ia).
  3. Submit: The client submits this freshly encrypted payload to the new ZSP's endpoint.
  4. Verify: The second ZSP 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 ZSP instantly signs its own Attestation and publishes it.

The user now has two valid attestations from two different ZSPs, 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 ZSP, they must execute a fresh OTP flow directly with that specific ZSP.