'remote' vs 'local' DID Resolvers

[ChristopherA]

In reading through some of the discussion about the DID resolver spec, I feel like some of the feature requests (for instance #27) are more for what I might call a "remote" did-resolver, which though can be useful as a secondary check on your own did-resolution results, but I personally would not directly trust.

In my scenarios I would only feel confident about my own 'local" did-resolver, i.e. installed on my device and not queried over internet. This is analogous to having my own bitcoin-core server (and Blockstream satellite connection) making me more financially self-sovereign.

And like bitcoin, when using a mobile device I might point to my own trusted server and secure connection to it (some bitcoin wallets support that now). I might also trust DID resolver a little bit when using a constrained devices (mobile or IOT), by using Tor/i2P or some other privacy service and then querying multiple DID-Resolvers to compare the results.

Thus in the use cases document for DID-Resolvers I'd like to see some discussion about the differences between local resolution vs. remote resolution.

[peacekeeper]

I agree this is a critical topic, that's why @dmitrizagidulin and I added a section called "DID Resolution Architectures" at the beginning of the DID Resolution spec: https://w3c-ccg.github.io/did-resolution/#architectures

There's not much content yet, but this section should discuss local resolvers vs. remote resolvers and their trade-offs and trust implications.

When relying on remote services during DID Resolution, I guess there are multiple potential mitigation strategies against various threats:

• run your own trusted remote DID Resolver and talk to it over a secure connection.
• contact multiple remote DID Resolvers and compare results (good idea, I haven't thought of this before).
• some DID method such as sov may contain state proofs from the ledger, this can allow you to trust the result to some extent, even if it was passed through an intermediary untrusted remote DID Resolver.
• a remote DID Resolver may add a signature or other proof to a DID document, this way you could mitigate against MITM attacks between your client and the remote DID Resolver.

Some of these ideas are already mentioned in the DID Resolution spec draft, but we need to flesh them out.

As a side note, @creatornader and I also added a yellow warning symbol to the Universal Resolver a few days ago, to make sure people treat it as an untrusted third party and run their own local resolver software whenever possible.

[mwherman2000]

I think this is a 2x2 scenario where the axis are:

1. Local vs. Remote DID Resolver
2. Local Ledger State vs. Remote Ledger Node (reference: https://github.com/decentralized-identity/universal-resolver/blob/master/docs/figures/overview.png)

Are all 4 of these scenarios valid? Are all 4 going to be described in the new Architecture section?

[peacekeeper]

@mwherman2000 Yes I have also been thinking about these as orthogonal questions, I would just note that for the second "axis":

• Not every DID method involves a "ledger".
• There may be more nuanced different ways how a DID Document can be resolved with a given DID method. I think depending on DID method we will not always have a strict local vs. remote distinction, but rather a spectrum of options how a DID method can specify its "resolve" operation.

Yes I think this is precisely what we should discuss in the "DID Resolution Architectures" section, and this will be the first topic on this week's DID Resolution call.

[mwherman2000]

Here's a draft sketch (alternative version 2) using "Verifiable Data (VDR)" instead of "DID Document Repository"...

The focal point for each of the 2x2 options is the "bright blue" DID Resolver box:

• what's inside it?
• what is outside it?

NOTE: On this morning's Indy community call, the term "Verifiable Data Registry" was used as an alternative to "DID Document Repository".

[brentzundel]

"Verifiable Data Registry" also matches the language used in the verifiable credential data model.

…

On Thu, Feb 21, 2019, 09:41 Michael Herman (Toronto) < ***@***.***> wrote: Here's a draft sketch (alternative version 2) using "Verifiable Data (VDR)" instead of "DID Document Registry"... [image: DID Resolver Architecture] <https://raw.githubusercontent.com/mwherman2000/indy-arm/master/images/HBB-DID-Resolver-Architecture%20v0.2.png> NOTE: On this morning's Indy community call, the term "Verifiable Data Registry" was used as an alternative to "DID Document Repository". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ5VP94DTemdEuGB2xTnJhrUg1pDq2hiks5vPsxRgaJpZM4bAUx8> .

[kdenhartog]

Some other aspects to consider with this is relevant to knowing which ledger I may want to resolve to. For example if I'm running a local indy network, I want to be able to resolve to the local network rather than a global ledger like sovrin which uses the same method. There's two ways that we can handle resolving these. One we could require people to configure their own resolvers for colliding name spaces, or we could namespace networks (more realistic). In any case, both will likely be useful and should be considered.

[BillBarnhill]

I think it may not necessarily be either-or for local vs. remote DID resolver; there may be a case where a local resolver works with a remote resolver.

An example scenario is when the resolution requestor has an intelligent local resolver, an intelligent software agent that incorporates the represented user's policies and data exchange relationships (including interacting with local VDR and caching), and this agent interacts with a remote resolver with it's own local VDR. In this scenario the client app always connects to the intelligent local resolver. The local resolver connects to an appropriate remote resolver, or resolves the DID directly. This scenario enables things such as local DID shortcut aliases (e.g., did:alias:Bob to did:btcr:xkyt-fzgq-qq87-xnhn), DID mapping across different methods, and selection of which DID to resolve based on the user's current presented identity. The last is a form of DID aliases. An example is how the local resolving agent resolves did:local:Bob to did:ipid:12D3KooWMHdrzcwpjbdrZs5GGqERAvcgqX3b5dpuPtPa9ot69yew when Alice is acting in her identity as Chess Club president and resolving Bob's DID document to get his data hub service, but when Alice is acting in her identity as Bob's corporate boss then the local resolving agent resolves did:alias:Bob to did:alias:Bob to did:btcr:xkyt-fzgq-qq87-xnh.

The alias method is something invented whole cloth for this example. It's not an existing method as far as I know.

[peacekeeper]

Maybe an analogy from the HTTP URL world would be things like http://localhost/ or http://192.168.1.1/profile.html. The returned resource depends on who dereferences it.

From RFC3986:

URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user's context.

[burnburn]

@ChristopherA do you believe your question/issue has been addressed in the current version of the spec?

[pchampin]

This was discussed during the did meeting on 08 November 2024.

View the transcript

w3c/did-resolution#28

burn: the real question is whether the DID Resolution spec adequately covers the question of local vs. remote resolvers.
… the easiest way to resolve this issue would be to check with the submitter (Christopher Allen).

denkeni: This question of local vs. remote was "under the radar" when we implemented our DID Resolver because we required developers to verify the VDR.
… so this question is worth investigating further, in particular when a mobile phone is running a resolver.

burn: could you add a comment directly?

denkeni: Yes.

burn: thanks to everyone who was able to come today. This was a good start on some very old issues.

---