فا
← BACK TO THE WIRE
N°0227ZK Tech2 MIN2 SOURCES

The Protocol Became the Product: Longfellow ZK Moves Identity Proofs Toward a Shared Wire Format

Google’s Longfellow ZK project has reached a new interoperability milestone: its proof system is now described in a July 2026 IETF Internet-Draft, while the open-source implementation targets existing identity formats such as ISO mdoc, JWT, and W3C Verifiable Credentials.

SHARE
ZK Tech
The Protocol Became the Product: Longfellow ZK Moves Identity Proofs Toward a Shared Wire Format
IMAGE: AI-GENERATED

Zero-knowledge identity work is moving from isolated libraries toward shared protocol machinery. On July 22, 2026, Google-authored Longfellow ZK appeared as an IETF Internet-Draft describing an algorithm for generating and verifying succinct non-interactive zero-knowledge arguments.

The important development is not simply another proving system. Longfellow is designed around the formats identity systems already use. Google’s public repository says the library can construct proofs concerning ISO mdoc credentials, JSON Web Tokens, and W3C Verifiable Credentials. That makes the project relevant to builders who need privacy-preserving claims without replacing every credential issuer and verifier in their stack.

The draft combines two major components. A Ligero-style commitment system handles zero-knowledge arguments for linear and quadratic constraints, while a sumcheck-based verifiable-computation protocol proves that a circuit evaluates correctly. Fiat–Shamir turns the interactive construction into a single-message proof suitable for deployment.

The design also targets a familiar ZK trade-off: reducing setup assumptions without making the system unusable. The draft says Longfellow does not require a common reference string or trusted parameter setup, and focuses on constructions instantiable from collision-resistant hash functions. That does not make the system assumption-free; security still depends on the protocol analysis, parameter choices, implementation quality, and the underlying cryptographic assumptions.

For developers, the practical signal is the combination of specification and code. The IETF draft includes serialization rules and test vectors, while the repository provides build instructions, benchmarks, a reference verifier service, and a Rust directory alongside the core library. Those pieces give implementers more than a research description: they provide an emerging target for compatibility testing.

There are two reasons to keep expectations measured. First, the IETF page labels the document Informational and says Internet-Drafts are temporary working documents that may be updated, replaced, or obsoleted. It is a protocol proposal, not a completed Internet standard. Second, the repository states that two independent security reviews are still underway. Longfellow should therefore be evaluated as an active engineering and standardization effort, not as a finished production trust anchor.

The broader shift is architectural. If identity proofs can be expressed against credentials that organizations already issue, ZK adoption becomes less about inventing a new identity stack and more about adding a private proof layer around existing data. Longfellow’s next test is whether that emerging wire format and implementation can survive interoperability work, cryptographic review, and real deployment constraints.

TAGSZero-Knowledge ProofsLongfellow ZKPrivacy-Preserving IdentityIETF
Grounded sources2 REFS
  1. [01]Longfellow ZK — IETF Internet-Draftietf.org
  2. [02]Longfellow ZK — Google Open-Source Repositorygithub.com
Read next

Get the wire in your inbox

Every new signal, straight from the generator. No noise, unsubscribe anytime.

RSS AVAILABLE · NO SPAM