support for deterministic secp256k1 key (part 2)

[lemoustachiste]

My last issue (#825) was marked as completed here as it could have been linked to the did:webs implementation, and I cannot reopen and add to it.

After more research on the matter, I'm pretty sure the issue lies with Keri, and probably with my own understanding of the architecture required to achieve a proper JWK representation of my keys.

First I have noticed that the incept command does not allow for specifying the type of key and defaults to Ed25519 as invoked from here: https://github.com/WebOfTrust/keripy/blob/main/src/keri/app/cli/commands/incept.py#L167 which cascades all the way down to this default: https://github.com/WebOfTrust/keripy/blob/3febc54a463125a4cc3d86d694e57004134b2092/src/keri/app/keeping.py#L928

I was able to fix that by allowing specifying icode to the incept args.

But that seems to be only one part of the issue and I think my problem lies earlier in the process.

If I understand the concept correctly the salt is the same as a seed, which I am expecting, either correctly or not, to be the same BIP-32 seed I am deriving from my mnemonic.

However it seems that I am stuck on getting the right format. If I use the Salter class with a raw of my seed, it comes back prefixed by 0A (Salt_128), and not what I would suppose should be J (ECDSA_256k1_Seed). And I cannot specify a code as only Salt_128 is supported (https://github.com/WebOfTrust/keripy/blob/3febc54a463125a4cc3d86d694e57004134b2092/src/keri/core/signing.py#L402).

Am I wrong in trying to use the Salt to init my Keri config as presented in this guide: https://github.com/peacekeeper/did-webs-iiw37-tutorial?tab=readme-ov-file#create-aid?

Could someone break down the process of action so I can get my expected secp256k1 key representation within the KERI infrastructure?

Thanks