Scope of sub-topics: trust in did resolution / authentication / encryption / selective disclosure

[ChristopherA]

In Markus' presentation today, there was a slide of "additional topics covered by DID Resolution".

At the end of the list was:

• trust in DID resolution
• authentication
• encryption
• selective disclosure

While these are important capabilities and a focus of my work (especially selective disclosure), I am concerned about locking them in prematurely.

Specifically, I believe you must trust your initial DID resolver, and how that trust is established should likely be out of scope, focusing only on the necessity of trusting the DID resolver. As the current draft discusses proxies, establishing trust in them also seems architecturally complex, with various trust models potentially leading to extensive debates if we attempt to define a trust model for proxies. Requirements for authentication and encryption are related to this issue.

Selective disclosure presents a related challenge—supporting progressive trust architectures adds complexity, as the results are not binary but shades of grey. The key question is whether it is trusted enough for the business purpose, requiring a progressive trust resolver to consider the risk context (low to high) and return a non-binary result. This also feels too big to tackle in DID Resolutions 1.0.

I'd like to see on a future agenda how much of these do we actually need to complete a final DID Resolution 1.0 spec, how important these sub-topics are to others, and risks of deferring or not deferring these sub-topics.

[w3cbot]

This was discussed during the #did meeting on 09 January 2025.

View the transcript

w3c/did-resolution#79

wip: Christopher is not on the call.
… Are these things that we want to spend time on, and should we split them into separate issues?

markus_sabadello: Yes, I think we should spend time on these.
… The questions of whether there should be authentication in DID resolution or whether there may be security or selective disclosure, have come up a number of times over the years.
… We need to discuss to what extent we want to cover these things.

<aaron2> There is definitely a use case for a internal identity and access management derver within an orginisation

<aaron2> server

---