xmtp / didethresolver

XMTP Registry Resolver
MIT License
3 stars 1 forks source link

Add version_id support #21

Closed tsachiherman closed 9 months ago

tsachiherman commented 9 months ago

What ?

This PR add the support for version_id as part of the resolver implementation.

More details

The DID document specifications is described https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md. The changes here convert the return type from DidDocument into a DidResolutionResult. The difference is this:

pub struct DidResolutionResult {
    #[serde(
        default,
        rename = "didDocumentMetadata",
        skip_serializing_if = "Option::is_none"
    )]
    pub metadata: Option<DidDocumentMetadata>,
    #[serde(
        rename = "didResolutionMetadata",
        skip_serializing_if = "Option::is_none"
    )]
    pub resolution_metadata: Option<DidResolutionMetadata>,
    #[serde(rename = "didDocument")]
    pub document: DidDocument,
}

So that a DidResolutionResult provides additional information regarding the document. In particular, it provides versioning information.

To take advantage of that, the resolver also support requesting a particular version. That version can be provided as the second argument :

> curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "did_resolveDid", "params": ["0x423B6F365C14F4b233928088FF937e01c143A328","4930857"]}' http://localhost:9944 | jq

result by

{
  "jsonrpc": "2.0",
  "result": {
    "didDocumentMetadata": {
      "deactivated": false,
      "versionId": 4930857,
      "updated": "2023-12-21T15:43:00Z",
      "nextVersionId": 4930891,
      "nextUpdate": "2023-12-21T15:50:48Z"
    },
    "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:0x423b6f365c14f4b233928088ff937e01c143a328",
      "verificationMethod": [
        {
          "id": "did:ethr:0x423b6f365c14f4b233928088ff937e01c143a328#controller",
          "controller": "did:ethr:0x423b6f365c14f4b233928088ff937e01c143a328",
          "type": "EcdsaSecp256k1VerificationKey2019",
          "blockchainAccountId": "0x423b6f365c14f4b233928088ff937e01c143a328"
        }
      ]
    }
  },
  "id": 1
}
codecov-commenter commented 9 months ago

Codecov Report

Attention: 20 lines in your changes are missing coverage. Please review.

Comparison is base (749f7c1) 91.79% compared to head (a94ecaf) 91.25%.

Files Patch % Lines
src/lib.rs 0.00% 13 Missing :warning:
src/resolver.rs 94.94% 5 Missing :warning:
src/types/ethr.rs 60.00% 2 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #21 +/- ## ========================================== - Coverage 91.79% 91.25% -0.54% ========================================== Files 11 11 Lines 1194 1292 +98 ========================================== + Hits 1096 1179 +83 - Misses 98 113 +15 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

tsachiherman commented 9 months ago

Looks good to me. One note about process, you should be able to directly create branches in the xmtp/didethresolver repo and PR from there. Let me know if GitHub permissions forced you to fork the repo. Your GitHub user may not be in the right group. IT should be able to fix that.

That was done very much on purpose, so that we won't "spam" the public repository with intermediate branches. Creating shared branches are good practice when we have multiple individuals contributing to the same branch, but aren't really designed for scalability. ( i.e. it would add the role of "cleanup officer" ).

That's the reason why most large organizations that promotes external contributions would allow PR to be created only from a fork.