secp256k1 support

[lemoustachiste]

Hi,

the spec mentions secp256k1 support (https://trustoverip.github.io/tswg-did-method-webs-specification/#secp256k1), but there does not seem to be such an option available in the code. Did I miss it?

Secondary question on the matter, would/will it be possible to create a did:webs for an existing (secp256k1) key?

And last question, this currently seems to be the only open source code implementation of the did:webs spec, am I correct do did I also miss this in my research?

Thanks

[2byrds]

Hi,

the spec mentions secp256k1 support (https://trustoverip.github.io/tswg-did-method-webs-specification/#secp256k1), but there does not seem to be such an option available in the code. Did I miss it?

Secondary question on the matter, would/will it be possible to create a did:webs for an existing (secp256k1) key?

And last question, this currently seems to be the only open source code implementation of the did:webs spec, am I correct do did I also miss this in my research?

Thanks

@lemoustachiste it should be possible. The CESR spec provides support. Keripy provides supports and has test examples like this. The KERI community often uses ed25519 so we did the same. But we'd be interested if you find code restricting the use of secp256k1.
This is the only reference implementation that I'm aware of.

[lemoustachiste]

Thanks, I'll explore that route

[lemoustachiste]

May I maybe point to this issue I opened in the keri repo, it seems it overlaps between the 2 libraries with this one here so maybe you'll have some insights that will unblock me: WebOfTrust/keripy#825

Thanks

[lemoustachiste]

@2byrds following your comment on the keripy repo, I've tried to pull the thread on the verfer object instance.

It seems that the Habery kerver property which comes from the db property as instantiated here https://github.com/WebOfTrust/keripy/blob/3febc54a463125a4cc3d86d694e57004134b2092/src/keri/app/habbing.py#L211C9-L211C16 holds references to Ed25519 rather than the desired secp256k1:

obj.__dict__ = {'_code': 'D', '_size': None, '_raw': b':p\x01q\xe1U\x85P-\x0f3?\x8f:\xef;Z\x15\xb2\xc7\xacE\xe9x\xe2R\xb9\xaa3\x84D]', '_verify': <function Verfer._ed25519 at 0x7f3690824af0>}

as shown in the MatterCodex:

obj.Codex = MatterCodex(Ed25519_Seed='A', Ed25519N='B', X25519='C', Ed25519='D'...

As opposed to what I suppose should be 1AAB for ECDSA_256k1 in the same Codex.

I've pushed further the investigation and it seems that this is set up at the kli incept command, which does not seem to accept a code parameter, but could potentially inject it into the Habery instance, which I would need to test out tomorrow.

So at this point it looks more like an issue at KERI level than at the did-webs-resolver level.

I will try to see if it's fixable.