Cowrie Research

reclaim-protocol

3 min read

Reclaim Protocol

  • Name: Reclaim Protocol
  • URL: https://www.reclaimprotocol.org/
  • Category: zkTLS web-proof middleware / provider-defined claim system / attestor-backed verification network
  • Summary: Reclaim Protocol packages website-derived proofs into a reusable developer rail. The useful layer is not the zkTLS label by itself. It is the mix of provider definitions, attestors, app integration defaults, and claim templates that turns raw web provenance into something applications can actually consume.
  • What it does:
    • Lets applications verify facts like employment, student status, age, account ownership, reputation, and other website-derived claims without relying on uploaded screenshots or PDFs
    • Uses provider definitions to specify which website interaction matters, which fields are extracted, and what claim is proved from the resulting HTTPS session data
    • Routes proving through client-side flows plus attestor / witness infrastructure rather than treating verification as a pure local cryptography problem
    • Offers SDKs across web, mobile, and blockchain-oriented environments so applications can request and verify claims without building their own proving rail
    • Maintains protocol and infrastructure code through public repositories including the JS SDK, attestor-core, TLS components, and docs repos
  • Key claims:
    • Reclaim’s real contribution is productizing web proofs into a provider marketplace and attestor-backed integration stack. That is more analytically useful than repeating the generic claim that it does zkTLS.
    • The docs make provider authorship a first-class control surface. Someone has to define which request is intercepted, which fields are extracted, and what assertion counts as success. That means proof semantics are partly governance over provider templates, not just cryptography.
    • The attestor / witness layer matters because the system is not merely a prover and a verifier speaking directly. Operational trust accumulates around who runs attestors, how they are selected, and what defaults downstream apps inherit.
    • Reclaim is also useful because it pushes beyond narrow KYC framing. The provider catalog and SDK surface suggest a generalized web-claim rail, where reputation, social, education, employment, and account-state proofs can all ride the same machinery.
    • The project’s own positioning against document-upload verification is directionally right, but the more important corpus point is that Reclaim moves verification power into provider curation, attestor policy, and developer integration defaults.
    • The linked whitepaper and IACR ePrint analysis raise the floor on technical seriousness, but they do not erase the practical chokepoints in provider maintenance, website compatibility, extension / SDK distribution, and attestor operations.
  • Whitepaper: Yes. The official docs link a Reclaim whitepaper PDF and a formal security analysis on IACR ePrint. For practical understanding, the docs portal and public repos remain the clearest primary materials; see ../whitepapers/reclaim-protocol-primary-sources-2026-04-26.md.
  • Sources:

Internal linkages

  • Keep the comparison set tight: tlsnotary, vlayer, and zkTLS Protocol.
  • That is enough. Reclaim is middleware for provider-defined web claims, not a universal map of every identity or proof system.

Control surface

  • The leverage sits in provider definitions, attestor policy, SDK defaults, website compatibility upkeep, and which proof types major apps start treating as normal.

  • So read Reclaim as web-proof middleware with real operator surfaces, not as pure cryptography.

  • Last reviewed: 2026-06-09 UTC

Graph View

Backlinks