search

hyperledger-labs / did-webs-resolver

A reference implementation for the did:webs DID method specified here https://github.com/trustoverip/tswg-did-method-webs-specification. The original work for the reference impl started here https://github.com/WebOfTrust/did-keri-resolver
Apache License 2.0
11 stars 10 forks source link

secp256k1 support #75

Open lemoustachiste opened 3 months ago

lemoustachiste commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

Thanks, I'll explore that route

lemoustachiste commented 3 months ago

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: https://github.com/WebOfTrust/keripy/issues/825

Thanks

lemoustachiste commented 3 months ago

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