Add examples to illustrate different DID Resolution Architectures
For example:
- local resolver performing verifiable read on local blockchain node
- local resolver deterministically generating DID
- mobile client securely connecting to remote resolver
- remote resolver (unknown how read executed)
- etc ...
We might want to look at different DID methods to provide examples of how verifiable reads can differ.
This was discussed during the #did meeting on 24 April 2025.
View the transcript
Add examples to illustrate different DID Resolution Architectures #131
markus_sabadello: This is a good idea. To add some more concrete diagrams for different architectures
… The current architecture section covers some concepts. Mentioning local and remote resolvers. And talks about how the read operation can be verified or not verified. There are some diagrams in the section right now, but all of it needs some more work
<markus_sabadello> w3c/
markus_sabadello: The diagrams that exist right now are quite high level. There is an open PR that updates these diagrams
<ottomorac> (link to diagrams from Markus)
markus_sabadello: This PR 143, adds additional diagrams for more concrete architecture
… For example the different ways that resolution against the bitcoin network could be implemented
<Wip> +1 that looks great markus_sabadello
manu: Just a quick note on the diagrams markus
… We are going to be required to add accessible descriptions for them. We would fail the accessibility review without those
markus_sabadello: Another thing I am doing in this PR, is changing to svg files. These include a short caption about what the image is
… Wondering if that is enough
manu: My experience is they require us to indetail describe what is in the picture
… you have to describe to someone who cannot see literally what is on the screen
… not sure if that has changed, but i doubt it
This was discussed during the #did meeting on 17 July 2025.
View the transcript
w3c/did-resolution#131
Add examples to illustrate different DID Resolution Architectures #131
Wip: Would someone be interested in taking this one on?
<Zakim> JoeAndrieu, you wanted to take that on
JoeAndrieu: I am happy to take this one. But would like to have some collaborators...
Wip: Yes this could be interesting, and also have some conversations around resolvers...
<Wip> w3c/
Complete threat modelling analysis for different DID Resolution architectures #132
Wip: Where should the threat modelling analysis live?
JoeAndrieu: The security group is looking to get all W3C specs to have a threat model analysis.... This could still be a separate document depending on how long it is...
This was discussed during the #did meeting on 28 August 2025.
View the transcript
w3c/did-resolution#131
Wip: I guess this one is related to the threat modeling discussion.
JoeAndrieu: I have seen this, didn't have time yet to dig into it, but will do.
We already have a version of these diagrams. They will be used as input to the threat modelling which we will address during CR
This was discussed during the #did meeting on 11 November 2025.
View the transcript
w3c/did-resolution#131
Wip: What would need to happen in he spec to make this happen?
JoeAndrieu: I'm assigned to it. We pulled this into the threat modelling. Another possible response, illustrations of DID Resolution architectures that Markus put together.
JoeAndrieu: Haven't gotten to that yet. I think we can consider this part of threat mdel work, we can do this during CR.
JoeAndrieu: There is a version of illustration of different DID Resolution architectures that satisfy the issue.
markus_sabadello: Regarding DID Resolution architectures, there are diagrams in the document. Local resolvers and remote resolvers -- DID Methods can work in different ways -- intention of this issue was to add architectures for specific DID Methods.. What we have in spec is generic, but we can apply how generic model applies to did:key / did:web
markus_sabadello: This issue is option, if we don't do it it's not a big deal.
Wip: I'll leave it for "during CR" -- if we don't get to it, we can close the issue w/o consequences.