Decentralized Identifier Working Group

Meeting minutes

Agenda Review, Introductions

Wip: Invite Grace and Phil to introduce themselves and they did.

Wip: Issues in DID Resolution need to acted upon. Wip assigned a issues to individuals in the group and requested the issues be addressed ASAP. We need someone to raise PRs and bring them back to the Working Group.
… Some issues have been labelled "discuss" and we'll go through them.

manu: Status of looking for a new chair? Response was no takers so far.

Wip: Challenging period for the work.

manu: While Grace is here -- the DID Method Standardization group was a DIF/W3C collaboration and one of the lead chairs had to step down and so we need a replacement. It would be good to take that issue to DIF and see if we can find a chair.

grace: Most of DIFs chairs are on the TSC and DIF also needs more input. Planning to go to Asia to work on getting people there involved and hopefully that will add new candidates.
… Identity is a hot topic and I'm hopefully of bringing in new leads.

Issue assigment - any questions

Wip: Everyone on the call should be assigned an issue. 3 or unassigned. Any questions or concerns?
… if you don't have an issue, please let me know.

<Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22ready%20for%20pr%22%20no%3Aassignee

manu: Out of issues (!!!!)

Wip: Please spend the time needed over the holidays to address your issue. We need to get these done.

dmitriz: Please assign me one.

DID Resolution Issues

<Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Adiscuss

w3c/did-resolution#224

Wip: Fix where we reference 1.1 to be the same format as all the references, then on update all the references will be auto-updated.

manu: That should work, but would like to publish before RC -- when we go to Recommendation, all should reference 1.1

w3c/did-resolution#225

Wip: I'll submit a PR for 224

Wip: Assigned to JennieM and addressed as a comment to get feedback. Issue is to provide a more technically grounded abstract.

JennieM: Looking for feedback on proposal.

manu: Perhaps shorten to a single paragraph for the abstract, perhaps eliminate the 3rd paragraph. 2nd paragraph is controversial but accurate, so...

JennieM: Good feedback. If 3rd goes, then removing the 2nd also makes sense.

w3c/did-resolution#230

Wip: Unclear about the "read" operation. Quite a discussion. On review -- its pretty ingrained and though we could change, but its in a lot of DID Method specs.
… Joe is against read and should use resolve. Markus suggests there is a difference and should be retained - resolve at the high level, read at the DID method level.
… we need prioritization. Do we do this?

manu: Agrees with Markus, but sees what Joe is saying. Tried to make a database operation, so the "Read" is the operation in that analogy.
… If we had the time and energy we would do what Joe is saying, that the fundamental interface is "resolve". The DID Methods have a "read" but it really is a resolve. Not an easy decision.

<Zakim> JoeAndrieu, you wanted to celebrate distinction, but I don't think there's much to change

manu: If it were easy to do that, OK, but if big breaking changes, not worth it.

JoeAndrieu: There is an important distinction and we should clarify. I think it is easy, or and not a lot of changes, just need to outline it.

manu: Sounds good. Maybe I misunderstood -- I thought you were saying banish "read" across all DID methods, etc. Registration process may also need to change. +1 if small change.

<JoeAndrieu> +1 to changing read to resolve

Wip: Resolve call and resolve operation. Is that the change? But that would leave the "Read" the 12 times in the DID Core spec.

manu: I think that would be OK, but Markus is concerned about that.
… Could go more abstract and DID methods define how resolution is performed. There is a distinction and some DID methods have database-like operations that are "read"s.
… talk about it as an abstract operation at the DID Core, and at the DID Resolution level say resolution might be a read.

Wip: Maybe leave read in some places such as the architecture.

w3c/did-resolution#247

Wip: About errors, but not actually used. Review them, find ones not thrown and either remove or add where they belong. Many can be removed, but there are some that might be worth adding.
… Do you agree the public key ones should be deleted?

JoeAndrieu: Yes -- delete those ones as they are at a different level. Other internal ones such as options and may be raised, but at the implementation level, not in the spec algorithms.

manu: These errors came up largely through testing such as in verifiable credential testing. Errors would occur, and no error was raised -- hence these were found.
… We thought it would be good to have an inventory of likely errors, even if they weren't called out in the spec algorithms -- analogy HTTP errors.
… Feature not supported, invalid options are useful. But where we can add them to the algorithm for given errors we should add them.

Wip: Sounds good. Try to find where they fit in the algorithms, if not, try to add a generic section about other errors. Remove public key ones.

w3c/did-resolution#259

swcurran: The example implies that when a fragment is used, the DID Resolver returns the fragment of the DID Document. My understanding of a fragment is document is returned and the client then does something w/ the fragment.

swcurran: In other words, bring out the node of the document that's referenced.

swcurran: Returning the node itself seems wrong to me.

manu: Agree with Stephen, but... This part of the spec concerns me. Should a DID resolver be required to provide this? Universal resolver is server side and does server side option.

<Zakim> JoeAndrieu, you wanted to mention this is dereferencing

manu: general concern about where dereferencing ends. In general, we shouldn't be doing stuff with fragments.

JoeAndrieu: General agreement. Challenge is how we talk about it. The way 3986 talks about it, the process to get to the fragment and the client has a role in it.
… defining the end point of dereferencing sounds like a piece of work that we don't want to do. Client should do the work beyond the DID resolution.

swcurran: You're saying that we should put an end to where DID Resolution ends, but also talk about dereferencing that a client could do.

<Zakim> manu, you wanted to say "a client might... and if so, it MUST"

JoeAndrieu: Yes, I think we have too much in the spec wrt. dereferencing right now.
… Put a limit on what the DID Resolver does, but add what a client would do in dereferencing.

<JoeAndrieu> +1 agreed. this also addresses the query properties that feed into resolution options

manu: +1. Is there any easy path to split out the dereferencing to what the client is to do. Its a layering concern. We shoved derefencing into the resolver and we should do to a point and the client should do other.

swcurran: +1 to what Manu said, the same thing I've been working on Path URL thing is the same thing. I had thought that DID Resolver would return resource pointed to -- it shouldn't, it should be left to another layer. This change is worthy, it's been the source of the need for special topic calls, etc.

swcurran: I am deep into DIDs, and I was confused by this features. All mentions of fragments should be: You get back a resource and you deal w/ a fragment. This is a layering thing -- you should get the DID Document back, URL back, but dereferencing is up to client. We should say: Here's what DID Resolver returns, and here's what a client can do once it gets that result. I'd be happy if we never did dereferencing and left that to the client.

Wip: Anyone want to take it?

<Zakim> manu, you wanted to get buy-in from Markus.

JoeAndrieu: What's the complication about Markus to get buy in. Where do we hit the substantive contribution challenge?

manu: I think we should collaborate as a community and get Markus's input since he is deeply knowledgeable.
… we need to get the concept aligned with Markus, and then get a PR. Maybe this is just a layer nuance that splits derefencing between resolver and client.
… Markus should be added as an invited effort.

<Zakim> JoeAndrieu, you wanted to IP considerations are the only Markus thing we might worry about

pchampin: +1 about needing consensus across the community, looking to resolve the issues wrt Markus and working to resolve it.

JoeAndrieu: +1 to get him back and an exception as needed. The IP issues are already covered and would only come into play if there is new IP added.

Wip: Try in the new year to get Markus onboard.

manu: I'll take it on if I can get Markus onboard.

w3c/did-resolution#243

Wip: Has been open a long time. Please take a look at this. Would like to get merged, and it is blocking a bunch of there PRs, so please take a look ASAP. Today. Now.

JoeAndrieu: Looking at it this, it is hitting the same discussion as above.

manu: Two ways -- go with what we currently have, and we know it will change when we get to the dereferencing with layering. Maybe we can make it a light touch.
… Right now its mixed in, but lets make the separation explicit and certain things are typically done client side. I don't know a lot needs to be done as we have to say what the client needs to do.
… Could just delete all the dereferencing but unlikely. Do want to talk about what you do with fragments after resolution. Need to get into that. How does this impact this PR?

<Zakim> JoeAndrieu, you wanted to get rid of conforming language for dereferencing

Wip: Not helpful to my question, but...

JoeAndrieu: +1 for NOT removing dereferencing. Move this PR forward, but recognize it will be changed in future PR. Need a conformant test suite about did resolution vs. derefencing

– DRAFT –
Decentralized Identifier Working Group

18 December 2025

Attendees