- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Wed, 19 Feb 2025 16:14:29 +0100
- To: Will Abramson <wip.abramson@gmail.com>
- Cc: Credentials Community Group <public-credentials@w3.org>, rgrant@rgrant.org
- Message-ID: <CAKaEYhJ7Xdm5tZcj7ZzkNans2ONL9HtsL4k4+TAYmdQvHOVkDA@mail.gmail.com>
st 19. 2. 2025 v 16:08 odesÃlatel Will Abramson <wip.abramson@gmail.com> napsal: > Hi all, > > I want to announce a new Data Integrity Cryptosuite that Digital Contract > Design and Legendary Requirements have been developing as part of an effort > to create a new and improved Bitcoin based DID method. > > As many of you may know, Bitcoin uses secp256k1 keys to authorize Bitcoin > transactions. It initially supported ECDSA signatures, but in the last few > years it has added support for Schnorr signatures. > > We wanted to enable these secp256k1 keys, which have extensive adoption > and library support, to be usable within DIDs and VCs. Specifically, > enabling a secp256k1 key could be included in a DID document as a > verificationMethod and used to create proofs on documents like a VC. > > While there have been some earlier attempts to support secp256k1 keys and > proofs, these all appeared outdated and not really maintained. > > This specification: > https://dcdpr.github.io/data-integrity-schnorr-secp256k1/ > <https://dcdpr.github.io/data-integrity-schnorr-secp256k1/> > > Is a draft of a Cryptosuite for producing Data Integrity proofs using > Schnorr signatures with Secp256k1 keys according to the latest proposed > recommendations from the VCDM. > > We chose to support Schnorr signatures rather than ECDSA because of its > better security and efficiency characteristics (See > https://hashpire.io/garden/EdDSA_vs_ECDSA_vs_Schnorr for a good short > overview). As well as its ability to support multisig - which needs some > more thought about how exactly to describe (if you want to) a > verificationMethod is a multisig. As well as how to produce a multisig > proof. Interestingly however, verifying a multisig Schnorr Data Integrity > proof would be exactly as described in this current specification. The > verifier would not, and does not need to, know how the proof was created. > > As you can see from our resository - > https://github.com/dcdpr/data-integrity-schnorr-secp256k1 - this > specification started from the EdDSA Cryptosuite specification and changed > it to be specific to Schnorr Secp256k1. So much of the work was already > done by the community and the VCDM - thank you for that! I hope it is okay > that I borrowed from this excellent starting point. > > One aspect of the spec that is worth drawing attention to is our > definition of the secp256k1 x-only Multikey prefix - > https://dcdpr.github.io/data-integrity-schnorr-secp256k1/#multikey. > Should this be registered somewhere else? From the CID spec, it states > anyone can define their own Multikey prefix so I figured this would be > okay. But clearly we wouldn't want other keys to also use the same value > > This is still very much a draft and we would welcome any external > contributions from those interested in supporting this specification. > > *We intend to propose this as a CCG Work Item and continue developing and > refining the specification under the CCG. * > +1 > > Finally, for those who like to get into the code the repository includes > Jupyter notebooks that walk through an implementation of the Cryptosuite > step by step - > https://github.com/dcdpr/data-integrity-schnorr-secp256k1/tree/main/notebook_examples > <https://github.com/dcdpr/data-integrity-schnorr-secp256k1/tree/main/notebook_examples> > > There is also a very rough stab at a Python library for adding Data > Integrity proofs to documents using the Schnorr secp256k1 Cryptosuite - > https://github.com/LegReq/di-schnorr-secp256k1-python. > > Would love to hear what people think, especially if folks are interested > in helping to move this work forward. > You may be aware of the Nostr project, which uses taproot and schnorr, to create a social network. I chair the nostr community group at the w3c [1], and we have been thinking about registering a DID method for a while. We have also begun some early work on web authentication using schnorr signatures [2]. Perhaps there would be some overlap. Looking forward to following your work. [1] https://www.w3.org/community/nostr/ [2] https://nostrcg.github.io/http-schnorr-auth/ > > Thanks, > Will > > > > > >
Received on Wednesday, 19 February 2025 15:14:47 UTC