- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 2 Aug 2025 20:21:21 +0200
- To: Will Abramson <wip.abramson@gmail.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAKaEYh+ah0C9CWFkYchCOrK8yHiNdiSOyZa1zzOxOVWHVy3JSQ@mail.gmail.com>
čt 31. 7. 2025 v 18:13 odesílatel Will Abramson <wip.abramson@gmail.com> napsal: > Hello CCG community, > > Digital Contract Design in collaboration with Legendary Requirements and > Danube Tech are proposing a new CCG Work Item for adoption: > https://dcdpr.github.io/data-integrity-schnorr-secp256k1/ > > See the proposal issue here: > https://github.com/w3c-ccg/community/issues/254 > > We feel this is important as there are currently no up to date Data > Integrity cryptosuites available for the secp256k1 curve, which has wide > adoption throughout multiple blockchain ecosystems. > -1 Thanks for the proposal. I’ve long advocated for secp256k1 and BIP340 support, and I appreciate the work being done here. That said, I have a strong concern: the current specification mandates Multibase encoding for keys, which breaks compatibility with millions of deployed identifiers in the Bitcoin and Nostr ecosystems. These ecosystems overwhelmingly use lowercase hex as the canonical key representation, not Multibase or Multikey. Introducing Multibase as a hard requirement creates an unnecessary and incompatible fork in identity representations. If the goal is adoption across real-world BIP340 deployments, the spec needs to offer flexibility in encoding, specifically, native support for raw hex. If there’s a path to accommodate this (e.g., via a publicKeyHex field or alternate verification method type), I’d be happy to support and contribute. But pushing existing infrastructure to adopt a new encoding format unilaterally, especially without a clear migration strategy, feels like a misstep. So in its current form, this is a -1 from me. > > Thanks, > All the best, > Will Abramson >
Received on Saturday, 2 August 2025 18:21:38 UTC