Skip to main content

Other OAuth Providers

As an open protocol, Zapf is designed to be extensible. Independent Zap Settlement Providers (ZSPs) can implement any number of external OAuth Legacy Identity Providers (LIDPs) to support niche communities or enterprise users.

Common targets include:

  • GitHub (github)
  • Google Authenticated Profiles (google)
  • LinkedIn (linkedin)
  • Reddit (reddit)

Standardization Rules​

If a ZSP operator implements a new OAuth provider, they must adhere to the standard Zap Protocol conventions.

1. Unified Prefixing​

The lidp name MUST be short, lowercased, and appended with a colon before the identifier to create the raw string. Example: github:flzpace

2. Immutable Identifiers​

The chosen identifier must be guaranteed permanent by the underlying platform. For GitHub, the username is changeable, so a ZSP should hash the numeric user ID (e.g., github_id:12345) to prevent account takeover vectors, even if the client UI resolves handles for UX purposes.

3. Shareable Evidence Payloads​

Because these are OAuth providers, the ZSP MUST package the resulting access_token into a securely encrypted ↗ evidence payload. This allows the user to securely execute Evidence Sharing with other ZSPs in the ecosystem without needing to constantly re-authenticate.

Securing Evidence Payloads​

For any generic OAuth provider, the internal evidence payload structure is standardized across Zapf implementations. It fundamentally consists of the raw OAuth Access Token and its associated expiry/scope metadata. Because these tokens grant limited read access to third-party providers, they are strictly protected via NIP-44 ↗ encryption.