[MINUTES] DID WG Special Topic 2025-09-03

DID Working Group Special Topic Call - 2025/09/03 Summary

*Attendees:* Benjamin Young, Dmitri Zagidulin, Joe Andrieu, Kevin Dean,
Manu Sporny, Markus Sabadello, Ted Thibodeau Jr, Will Abramson

*Topics Covered:*

   1.

   *DID Resolution Test Suite Improvements:* The primary focus was
   enhancing the DID resolution test suite to allow resolver implementations
   to define:
   - The DIDs they can successfully resolve.
      - The DIDs that should produce specific error responses.
      - Resolution options (including version IDs and other method-specific
      data).
   2.

   *Test Suite Structure and Implementation:* Discussion included the
   structure of individual test files (multiple files recommended over one
   large file), the use of JSON schema validation for testing, and the
   creation of negative tests for invalid inputs. A method for linking test
   cases directly to relevant sections of the DID resolution specification was
   also described.
   3.

   *Test Report Generation:* The process of generating test reports was
   clarified, emphasizing that the existing GitHub Actions and Mocha W3C
   interop reporter handle this automatically. Improvements to the metadata
   included in the reports, such as more comprehensive implementation details,
   were also discussed.
   4.

   *Debugging and Next Steps:* Will Abramson encountered a caching issue
   while working on the test suite. The group provided solutions involving
   local linking of the implementation folder to avoid caching problems. A
   follow-up meeting in two weeks was scheduled to review progress on the test
   suite.

*Key Points:*

   - The group agreed on the need to enhance the DID resolution test suite
   to allow for more precise definition of supported DIDs and expected error
   conditions.
   - A structured approach to test creation was established, aiming for
   clarity and maintainability.
   - Existing mechanisms for test reporting were found to be sufficient,
   but future improvements to metadata within the report were noted.
   - Practical debugging advice was provided to resolve a caching issue
   encountered by a participant.
   - A follow-up meeting was planned to continue work on the DID resolution
   test suite.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-did-wg-special-topic-2025-09-03.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-did-wg-special-topic-2025-09-03.mp4
*DID Working Group Special Topic Call - 2025/09/03 10:02 EDT - Transcript*
*Attendees*

Benjamin Young, Dmitri Zagidulin, Joe Andrieu, Kevin Dean, Manu Sporny,
Markus Sabadello, Ted Thibodeau Jr, Will Abramson
*Transcript*

Benjamin Young: Hey, are we not doing this today?

Will Abramson: Maybe that'll be good.

Will Abramson: I'm not prepared. But yeah, you could just dive into the
code right and try and make some progress but frantically been trying to do
that the last half now.

Benjamin Young: Yeah, I understand.

Will Abramson: That would be useful. Ed, we'll wait and see who else joins
and see if there's anything else to chat about. I just followed managers
suggestion just pushed to main on the new text implementation definition to
explore this solid

Will Abramson: So just to explore a different data structure right for
defining a did resolver and the valids that resolver can resolve. last
second you doing all right.

Manu Sporny: Hey guys, how you doing?

Will Abramson: I was just saying I'm not as prepared as I would like to be
this call.

Will Abramson: So you can see how we go. yeah, I mean maybe we can just get
started. I mean a small group is good because maybe we can just do some of
the code work, right? you guys can help me figure out exactly what changes
need to be made and all that sort of stuff. Before we get into that, is
there anything else that we want to dis discuss that are more like high
level plans and Joe?

Manu Sporny: I wanted to go back around to the discussion we had last time
to make sure we were all on the p same page kind of…

Will Abramson: Yeah, I was hoping to do that too…

Manu Sporny:

Manu Sporny: what tests. Yeah. And that's the only in my

Will Abramson: because I hope I just paint Marcus. Yeah, because I think
Marcus wasn't here last time, And I was hoping to hear let's make this one.
okay so let's talk about that matter.

Will Abramson: I think that's the first issue raised on this did resolution
test suite right unless there's a different bit that you wanted to discuss
I think this is the change that we need to make to the bid resolution test
suite that allows the resolvers or implementation definitions of resolvers
that are going to pass the test suite to be able to define the divs that
they are able to resolve or the divs that they know will throw specific
errors

Will Abramson: Yeah, let's go from there.

Manu Sporny: Yeah, I think that's exactly right. And maybe we can focus on
just the f very first thing that needs to be implemented which is the
resolution of a valid did.

Will Abramson: Mhm. Yeah.

Manu Sporny: I think the only thing we need to add right now is I think we
have a did resolution tag Benjamin. Is that right?

Will Abramson: So I was telling Ben I have proposed this I mean I followed
your advice just pushed to main on the CC test implementation thing…

Manu Sporny: Okay.

Will Abramson: which there is one ballad did like that is resolving…

Manu Sporny: …

Will Abramson: but then my local test is not working. I tried to update my

Manu Sporny:

Manu Sporny: yeah. yeah,…

Manu Sporny: I think that looks right for the first So I mean we should be
able to do a minimal viable set of tests just with that. that's all we need
in the config.

Will Abramson: Yes. Mhm.

Manu Sporny: And then you can start, picking the most simple must
statements out of the spec and we can see what we get from there.
00:05:00

Will Abramson: Yeah. That all makes sense. I Yeah,…

Joe Andrieu: In that configuration, where do the options go for Resolution
options.

Manu Sporny: We are going to need to add them. Yeah.

Will Abramson: that's a separate issue that we have in I think there needs
to be a way that …

Joe Andrieu: Okay.

Will Abramson: because some of the tests I think the result the test itself
will define the resolution options, right?

Will Abramson: a specific version I actually will it because what that
version ID is is up to the method to specify All right.

Joe Andrieu: Yeah.

Manu Sporny: Yeah, I mean we're going to end up with an object here instead
of just a string where did we'll identify the resolver options. We'll
identify sidecar data like whatever needs to go in to this call for testing
a valid which is fine. and again I think that's largely for you will and…

Will Abramson: Yeah. Yeah.

Manu Sporny: and figure out what the structure there looks like.

Will Abramson: So, I am going to have regular calls with BenGo.

Will Abramson: I've not started doing that yet, but because we're having a
call on Monday, but Monday was a US holiday, so we didn't call, but
hopefully we'll get into a rhythm of, doing that. And I guess maybe what we
can do today is just talk through some of those initi look through the spec
and pick out five statements that we do want to write test and just talk
without actually writing the test what that test might look like. where is
I think it's probably best to just be inspect rather than see it's
extracted list that I extracted all the must statements right but then
they're kind of out of context.

Will Abramson: So this one is going to be tested just by supporting the
resolve well and passing it resolution.

Manu Sporny: Yeah, that's right.

Manu Sporny: Yeah, I think this is your first test, right? Yep.

Will Abramson: And…

Will Abramson: then the second one, the input is required and the value
must be in form did. I guess that is checking that it throws an error…

Will Abramson: if there is no input or

Manu Sporny: Yeah. Yeah.

Manu Sporny: Or it's just,…

Manu Sporny: a random string or whatever. so this could be a negative test.
This could be test two.

Will Abramson: Yeah, I guess that speaks to me there are some tests,…

Will Abramson: right, that we can run against all resolvers that don't even
need inputs, right? We can decide what the bad inputs are and run those bad
inputs against all.

Manu Sporny: Yep.

Will Abramson: So that's good.

Manu Sporny: Yeah. And…

Will Abramson: Okay. Right.

Manu Sporny: then all of these feel like they could be one test that's JSON
schema test.

Will Abramson: And we just basically get the resolution result and…

Will Abramson: pass it through this JSON schema validation check.

Manu Sporny: I guess You'd have to figure out exactly how to make the
resolution unsuccessful. You're Yeah,…

Joe Andrieu: we probably want to break out the failures in those three
tests though.

Joe Andrieu: So, I don't know that putting them all in one test feels like
it would obscure the document versus metadata, for example.

Manu Sporny: you're right. I guess what I'm trying to say is that the way
that we would do the test would Yeah.

Manu Sporny: No, you're right.

Manu Sporny: May maybe yeah, I'm probably over optimizing too early. Mhm.

Joe Andrieu: But each one is easily just a schema.

Joe Andrieu: I think all the same did document metadata match that shape?
did document match that shape? Does our did resolution metadata match that
shape?

Manu Sporny: Mhm.

Will Abramson: And I think we'd have shapes that are expected for a
negative,…

Will Abramson: if for all those error states that people are going to say,
" this is a not found b did for example, we're going to expect the result
that comes back to have a bid resolution status structure. Okay.
00:10:00

Manu Sporny: Yeah. So, for this one, it's like, okay, we're going to
resolve a did. We're going to make sure it's an error. So maybe we pass
just a totally invalid in or a did that is clearly not going to be resolved
did example and then we're going to get a response back and we are going to
make sure did resolution metadata is not empty and…

Manu Sporny: contains an error property. Okay. Right.

Will Abramson: Yeah. …

Manu Sporny: And then for Yeah. Yep.

Will Abramson: and mostly the error property should be known because I
think that will be part of if you look at your object you propose right you
have supported did and then they're valid and then I think there's a bunch
of error codes that we're going to expect people to pass Okay. So, that
does make sense. I'm just taking notes. I'll try and do some

Will Abramson: and there would just be one file,…

Will Abramson: If I'm looking at the mocker test suite, there is a one file
that I guess Benjamin you created called 10- test example would just like
it's just you describe and then all of your test cases currently there just
one. Okay.

Manu Sporny: I'd suggest that we do multiple files.

Manu Sporny: One per section of the spec is one way to do it.

Will Abramson: All right.

Manu Sporny: just to make it easier to kind of otherwise you end up with a
giant file with thousands of lines.

Will Abramson: So, yeah,…

Manu Sporny: Go ahead, Benchman.

Will Abramson: that makes sense,…

Benjamin Young: Yeah, the numbers at the front of the file are just so that
they run in a consistent order.

Benjamin Young: If you look at the VC data model test suite,…

Will Abramson: All right. Mhm.

Benjamin Young: that's a good one to cheat off of. It uses numbers roughly
based on the section in the spec. So all of that's, just for human beings
to find their way around. you do want to avoid one massive file. That's how
a lot of these were when I started working them, but breaking them up this
way lets you have the spec open on one screen and your test stuff on the
other. Typically, a good rule of thumb is just to have one describe section
per file.

Benjamin Young: So if you find yourself starting a new mocha describe right
here line whatever yep if you end up with two of those in a file you can…

Will Abramson: Yeah, that

Benjamin Young: but I've been chopping things at those describe levels for
the most part and then I also posted this in chat but if you look at line
33 this test. link that's a Chrome friendly Firefox supports not to text
highlight URL. So if you highlight the must statement that you're testing
and link the highlight in Chrome you'll get this kind of URL and then if
you stick it in that variable the test suite will link it text. So in this
case, if present the value of the ID blah blah blah,…

Benjamin Young: that will become a link to this URL, which is ideally the
highlighted must text that you're testing.

Will Abramson: Right. Yeah,…

Benjamin Young: So that people can go over and see the surrounding context
of when and where that's tested.

Will Abramson: that's useful. In fact, maybe you guys can walk me through
that a bit more because that's one bit of the current test suite that I
haven't looked at which is about how the report is constructed, so there is
a test case, but where because we're going to want to change that report,
right, to have a bit of a different structure than there is currently in
our example, I suppose.

Benjamin Young: The stub test suite. Are you talking about the did
resolution test?
00:15:00

Will Abramson: Yeah, the mocker. Yeah, exactly.

Benjamin Young: Yeah, it's extremely minimal at this point. it does do the
implementation looping and…

Benjamin Young: things, I believe. but I would cheat off of a finished test
suite this one for how it works. It's in every file.

Will Abramson: Which file defines the short?

Will Abramson: Maybe money will know

Benjamin Young: I can show you. Go ahead.

Manu Sporny: I wasn't going to answer his question, Benjamin. I was gonna
raise something else up,…

Benjamin Young: Okay. Yeah,…

Manu Sporny: which is I've always not quite liked the fact that we smash
all the conformance statement here on the left and it takes up an enormous
amount of space. I'm wondering if there's a way for us to, put the
statement out here and then the check boxes down. again, this is nitpicky,
but I don't know if there's a way for us to make this easier to read.

Benjamin Young: collapsible sidebar would be a better choice. you can
reword like you can make it value whatever you want.

Benjamin Young: it just makes it far less comprehensible because most of
the test suites when I started working on them it should have a valid type
which could be from anywhere in the spec. and so they were very often
disjointed and it took as much time to understand what the test was
actually testing in the spec than it did to know whether the code was
sufficient. and it was just absurd. So, while some of them nearly paragraph
link length and the wrapping is annoying, you at least know what's actually
being tested. So, there is UX stuff that could be done. But I really would
not rat hole on that. I would, add a collapsing sidebar and call it a day
for now and get the test suite written.

Manu Sporny: Yeah, I mean plus one to that. I wasn't suggesting we get rid
of the language. I think we absolutely do need the language. and in some
cases we need a little more context for the language. I think I don't know…

Manu Sporny: if you saw me click on this thing, But when I click here, it's
going to take us to the spec. It's going to find the text and highlight it
in purple to tell you exactly…

Will Abramson: All right.

Will Abramson: Yeah, that is great. Yeah.

Manu Sporny: where this is great. this is exactly what you want in a test
suite cuz if you're an implementer and you're kind of like why am I failing
this test you can just go over here you can click it will take you to the
exact line in the spec and…

Manu Sporny: then you've got context for okay that's what is being tested
here. go ahead, Benjamin. Mhm.

Benjamin Young: Yeah, with enough time and…

Benjamin Young: effort, we haven't done it yet. you could load that same
highlight in an I frame or something that you position in a modal or below
the test that you're looking at. the UI can always be better, but just
jumping over to the test in the spec was way more than we've had previously
and way more than you'll see on most W3C spec tests.

Will Abramson: I wonder…

Will Abramson: if they just

Manu Sporny: Yeah. And…

Manu Sporny: then I guess it's just a whole bunch of await, assert
statements on, what we're expecting in the response and that's it. mean,
this is just this entire file, which is not very long. It's, 65 some odd
lines. You test the entire identifier section in the VC data model spec.
So, it's not super complicated here. what is it like there's some header
stuff. you describe the section of the spec that you're testing.

Manu Sporny: you set up kind of the output, matrix that's going to show up
in the report. You cycle through every endpoint for every implementation.
you do any kind of setup that you need and then you go and you call each
endpoint one by one expecting a certain output.

Will Abramson: Yeah, cool. I just saw Marcus joined and…

Will Abramson: I know I think he's got to leave soon. I don't think you
realize this call was on, but maybe we can just review where we're at and
how it's changed from when because I think Benjamin, you worked with
Marcus, right, to create this sub format.
00:20:00

Benjamin Young: sort of like this implementation structure definition has
been around for three or four years. so we're just in this did resolvers
block. even that existed for since the didsp spec was done which again was
three or four years ago. the main thing to discuss is what other data you
want to cram in there since the resolver implementations are providing
their own fixtures as you've done here with this is a valid for me.

Benjamin Young:

Benjamin Young: In Europe

Will Abramson: Yeah, I think that's the main thing that maybe Marcus you
missed.

Will Abramson: I know you've been out for a few weeks, but we decided as a
group that did resolvers or implementations of did resolver need to have a
way to provide the set of bids that they can resolve that are valid for
their resolver implementation. And similarly the set of bibs that are
throwing specific error cases. And then the only other thing that we also
haven't yet got in here is we think resolvers are going to need to provide
the resolution options object as well. certainly in the case of divid BTC1
for example we might need to provide additional specific data for that
divid method. But similarly with version ID is specific to a divid method.

Will Abramson: So if we want to test that version ID is handled properly in
the resolver then think we would need message to provide that version. But
I don't know if you already had this information or not but I wonder if you
have any thoughts. ust. maybe Marcus can't speak. I don't know. I guess the
other thing, us, is we kind of volunteered I mean, I'm going to help on
this.

Will Abramson: thought I help lead this effort but be great to have your
support as well Marcus on building the tests and we're also going to work
with Bango to build this so what else is worth discussing in this call
right now?

Manu Sporny: I mean, I guess the question, do you feel like you have enough
to write the first five tests? I feel like that is the next thing that
needs to happen.

Will Abramson: Yeah. No,…

Manu Sporny: There's not too much point in talking about anything else…

Will Abramson: no, I think I do.

Manu Sporny: until I think largely that's a question for you Benjamin.

Will Abramson: The area that I don't fully understand in the code still is
still about how these reports are generated, right?

Will Abramson: I know how to run the tests, but how are the reports
generated from those tests and how do we change what is generated in those
reports or do I just not really care about that and accept that the reports
are going to be generated? Okay, because I couldn't see any codes or…

Will Abramson: I'm not looking the right file.

Manu Sporny: The…

Benjamin Young: or rich bit,…

Benjamin Young: sorry. …

Manu Sporny: how are the reports generated?

Benjamin Young: it's all a GitHub action.

Benjamin Young: So, if you go back to the top or on the left there, just
click on GitHub.

Will Abramson: All right.

Will Abramson: Yeah. Right.

Manu Sporny: I think that the question might be slightly different.

Manu Sporny: It is all GitHub generated, but it's driven off of this Mocha
W3C interop reporters thing.

Benjamin Young: Yes. Yeah.

Manu Sporny: You shouldn't have to think about it at all.

Will Abramson: Right. Okay.

Manu Sporny: Right. It just follow the pattern and…

Will Abramson: Okay.

Manu Sporny: it will generate the report …

Will Abramson: Yeah. Right. Okay.

Manu Sporny:

Manu Sporny: years of work has gone into this. So you don't have to think
about it at all. and if you want the output to look different or we need to
do something different with the output, then we can break this apart and
try to figure out how to improve it. But for did resolution, I don't think
we're going to have to change anything. go ahead, Benjamin.

Benjamin Young: Yeah, that is the upstream reporter. it does two things.
Makes it look like a W3C official document or unofficial document depending
on settings you pass to it. so it looks like that and then it does the it
does one grid type for two different scenarios, but where you've got
implementations as column headings and spec definitions as row headings.
and then there is an interop grid which is essentially the exact same
reporting flow.
00:25:00

Benjamin Young: you just pass it in a different sort of test to say whether
or not implement and B can talk to each other…

Will Abramson: Cool.

Benjamin Young: which is probably not necessary in this case. and that
Mocha W3C interop reporter is moving to the W3C soon but it'll be the same.
So that is the codebase where you would add something like the collapsing
sidebar or something if and when you get there. Yeah, there's an interop
example such as it is, but I don't think you'll need that did resolution.

Ted Thibodeau Jr: I just caught a piece of that. I was talking a bunch of
times that these reports are focused on the company,…

Ted Thibodeau Jr: not on the implementation. And that's a thing that still
needs to get addressed. It looks like

Benjamin Young: Yeah, it's totally possible.

Benjamin Young: Basically we've only gathered company name and and for
whatever reason, implementation name, wasn't used. you go. So there is a PR
on the mo interop reporter repo that starts to flesh out a lot more of that
implementation data. because other requests were like we still want to see
the company name…

Ted Thibodeau Jr: Sure.

Benjamin Young: because a lot of these products don't actually have names
anybody knows.

Benjamin Young: so we need to add an appendix that says vary by digital
bazaar and then companies also want to show links and repo links and
whatever else. So I think if you scroll up a bit yeah improve test subject
metadata maybe that may or you're just in issues go to PRs. This is the
same request. been around for a minute. maybe it's on a different repo. it
is in one of the implementation repos where I started redescribing things.
it is, on the to-do list for this. but that is the issue from as you can
see a couple years back and the code to do it is not hard.

Benjamin Young: just, it's the spidering effect it has on now 10 plus repos.

Ted Thibodeau Jr: Yeah, that's part of…

Ted Thibodeau Jr: why I kind of hope to get it done sooner. That's all
right. It is…

Benjamin Young: Yeah. Yeah.

Ted Thibodeau Jr: what it is.

Benjamin Young: The 10 or eight or…

Benjamin Young: nine of them are already in production, but yeah, it's
hoping you would take That's right.

Ted Thibodeau Jr: If it's in the usual list,…

Ted Thibodeau Jr: somebody will deal with it someday. Yeah, I code in
English, remember? Or maybe I am the IOT.

Benjamin Young:

Benjamin Young: That's the world's catching up with you. So, pretty soon
we'll just have you in an AI bot somewhere. All TED.ai. If you don't buy
it, I will

Will Abramson: Okay.

Will Abramson: Yeah, I think I do have enough to get going. so maybe we can
just close there. I guess I have one last question which is I'm currently
running into an error which I haven't really had time to debug properly.
Maybe I can just share my screen and you guys can tell me if I'm being
silly.

Will Abramson: But I made this change to the structure right so now we
should have this supported did and this valid right this is accessing the
danny tech resolver implementation right it's an array and we should be
able to get the support did this is an array but currently this is coming
back as not defined I don't know is it caching or there's something wrong
with my I mean I haven't really debuged this deeply but I would have follow
this search for I don't know yeah so it's fine I just wanted to ask…

Manu Sporny: Yeah, just do a print statement and see what object you're
dealing with before you start accessing stuff in it.

Will Abramson: if there's any question so I'll take this last half an hour
try and…

Joe Andrieu: Okay.

Will Abramson: create some tests like you guys can all have half an hour
it's fine

Will Abramson: cuz I think this is right. I just need to debug it.

Manu Sporny: The caching thing. What might be happening is thinking about
it a bit more. see this VC test suite implementations when you do an npm
install of it, it's just going to install whatever the latest thing is. And
then if you go and…
00:30:00

Will Abramson: Okay. Right.

Manu Sporny: you update it and do a bunch of stuff, it's not going to pick
up those changes until you reinstall it.

Will Abramson: That might be it. Yeah.

Will Abramson: That's exactly what I was looking for. Okay, that works.
Right, right,…

Benjamin Young: Yeah, npm will cache that.

Benjamin Young: So your best bet is actually to bring that implementation
folder locally and…

Will Abramson: right. Yes. Okay. Nice.

Benjamin Young: re renp link it to your local folder after you make new
changes.

Will Abramson: Right. Yeah. Just changes it.

Will Abramson: Yeah. Yeah.

Benjamin Young: it'll usually stick …

Benjamin Young: unless you npmi and then it'll throw out your link and you
have to put it back which is obnoxious…

Will Abramson: Cool.

Benjamin Young: but yeah it's basically overheavily caching the things.

Will Abramson: So if I wink the implementation folder, then I can just be
changing the implementation folder to experiment with different structure,…

Benjamin Young: Yep.

Will Abramson: And it should work. That's great. That's perfect.

Benjamin Young: That's it.

Will Abramson: That's the kind of help I wanted. So I'll just have a play
with this and let you know how I get on. I was thinking I mean maybe we do
should have another call in two weeks that is about the test suite.

Will Abramson: I did also want to try and get some special topic time for
some other topics, but death does still feel like the most pressing thing.
and I'd try and catch up with Marcus as well and just see if we can get his
help on this test. But I think I should be able to write this live test on
my own to be But it' be good to get some review Have a good rest of the day.

Joe Andrieu: Cheers.

Manu Sporny: All right.

Will Abramson: This is a bit chaotic,…

Will Abramson: but it's useful for me. Thank

Manu Sporny: No, it's good. Thanks all.
Meeting ended after 00:31:51 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*