w3c
Add DID Resolution architecture security and privacy considerations
Currently security and privacy considerations section does not refer to the architecture of DID resolvers.
The architecture section - https://w3c.github.io/did-resolution/#architectures - includes some security considerations. We should add some specific security considerations to the section and reference the architecture section.
Also, might we want to add some privacy considerations aswell. Especially when accessing a remote resolver outside of your control.
This was discussed during the #did meeting on 24 April 2025.
View the transcript
Add DID Resolution architecture security and privacy considerations #133
<ottomorac> w3c/
Wip: not much more to add to it... main thing is what considerations do implementers of the resolvers need to have in mind
markus_sabadello: In the current section about architectures there are some short comments about some of these considerations
… For example there is a sentence that says when you use a remote resolver service you could use a VPN. Or some form of authentication. Or query multiple resolvers to check results
… These ideas probably need to be expanded and elaborated on so they can be added into the security considerations section
<JoeAndrieu9> RFC 3552 Guidelines for Writing RFC Text on Security Considerations
JoeAndrieu: I think we should improve our guidance for what should go in security and privacy consideration section
… In our work with Simone we have incorparated RFC 3552. I think we should point DID method implementers to this RFC or additional guidance for writing these sections
This was discussed during the #did meeting on 24 July 2025.
View the transcript
DID Resolution Issue Processing
Add DID Resolution architecture security and privacy considerations #133
This was discussed during the #did meeting on 24 July 2025.
View the transcript
Add DID Resolution architecture security and privacy considerations #133
What considerations do implementers of the resolvers need to have in mind. Joe had referenced “RFC 3552 Guidelines for Writing RFC Text on Security Considerations” indicating that in the work with Simone this was incorporated.
JoeAndrieu: Simones suggestion is that security consideration sections be done as threat model and the walk through the various types of threats....
JoeAndrieu: I am still working with Simone, so we should probably revisit later
ivan: would that kind of requirement be there for already existing recommmendations that get republished. Do we need it for DID spec as well.
Ivan: Is this something that we should do for the did spec as well?
JoeAndrieu: I think it is desirable, but perhaps not required.... The goal we have is to have a threat model framework that any spec in the W3C VC spec can fit into...
Ivan: I have some doubts about it.....
markus_sabadello: I've been thinking about security consideration. I agree we need more work. The threat modeling sounds useful.
… One thing is the specification has a section about resolver architectures. Which introduces some security related topics.
… How to read from a VDR, how to talk with a resolver, and proofs and meta data.
… So how does that relate?
JoenAdrieu: the diagrams are the right place to start the work....
S /JoenAdrieu/JoeAndrieu/
manu: Just to react to did-core consideration request. I'm not sure what the ask would be.
… I don't think it's quite there yet. It's a lot of work. I'd rather not redo that section until we have a good guidance on what to do.
This was discussed during the #did meeting on 28 August 2025.
View the transcript
w3c/did-resolution#133
<dmitriz> though I think this is ok because our spec currently is very light on Controller semantics
Wip: IIUC, this issue is about providing some architecture diagram from which we can derive Security and Privacy considerations.
JoeAndrieu: that's a good description
The work is to review the https://w3c.github.io/did-resolution/#architectures and add any identified security and privacy considerations to the relevant section referencing the architecture section
This was discussed during the #did meeting on 11 November 2025.
View the transcript
w3c/did-resolution#133
wip: Threat modeling
wip: This should be addressed when we have threat modeling
joeandrieu: it's going to block us from going into security review
JoeAndrieu: The bottleneck has been figuring out what security group wants out of a threat model. We are very close to being able to share something -- once that's done, in about 3 weeks, we have three diagrams that Markus has put together, we have local/remote proxy archiectures -- we might need to do diagrams with focused threats -- threats are relatively straightforwad to do once we have diagrams.
JoeAndrieu: There are four different types of threats we want to speak to, threats in threat model, in VCs we knew tampering was a threat -- that's why we have proofs. Next is implementation threats, key compromise, issuing VCs? Have to manage keys -- but implementers have to deal with it. External threats, which we don't know a away around, but people should be aware of.
JoeAndrieu: Dependency threats -- eg. DID Resolution relies on TCP/IP and HTTP -- specify some threats on TCP/IP dependencies -- and DNS -- spoofing DNS, and get false DID Document, that's a threat -- networking layer, router might decide Joe is a bad person and is sending me over there. That's part of wy it's taken longer, but getting close to something usable by the group.
wip: we have asked Simone for a security review.
JoeAndrieu: This "needs work" -- we are going to finish the threat modelling guide -- we'll need to facilitate some conversations, special topic calls, maybe this is "to be discussed" in context of threat modelling guide.
wip: we need to be in CR before April
… Maybe we should break to talk about that
manu: I'm really concerned about this timeline
… we wanted to get through our issues and be ready for PR
… And this looks like it might take another 3 months
wip: Maybe its worth talking with Simone to understand.
JoeAndrieu: I think it's negotiating with SING -- in order to go to CR, do we need threat model today -- conversation that staff needs to think about -- is it worth extending now because we need threat model, we are making good progress, maybe we put options to staff.
manu: I'm really concerned about what this does for our timeline.
JoeAndrieu: We should discuss this with Staff and have them provide guidance on what we do next.
wip: ok. we have a section that is security considerations
… the work is to review the DID architecture section and update the Privacy Consideration sections
JoeAndrieu: I do agree with where we should put these edits -- this is not put privacy/security issues in architecture section.
JoeAndrieu: Do we mention threat model in this issue?
Wip: No, we don't.
JoeAndrieu: Ok, let's keep threat model in another issue. Our intention is to complete threat model while we're in CR, not before.
ack