Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for didResolutionMetadata and didDocumentMetadata #79

Closed
oed opened this issue Feb 25, 2021 · 5 comments
Closed

Add support for didResolutionMetadata and didDocumentMetadata #79

oed opened this issue Feb 25, 2021 · 5 comments
Labels
enhancement New feature or request spec more parties need to agree

Comments

@oed
Copy link
Contributor

oed commented Feb 25, 2021

According to did-core a resolver function should have the following abstract form:

resolve(did, resolutionOptions) →
   « didResolutionMetadata, didDocument, didDocumentMetadata »

Currently the function signature for this library looks like this:

resolve(did: string): Promise<DIDDocument>

We should introduce a breaking change that adds support for returning didResolutionMetadata and didDocumentMetadata.
It should be possible to implement this in a way in which all resolvers won't break with the new version of this package, but won't provide additional metadata until they implement the new interface.

The new function signature would look something like this:

interface ResolutionResult {
  didDocument: DIDDocument
  didResolutionMetadata: DIDResolutionMetadata
  didDocumentMetadata: DIDDocumentMetadata
}

resolve(did: string, resolutionOptions: ResolutionOptions): Promise<ResolutionResult>
@mirceanis mirceanis added the enhancement New feature or request label Feb 25, 2021
@mirceanis
Copy link
Member

Yes, thank you for flagging this!
Do you plan to contribute a PR to fix this?

@oed
Copy link
Contributor Author

oed commented Feb 25, 2021

I'm planning to do that yes! :)

@oed
Copy link
Contributor Author

oed commented Mar 1, 2021

To reduce complexity, ensure spec compliance and code readability, I will likely make this a breaking change without backwards compatibility. This means that all method specific resolvers would need to be changed in order to support the new version.

@mirceanis
Copy link
Member

mirceanis commented Mar 1, 2021

A breaking change is unfortunate, but if it is indeed necessary it should not be a show-stopper.
I look forward to your PR :)

Do you have an example of the change required?

uport-automation-bot pushed a commit that referenced this issue Mar 2, 2021
# [3.0.0](2.2.0...3.0.0) (2021-03-02)

### Features

* update resolve method signature to match did core spec ([#82](#82)) ([313e685](313e685)), closes [#79](#79)

### BREAKING CHANGES

* the `Resolver` and `DIDResolver` data types have been upgraded.
To use a legacy resolver that simply returns a `DIDDocument`, please register it under the `options.legacyResolvers` constructor param
@uport-automation-bot
Copy link
Collaborator

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@uport-automation-bot uport-automation-bot added the spec more parties need to agree label Mar 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request spec more parties need to agree
Projects
None yet
Development

No branches or pull requests

3 participants