Draft Schnorr Secp256k1 Cryptosuite for Data Integrity

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. *

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.

Thanks,
Will