Is your feature request related to a problem?

when constructing a document, we manipulate the original did by cloning and modify the parts of the DID-URL as necessasry. For instance, the code to set a controller account is as follows:

/// Set the controller of the document
    pub fn controller(&mut self, controller: &Address) -> Result<()> {
        let mut did = self.id.clone();
        // TODO: Include a `set_id` method on `DidUrl
        did.set_path(&format!("ethr:0x{}", hex::encode(&controller)))?;
        self.controller = Some(did);
        Ok(())
    }

Here, we clone the original did, format a did path parameter, and then set the documents controller to this DID.

This isn't the best, because by passing a formatted path in the form of ethr:controller_address, DidUrl re-parses this path even though we already have Method and ID types parsed.

For usability/general enhancment, it would be better to provide a set_id method on DidUrl which can directly manipulate the ID of a did. We must also ensure that the underlying Url representation of the did contains this new address (simply assigning method.id.public_key won't change how the address is serialized to JSON because the underlying URL type still contains this address).

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

Add code coverage via cargo-llvm-cov

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

We will generally be running the gateway as a dockerfile deployment or otherwise, so it will be easier to set environment variables rather than CLI Arguments. Environment variables are better if we ever need to set an APIKEY for our ethereum provider, since these variables may be encrypted secrets. Additionally we can change the arguments without rebuilding the docker image.

didethresolver currently defines two command line arguments in it's lib.rs:

#[derive(FromArgs)]
/// DID Ethereum Resolver XMTP Gateway
struct DidEthGatewayApp {
    /// the address to start the server
    #[argh(option, short = 'a', default = "String::from(\"127.0.0.1:9944\")")]
    address: String,

    /// ethereum RPC Provider
    #[argh(
        option,
        short = 'p',
        default = "String::from(\"wss://eth.llamarpc.com\")"
    )]
    provider: String,
}

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Describe the bug

mainnet reported on sepolia

$ curl -H "Content-Type: application/json" -d '{"id":"1", "jsonrpc":"2.0", "method":"did_resolveDid", "params":{ "publicKey":"0x12345679abcdef" }}' http:///localhost:8080

{
  "jsonrpc": "2.0",
  "result": {
    "didDocumentMetadata": {
      "deactivated": false,
      "versionId": 4918526,
      "updated": "2023-12-19T17:54:12Z"
    },
    "didResolutionMetadata": {
      "contentType": "application/did+ld+json"
    },
    "didDocument": {
      "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/ed25519-2020/v2"
      ],
      "id": "did:ethr:mainnet:0x12345679abcdef",
      "verificationMethod": [
        {
          "id": "did:ethr:mainnet:0x12345679abcdef#controller",
          "controller": "did:ethr:mainnet:0x12345679abcdef",
          "type": "EcdsaSecp256k1VerificationKey2019",
          "blockchainAccountId": "0x12345679abcdef"
        }
      ]
    }
  },
  "id": 1
}

Expected behavior

RPC connection should be used for default network information or network should not be defaulted when it is not known.

Steps to reproduce the bug

No response

Is your feature request related to a problem?

initial terraform scripts/deployment

resolveDid method is different from documentation. This needs some cleanup. A command line example would also be nice.

Is your feature request related to a problem?

Please setup an initial gateway service skeleton. The initial implementation can be simplified as we will continue evolve the feature set based on our project requirements.

Minimum Requirements:

1. JSON RPC – DID is a json specification thus we must be able to resolve json documents
2. composability – This project will go though our iterative development process and should be easy to change
3. testing – blanket testing and the ability to test is a baseline
4. documentation - methods and modules should be documented

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

The did:ethr specification indicates that all addresses are case-insensitive, but that blockchain_account_id may be represented according to EIP-55. It may be advantageous to do so:

https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md#method-specific-identifier

EIP-55 describes a way of checksummed public keys: https://eips.ethereum.org/EIPS/eip-55

This representation is only relevant to the outputted DID Document, but does not have to be represented as such internally.

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Describe the bug

No attributes in did document. Error occurred.

unhandled or malformed attribute name=did/svc/MessagingService,value=https://xmtp.com/resolver
2024-02-13T19:13:26.519603Z WARN lib_didethresolver::types::ethr: unhandled or malformed attribute name=did/pub/Ed25519/veriKey/base58,value=041daed68ecce73f9193c88989ca2e252f575d83dcedd66e1200eda9979db52d4e732030093aa2fa0ca8bf29269e6097534c81d15c521758447918cf2179191a83

Expected behavior

Document should contain both did/svc and did/pub

Steps to reproduce the bug

No response

Is your feature request related to a problem?

No response

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

Split didethresolver between its gateway parts and its library parts to make did:ethr resolution re-usable in xps-gateway

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

Currently, we don't handle the case where an owner address has been deactivated. Instead of handling it, we return a log :

if event.owner == Address::from_str(NULL_ADDRESS).expect("const address is correct") {
    log::warn!("Address has been deactivated. not implemented");
}

We need to handle this case according to the did:ethr specification

reference implementation

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

The implementation might already be there, as it was added in #21 , but it's unclear whether it's working correctly or not. A test need to be added, which verify the correct behavior.

Blocked on deployment of did:ethr to mainnet

Is your feature request related to a problem?

using a proper bytes type makes Vec<u8> easier to work with and avoids a class of bugs resulting from incorrect hex string conversions. Related to xmtp/xps-gateway#71

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Introduce yaml lint

Is your feature request related to a problem?

The DidUrl parser uses URL crate to assist parsing but it's problematic as specified here. uri crate doesn't work for our case as well.

Describe the solution to the problem

So we will need to write our own parser grammar in order to properly parse a did url with optional path, query and fragment like this:
"did:ethr:0xb9c5714089478a327f09197987f16f9e5d936e8a/path?query=q#fragment"

Describe the uses cases for the feature

We may need to accommodate other did format, but for now the feature would be more than enough.

Additional details

lyn might be a good reference.

Is your feature request related to a problem?

Introduce GitHub pages to this repo

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

Revoked attributes should not be present in the resulting DID document. Handling of revoked attributes is described in the did:ethr spec

• https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md#delete-revoke

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

the did:ethr spec defines a way to version DID's. the didethresolver should handle version_ids according to this spec. There is a reference implementation of these versionIds here

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

We are typically calling resolveDid with an address rather than a publicKey so it makes sense to use address here.

• update api
• update docs

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

Is your feature request related to a problem?

Our project aim is to produce exceptional documentation and test coverage. Let's enable the rust coverage so that we can monitor this.

Describe the solution to the problem

No response

Describe the uses cases for the feature

No response

Additional details

No response

depend on ci-image in pages build for integration testing

Discussed in #3

POST /api/v1/resolveDid

{
  "publicKey": "0x123abc..."
}

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "controller": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
  "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
  "service": [
    {
      "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "recipientKeys": "0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "serviceEndpoint": "https://xmtp.com/resolver",
      "type": "MessagingService"
    }
  ],
  "verificationMethod": [
    {
      "controller": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "id": "did:ethr:0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "publicKeyMultibase": "0x6CEb0bF1f28ca4165d5C0A04f61DC733987eD6ad",
      "type": "Ed25519VerificationKey2020"
    }
  ]

{
  "error": "Invalid public key format"
}