w3c
Remove normative statement around passing resolution options to the Read operation
Besides the input DID, all additional resolution options of this algorithm MUST be passed to the Read operation of the input DID method.
On the DID Resolution Test Suite call it was suggested that this normative statement could be removed after I raised concerns around how to write a test for it
This was discussed during the #did meeting on 11 November 2025.
View the transcript
w3c/did-resolution#223
Wip: The read operation can tells you what to do
markus_sabadello: This is for DID Methods that require certain resolution options -- that would be in context of specific DID Method, resolution only works if resolution option is passed to the method
<Zakim> JoeAndrieu, you wanted to say this is test requirement
JoeAndrieu: I don't know if we do this anywhere else, this is a requirement on the test suite -- we don't have any normative requirements on client of resolver, we could sepcify requirements on test suite.
Wip: The test suite is testing a universal resolver, you pass in a DID and some options and you get back resolution result -- I'm trying to test inputs/outputs.
JoeAndrieu: Dereferencing tests start w/ DID URL and they must do this.
Wip: The way you test it is by having verifiable input -- these resolution option are required -- this DID URL pass it over to universal resolvers API - in test suite -- it's ablack box, I can't go in there and check to see if options have been passed.
JoeAndrieu: We don't have a way of transforming input and getting signatue of the call. My own unit tests would teest this, I'd isolate the function away from the APi.
Wip: Yes, here is my API, ehre are some dids you can test it with -- that's what the test suite does. DID Methods are going to put requirements to pass on sidecar data -- ensure information is passed in... what could we change this to -- resolution options passed to read option, could be just execute read operation.
JoeAndrieu: This is a requirement of unviersal resolver, not any particular resolver.
JoeAndrieu: When I make a BTCR2 resolver, it has resolution options because its a single component. When we write something that isn't designed for universal resolver, you give DID and get back DID Document -- it already has parameters.
JoeAndrieu: I don't disagree w/ markus_sabadello framing.
JoeAndrieu: Maybe we should just remove it.
JoeAndrieu: We are not standardizing the architecture of the universal resolver.
manu: +1 to remove
markus_sabadello: I don't really see how this is specific to universal resolver -- this applies to any resolver
markus_sabadello: In my mind, the sentence here wrt. read operation is very generic, pasing it doen't mean sending it over the wires -- if it's hard to test then maybe remove, but it's not specific to universal resolver.
Wip: What Joe si getting at, if I care about DID method, I'm going to implement the resolver spec by combining both interfaces... but in practice, they might do resolver for single DID Method.
<Zakim> JoeAndrieu, you wanted to say did btcr2 doesn't have a read method
manu: this is impossible to test, let's remove it.
JoeAndrieu: BTRC2 doesn't have a read method, we have a resolve mechanism and a resolver implements it.
Wip: ok, consensus is we're going to remove this statement.
