– DRAFT –
Decentralized Identifier Working Group

Agenda Review

<Zakim> manu, you wanted to agenda+ maybe?

manu: What is happening with the DID Methods Working Group at TPAC - are the meeting or not?

TPAC Logistics

manu: perhaps cover the DID URL Dereferencing PR a little

wip: After TPAC - are we taking a week off or holding it?

pchampin: About DID Method Working Group -- plan the meeting in case there is a meeting, but the Charter has been stalled, so not sure if the slot can be used or not.

<Zakim> manu, you wanted to take two weeks off?

manu: Manu will not be around in November and so good with the two week break, plus US Thanksgiving, so perhaps three weeks off.
… On the Charter issue -- when is it getting unstuck? Thought it was going to move a month ago. Even then, have the meeting at TPAC to try to make some progress.
… There are a number of people in the APAC region interested in DIDs. No binding decisions obviously, but having a discussion would be good. No chairs there, so might fall to Manu.

ottomorac: Agreement on two weeks off.

<Wip> https://docs.google.com/spreadsheets/d/1GZqNyInIAdDcaHemrHxiV5kd8S2ByfGXEEL0jRzQL9o/edit?gid=0#gid=0

ottomorac: On TPAC, agree we should have some meeting there, and keep pushing it forward.

Wip: Please sign up if you are going, dinner to be planned, agenda is on the spreadsheet -- add more if you want to.

Announcement: DID Path special topic call (5-Nov)

<Zakim> manu, you wanted to ask about DID Methods charter to AC?

ivan: For the JSON-LD Working Group -- new charter going to the AC. Goes to the Comms team tomorrow, AC on Monday. Voting period proposed to Dec. 17 -- longer. Member companies should vote and comment if needed. Security items in the Charter that are relevant to this group.

manu: DID Methods Charter -- when to AC?

<ottomorac> https://github.com/w3c/did-methods-wg-charter/issues

pchampin: All issues are closed. Could go, but some issues were create to reflect remarks of some groups and they are still open. TAC has reviewed, but are expecting actions.
… could add a comment to the issues to see if they can move forward. Content has been proposed in comments but not PRs.

<Zakim> manu, you wanted to invite all open issue commenters to W3C TPAC Monday morning session -- can we put AC vote out before TPAC?

manu: That we send out to AC right now -- those issues can be discussed at TPAC and to get the changes into the Charter. Would be nice to get feedback before TPAC.
… Could in parallel invite people with comments to the Monday meeting and we can process them there.
… Really need to move forward. It's been a year and not likely to change.

<Zakim> manu, you wanted to say mid nextweek would be fine.

ivan: Really tough to get it out before TPAC. Maybe mid-next week.

manu: mid-next week would be fine. We would get the expected objection.

pchampin: Off to Japan tomorrow -- tough to fit in, but will try.

Announcement: DID Path special topic call (5-Nov)

<ottomorac> w3c/did-resolution#221

Wip: Don't discuss on the call today -- hence special call.

manu: Won't make the special call -- has lots of opinions. Surprised by the response. Not sure if opposed philosophically or is it the PR content.

swcurran: +1 to what Manu said. The philosophical is "do we want to define what path handling should be as a part of DID spec, or do we defer it to DID Methods only?".

<ottomorac> q>

Make conformance statements concretely testable #213

<ottomorac> w3c/did-resolution#213

Wip: Have to make sure that all the needed parties can be at the special call.

<ottomorac> Issue deals with defining conformance classes for DID Resolution, which is required for resolving other issues. Conformance classes should be defined in terms of inputs and outputs, Manu has proposed some wording.

manu: Reference to section 4 -- have to return something in one conformance format. So must be JSON. For DID resolution, it is concretely testable, right? Could make it so input parameters must be capable of being serializable to JSON.
… Single sentence in both cases...should be easy...

Wip: Yes, but should be added, so needs two be clarified. Other part is adding in the conformance class. Are we aligned on that class name? We need to conformance classes.

manu: We can name them anything -- doesn't really matter. Would be nice to resolve. "Software Library Resolver" and "Network-based Resolver". Software library deals with internal data structs which is OK if serializable. For the Network -- should be clear, use HTTP binding.

Wip: That sounds great. No one is assigned. I'll do it or ottomorac. Sound fine -- let's get something in.

ottomorac: You can have it Wip.

Review Issue Flags throughout DID Resolution document

<ottomorac> w3c/did-resolution#220

<ottomorac> Issue raised by Will, there are several red ISSUE notes throughout the DID Resolution specification.

Wip: Would appreciate people read over it -- found the "Issues" in the spec, categorized them as no longer relevant, some as needed.

<ivan> +1 to manu

manu: Issue flag needs an issue in the tracker if still relevant. Wip, do you want to go over them today?

<Wip> https://www.w3.org/TR/did-resolution/#caching

Wip -- remove -- the ones in the Caching section. Has an open issue -- moved to DID Core.

manu: Remove both -- agree.

<Wip> https://www.w3.org/TR/did-resolution/#non-did-identifiers

Wip: Security section -- move to an extension and not handling in DID Resolution. Just remove it.

<Wip> https://www.w3.org/TR/did-resolution/#resolving-algorithm

manu: +1 to remove.

Wip: Another moved to an extension about discovery methods for a resolver. It's an extension...we've said.

Wip: There is an issue tracking this and it says in the DID Extensions.

manu: +1 to remove it.

Wip: DID Resolution Architectures. This is elsewhere partially, but should we leave it in?

<Wip> w3c/did-resolution#131

manu: Perhaps an issue for Joe to ask about if this is part of other architectures. If so, then that might remove the section.

Wip: Issue 131 seems to track to that.

manu: Propose deleting the section and Issue from the spec per that issue.

Wip: Privacy Consideration. Perhaps create as an issue to create more.

https://w3c.github.io/vc-bitstring-status-list/#privacy-considerations

manu: Too generic. Remove the issue because we have a section. In other specs, there is language to use --- "you should also read the DID Core spec and then this section".
… Threat modelling has some stuff. Could use LLM to generate some ideas of what to build based on the specs and then curate the output.

Wip: For now remove it, add an issue to put in the language. There is an issue on Threat Modelling.

Wip: DID Resolution result section. Two -- remove them?

markus_sabadello: First can be removed based on DID URL Dereferencing inclusion.
… Second could be a general comment somewhere. We explain in Metadata section already, so probably not necessary anymore.

Wip: Will remove it in a PR and someone can object and add an issue.

Wip: Perhaps Markus can take a look at the last comment in the Issue 220.
… others we can raise issues to track and then remove.

TAG initial review

<ottomorac> w3ctag/design-reviews#1157

<ottomorac> As an outcome of the initial horizontal review by TAG, Will has separated the feedback into several issues which we should discuss one by one.

Wip: Encourage everyone to read the comment by Jeffrey Askin -- big favour to get in before TPAC.

Wip: Could discuss one by one. Note this is Askin's review, not the TAG review.
… Does not include the DID URL Dereferencing...he didn't review that.

Wip: issues added, could label them as TAG.

manu: Very helpful, thanks Will. Please tag them as TAG.
… When sections change, we give them a heads up on what has changed to focus his/their effort on certain parts. Probably best he waits to Dec. for the path handling part.

w3c/did-resolution#224

Wip: Should be referencing the correct DID Core version -- 1.0 or 1.1? Do a pass to get right across the spec. Should be 1.1 Wip thinks.

manu: +1
… Should still be able to resolve 1.0 documents, but in general everywhere else 1.1.

w3c/did-resolution#225

manu: Well...kind of agree / disagree. Standard URIs were centralizing, whereas the explicit purpose is to make DIDs decentralized. Could make it more grounded, but editorial. Can't object, but we could try.

ivan: Point is that what a DID is, and why it was created is part of DID Core, not in the DID Resolution spec.

I'm fine w/ Ivan's interpretation as well -- we could make it more about DID Resolution.

w3c/did-resolution#226

Wip: Should we be using resolution at all? That's what he is questioning.

<Zakim> manu, you wanted to note it's the first thing, isn't it?

markus_sabadello: We've always been using resolution. The DID can also be dereferenced. Consistent with RFC3986 in my mind. This does fit with how we are using it. I wouldn't change anything.

URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; this resolution may require several

iterations. To use that access mechanism to perform an action on the

URI's resource is to "dereference" the URI.

manu: Agree with Markus. Looking at RFC3986 -- pasting...
… what we are doing is textbook definition. Perhaps he is worried about a sentence and how we are using it. Perhaps he is saying it's "dereferencing" vs. "resolution".

<Zakim> manu, you wanted to note we need to do a complete review

ottomorac: Perhaps we need to ask more about what he is asking -- perhaps Manu or Markus put in a comment and tag Jeffrey.

<Wip> https://www.w3.org/TR/did-resolution/#introduction

Wip: The core question is are we dereferencing a DID?

manu: We should do a review of the spec to make sure we are consistent. I can't do that, too much on plate.

ottomorac: We're at time. To be continued.