General question about importing private keys for did:ethr

[Ajmasta]

Hello, thanks again for all your help and advice. Having read up on the various discussion in this Github, I was able to create a private key and importing it as a DID. I just want to make sure what I'm doing is right.

import 'react-native-get-random-values'; /// ethers recommends importing this line for react native but not sure if it's important in this case.
import '@ethersproject/shims';
import {randomBytes} from '@ethersproject/random';
import {SigningKey} from '@ethersproject/signing-key';
import {computeAddress} from '@ethersproject/transactions';
import {IDIDManagerAddServiceArgs} from '@veramo/core';
import * as u8a from 'uint8arrays';
import {TKeyType} from '@veramo/core';
import {agent} from './veramo';

export const createAndImportDid = async () => {

  const privateBytes = randomBytes(32);
  const keyPair = new SigningKey(privateBytes);
  const publicKeyHex = keyPair.publicKey.substring(2);
  let privateKeyHex = u8a.toString(privateBytes, 'base16');
  const address = computeAddress('0x' + privateKeyHex);
  const identifier = `did:ethr:rinkeby:${address}`;

  try {
    const didCreation = await agent.didManagerImport({
      services: [],
      provider: 'did:ethr:rinkeby',
      did: identifier,
      controllerKeyId: keyData.kid,
      keys: [
        {
          kid: keyData.kid,
          kms: 'local',
          type: <TKeyType>'Secp256k1',
          publicKeyHex: keyData.publicKeyHex,
          privateKeyHex: keyData.privateKeyHex,
        },
      ],
    });
 
  } catch (err) {
    console.log(err);
  }
};

This gives me this result:

{ services: [],
                             │ provider: 'did:ethr:rinkeby',
                             │ did: 'did:ethr:rinkeby:0x26D32C27270c29E74D37b174D0E16E44Df6c6682',
                             │ controllerKeyId: '045782ab02495529df136ede532f0cda3396d74817d783ec81afe425375e0568f143922dc0b4d0bab1a9aae4a7ae37af10038e08a123eb8274ee67d32f8f2ed5df',
                             │ keys:
                             │ [ { type: 'Secp256k1',
                             │ kid: '045782ab02495529df136ede532f0cda3396d74817d783ec81afe425375e0568f143922dc0b4d0bab1a9aae4a7ae37af10038e08a123eb8274ee67d32f8f2ed5df',
                             │ publicKeyHex: '045782ab02495529df136ede532f0cda3396d74817d783ec81afe425375e0568f143922dc0b4d0bab1a9aae4a7ae37af10038e08a123eb8274ee67d32f8f2ed5df',
                             │ meta:
                             │ { algorithms:
                             │ [ 'ES256K',
                             │ 'ES256K-R',
                             │ 'eth_signTransaction',
                             │ 'eth_signTypedData',
                             │ 'eth_signMessage' ] },
                             └ kms: 'local' } ] }

There's two issues when I do that. The did works well and is able to be resolved when I use the address in the did identifier. But, when I use the public key it just doesn't work, did:ethr:rinkeby:0x${publicAddressHex}. The did is way too long and does not resolve. Did I do something wrong when computing the public key? I tried looking for a special formatting of a public key for did:ethr but I was unsuccessful.

Second, when I try to update one of these created DIDs, at first it seems to just freeze and not work. No matter how long I wait the transaction seems to never get sent. And then, when I try to send it again, I get the error

 { [Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":52,\"error\":{\"code\":-32000,\"message\":\"already known\"}}"

It looks like the already known error happens when a similar transaction is already on the blockchain. So, it seems like the first time the transaction is sent out on the blockchain, but I can't find it anywhere (etherscan or others), and not matter how long I wait it just doesn't seem to get resolved. Here is my sample code to update a did:

const updateDid= () => {
 try {
const options = {
      did: 'did:ethr:rinkeby:0x2c1C8A258349358fedDc93D5C5e537604874F40B',
      service: {
        id: 'localhost-',
        type: 'DIDComm',
        serviceEndpoint: 'http://localhost:1/foobar',
        description: 'endpoint ',
      },
    }
    const result = await agent.didManagerAddService(options);
    console.log('Success!');
    return result;
  } catch (err) {
        console.log(err)
    }
  }
}

I am wondering if the two issues are related? Is there something abnormal in my did creation? It should be noted that when I import the private key in a wallet like Metamask, I get the exact same address as the one I compute. It's really just my Public Key that doesn't seem to be working properly. Maybe I'm missing/misunderstanding something as all of this is very new to me.

[mirceanis]

You are doing everything almost perfectly, kudos!

The issue with the public key can be fixed by using a compressed public key, since that's what did:ethr requires.
You can get a did:ethr from a SigningKey like so:

  const keyPair = new SigningKey(privateBytes);
  const identifier = `did:ethr:rinkeby:${keyPair.compressedPublicKey}`;
  // It's useful to also get the address at this point since it must be funded to be able to update DID
  const address = computeAddress(keyPair.publicKey);
  console.log(`send Rinkeby ETH to ${address} to be able to update ${identifier}`);

For the second issue, I can see the update for your DID on-chain: https://rinkeby.etherscan.io/tx/0x0cd66a2d7d74c0e4299e692eedd6ed31158d15c8e39f8572d8cfd40c4385950f.
Your DID is using Rinkeby to anchor updates, perhaps you were looking at a different ethereum network, or maybe just delays on rinkeby?
Anyway, I don't think the two issues are related.

I hope this helps

[Ajmasta]

Thank you so much for all the help! Of course ,it was comppressed keys! I am wondering, is there a difference between using the address directly for the did,vs using the compressed key? It seems like using did:ethr:${address} would make it easier for the user to know which address to fund. But is there a downside to doing that?

Thank you for checking the network, I probably missed it or it was taking a very long time indeed.

[mirceanis]

There is a benefit when you use the public key, which is that there are more algorithms available for signing.
The ethereum address is technically only usable for ES256K-R JWTs and EcdsaSecp256k1RecoveryMethod2020 JSON-LD credentials.
When you use the public key variant, you get access to those first 2 plus ES256K and EcdsaSecp256k1Signature2019, and a few others out of the box. (yeah, I know, these names are loooong and cryptic :) )
Also, theoretically, that type of public key can also be used for encryption (although it's not recommended for this purpose).

The good news is that both variants are backed by the same entry in the ERC1056 registry, so when you update the did document for one, the same update shows up in the other variant.

I hope this helps

[Ajmasta]

Thank you for the complete answer! Everything makes sense now.