Generic "Resolvers"

[decentralgabe]

Create generic resolvers for certain data types, like DIDs, Schemas, Revocations.

Provide an interface with an in-memory implementation at the minimum. A HTTP implementation might also be worth it.

[andorsk]

YES! this is needed. The more I've played with the SDK, the more I've realized this is a kinda big problem that needs to be resolved.

A question also begs which is how we interact with the ecosystem in general. See https://github.com/decentralized-identity/universal-resolver as an example

TBH I'm not a huge fan of the above. It's way to heavyweight for what it's trying to do. Maybe there's a middle ground?

[peacekeeper]

Hello I have a few thoughts on this.

I think it would be very useful to work on integrating ssi-sdk and ssi-service with both the Universal Resolver (https://github.com/decentralized-identity/universal-resolver) and the Universal Registrar (https://github.com/decentralized-identity/universal-registrar). The latter is a not-so-well-known project, but it's essentially the same idea, creating an abstraction layer not only for the DID resolve operation, but also for the create/update/deactivate operations.

With regard to "heavyweight". Yes. Both the Universal Resolver and Universal Registrar are rather heavy-weight container-based applications, so you definitely can't run them on a mobile phone, etc. They are run as services, and therefore can also add an element of centralization that DIDs are not supposed to have.

But, the purpose of these components is still a bit more nuanced than it seems:

• First, they are based on open specifications (DID Resolution, DID Registration) which do not mandate any specific implementation or deployment pattern. They define abstract interfaces that can be implemented in various ways.
• Second, both the Universal Resolver and Universal Registrar can be self-hosted. If you are planning to run something like TBD's ssi-sdk or ssi-service on some backend service, then I think there's nothing wrong with also deploying the Universal Resolver/Registrar side-by-side with that.
• Third, we often see deployment patterns where some DID methods are implemented as part of a local library, and remote Universal Resolver/Registrar services are configured as "fallbacks" when the local library can't handle a certain DID method. For example, TBD's ssi-sdk could handle did:key internally (no need to use any external component), but it could use the Universal Resolver/Registrar for handling did:ebsi or did:indy or did:v1, etc.

This should be configurable, in a similar way as you can configure your DNS server in your operating system. Depending on requirements, TBD's ssi-sdk or ssi-service could be configured to handle all DID operations internally, or use a self-hosted instance of the Universal Resolver/Registrar, or in certain situations perhaps even use a commercial, centralized service such as https://godiddy.com/ (maybe only for testing/development purposes).

The advantage would be that the TBD tools could immediately benefit from supporting many different DID methods (resolve/create/update/deactivate) out-of-the-box.

I'd love to discuss this more if there is an opportunity?

[andorsk]

Good thoughts here @peacekeeper (btw I've seen some of your presentations ). Thank you for them. It really helped me get up to speed with some of the information in the space.

@decentralgabe I think this closely relates to: https://github.com/TBD54566975/ssi-sdk/issues/111. In fact, I would argue this ticket is "blocked" until https://github.com/TBD54566975/ssi-sdk/issues/111 is somewhat more hashed out.

@peacekeeper To your second and third point. I'm not sure this is always intended to be hosted as a service? Again, https://github.com/TBD54566975/ssi-sdk/issues/111 really matters here.

Re: services configured as "fallbacks", definitely I think it should be configurable, and to your point maybe the ecosystem will eventually have various commercial DID Resolvers. That being said: I would generally prefer NOT using a resolver service if I could avoid it, as that somewhat requires trust on behalf of the resolving party, which is a failure point.

Again, all falls back to https://github.com/TBD54566975/ssi-sdk/issues/111. Right now we support did:key, did:peer, and did:web. What's the scope here for future did methods?

Finally, I'd like to point out a recent: https://github.com/TBD54566975/ssi-sdk/blob/main/did/interface.go#L30 resolver interface. In theory, we can add a whole bunch of methods as long as it supports the DID resolution interface.

My final question here is: Are there any other requirements for a DID Resolver that haven't been specified and does this interface hold true in all cases?

[peacekeeper]

Right now we support did:key, did:peer, and did:web.

I have a question about this, I thought the web5 project was primarily based on did:ion, did I misunderstand that? I would have expected there to be code for did:ion in ssi-sdk or ssi-service.

Finally, I'd like to point out a recent: https://github.com/TBD54566975/ssi-sdk/blob/main/did/interface.go#L30 resolver interface.

Good start, but it's missing some things that you can have in DID resolution, see the DID Core spec for the abstract function definition:

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

Are there any other requirements for a DID Resolver that haven't been specified

In general, most of the requirements/considerations should be expressed in the (still work-in-progress) DID Resolution spec (https://w3c-ccg.github.io/did-resolution/). Maybe one thing to mention is that there's DID resolution, and then there's also DID URL dereferencing.

My understanding from last IIW was that there are some interesting applications of DID URLs (DID with path and/or query and/or fragment) in DWNs.

[andorsk]

Added an issue here: https://github.com/TBD54566975/ssi-sdk/issues/139

[cihanss]

@peacekeeper

I have a question about this, I thought the web5 project was primarily based on did:ion, did I misunderstand that? I would have expected there to be code for did:ion in ssi-sdk or ssi-service.

The default method supposed to be ION, as it is stated here. However, ION support is not there yet.

[decentralgabe]

Yes, agreed. ION may be what we think is best, but this software is designed to be as unopinionated as possible (to expand on in #111). That means that using any DID method should be possible, and we accept contributions as such.

I made a post on the forums, which I'll copy here:

I’m not sure the best way to include resolvers into the SDK. I think as your other comment alluded to - including an interface for DID resolution is sufficient, along with an implementation for self-resolving methods (did:key, did:peer).

For the ssi-service, it seems like we could include a binary for the existing resolvers, which may be the right starting point (or run them both using something like docker-compose). In the future, it may be worth having native support for the DID registrar and resolver in Go - multi-language support, and multiple implementations will prove out the strength of the applications.

[peacekeeper]

Sounds like we're aligned. +1 to making the stack unopinionated and supporting any DID method. If we all follow a standardized DID Resolution (and DID Registration) interface, it should be possible to just "plug in" support for different DID methods. Ideally locally as part of the ssi-service itself, but various options to plug in existing resolvers are also possible.

And yes I agree multiple implementations are a good thing, also for standardization processes, test suites, etc.

[decentralgabe]

Brief update: we (TBD) discussed as a team this week and think it's best if we spin up our own implementations of the Universal Resolver (and potentially the registrar) as projects here, separate from the SDK.

[peacekeeper]

@decentralgabe Sounds great, I'd love to help with that if you need anything!

[andorsk]

Same here @peacekeeper and @decentralgabe . I'd love to help as well. @decentralgabe if you can link the repo here, I think we can close this issue.

[pascaldekloe]

For HTTP I made a generic resolver, which applies some headers too. Feedback is welcome.

https://pkg.go.dev/github.com/pascaldekloe/[email protected]/didweb#pkg-index

[decentralgabe]

this is done here https://github.com/TBD54566975/ssi-sdk/blob/main/did/resolver.go

will spin this out to a separate project/repo at some point in the coming months.

[andorsk]

@decentralgabe not sure what the plan is down the road, but wanted to ask what your thoughts are on the following for a more mature resolver:

1. Try to resolve locally.
2. If it doesn't resolve locally, use an external service ( i.e universal resolver ) to resolve as a fallback. Hyperledger Aries does this, and it seems like a reasonable approach.

goal of the sdk should be to support as many functions internally as possible, as in general I'm not a huge fan of reaching outward to resolve a did, but it can resolve externally via an endpoint if needed as a fallback.

[peacekeeper]

+1 to the approach of first trying to resolve locally, and supporting the use of an external service as a fallback.

The external service should be configurable (i.e. don't just hardcode https://dev.uniresolver.io/ as the only possibility). Note also that there is both an HTTPS and a DIDComm binding for resolving via an remote service.

The list of locally resolvable DID methods should also be configurable; there may be situations where it's still preferable to use a remote resolver service, even if a local resolver also exists.

[decentralgabe]

Great idea @andorsk and agreed @peacekeeper. We have a resolver impl of this library code in the ssi-service but it does not do caching yet. We have yet to integrate an external service - but we have configuration where this can be set.

I'm opening an issue to make the resolver a caching resolver. https://github.com/TBD54566975/ssi-service/issues/237