Re: Call for Co-Editors: Post-Quantum Migration Pattern for Verifiable Credentials (Ed25519 + ML-DSA Dual-Signature Model)

Hi Ramprasad,

Thank you for the email.

I would encourage everyone who is interested in serving as a co-editor or
contributor to leave a comment on the issue expressing their support and
interest. Since the proposed work item is expected to progress
asynchronously, this will help demonstrate community engagement and
identify the initial group of participants.

Given the importance of cryptographic continuity as the ecosystem
transitions toward post-quantum cryptography, it would be valuable to
establish broad participation from the outset. This is a cross-cutting
topic that affects the long-term verifiability and interoperability of
digital credentials and identity systems, so input from a diverse set of
stakeholders will help ensure the work is practical and widely applicable.

Once the Chairs determine that the proposal is suitable for adoption and a
repository is created, the work will begin with a minimal document and
evolve incrementally through community contributions and consensus.


Best regards,

Amir Hameed Mir



On Sun, 12 Jul 2026 at 4:06 AM, Ramprasad G <ram@vouch-protocol.com> wrote:

> Hi Amir, all,
>
> I'd like to volunteer as a co-editor.
>
> I maintain Vouch Protocol (the continuous state verifiability work some of
> you saw on this list in June), and its post-quantum profile is built
> exactly the way this thread converged: parallel proof sets, two independent
> Data Integrity proofs over the same canonicalized payload, eddsa-jcs-2022
> alongside an ML-DSA-44 suite. There is no combined signature anywhere;
> either proof verifies on its own, which I think is the property Manu is
> pointing at with proof sets.
>
> Concretely, I can bring:
>
>    1. Working proof-set implementations in Python, TypeScript, Go, Rust,
>    and WebAssembly, kept byte-identical on JCS canonicalization.
>    2. Cross-language test vectors for the eddsa + mldsa44 proof-set
>    combination. Greg noted there are no published examples combining two
>    cryptosuites; ours are JCS-based, so together with Greg's RDFC vectors the
>    guidance could cover both canonicalization paths.
>    3. Verifier-side migration experience: what acceptance policy looks
>    like while some verifiers check only the Ed25519 proof, some check both,
>    and how to keep that transition from quietly degrading into classical-only
>    verification. I think that policy question is the heart of the "operational
>    guidance" scope.
>
> I'll add a note on the work item issue as well. Happy to align the vectors
> with vc-di-quantum-resistant-1.0 (we're on ML-DSA-44 with the 0x1210
> multikey encoding, so the overlap should be clean) and to work
> asynchronously through GitHub as you proposed.
>
>
> Cheers,
>
> Ramprasad Anandam Gaddam
>
> Vouch Protocol, https://vouch-protocol.com
>
>
>