Meeting minutes
Agenda Review
Wip: we have a basic agenda today.
… Status of DID-core by Manu, looking at PRs for DID Resolution.
… Then I want to spend time of DID Resolution issue processing.
DID Core Update
manu: No issue we need to focus on. DID-Core is in a fine shape.
… We have ways to move forward about fragments in DID-URLs (which we discussed previously), PR coming.
… Overall, the text is fine; I don't think we have figured out how to prove interop for the 1.1. spec.
… We need to have this dicussion.
… We need horizontal reviews done as well, they are on other groups.
… We would like to get DID 1.1 as CR for TPAC, possibly before.
Wip: what is your take about how we can prove interop?
manu: in a perfect world, we would have multiple DID implementers upgrading their method to DID 1.1.
… I don't know if we would get much coverage, given the number of DID methods.
… Another possible path: we have a bunch of DID documents provided by people.
… We could inject the new 1.1 context in these documents and check that JSON-LD processors handle them correctly.
… This would prove that we have not made any backward incompatible change, and that the new 1.1. context will not break 1.0 implementations.
… This is hacky but I suggest that we do that. It is doable in short time.
… Another possible path, better in the long term:
… use the interface we are using for DID resolution, and modify the test suite to modify the context that comes back.
… At Digital Bazaar, we plan to use the 1.1 context in the documents we return.
… That would be more work, but better in the long term, compared to the current static test suite that we have.
… To summarize:
… option 1: modify the current test suite, search and replace the 1.0 context with the 1.1 context
… option 2: modify the DID resolution test-suite, replace the context
… option 3: update the DID resolution test-suite, have people use the 1.1 context
ivan: when replacing the 1.0 context with 1.1 context, how do we prove we didn't break anything?
… I would assume by computing the hash based on RDF C14N and check that it didn't change?
manu: that's one way to do it
… some implementers do not want to use JSON-LD but we only need two to pass.
Wip: I like the hacky and quick option, but will it satisfy W3C?
… we could mix it with option 3: use native 1.1 implementation when available, or patch 1.0 implementation otherwise
ivan: doing the first one avoids to open the floodgate of discussions with outsider
… the changes in 1.1 are not changing the documents, as per our charter
… 1.0 documents have already passed the tests for 1.0; we do the minimal thing to validate our minimal changes
Wip: I like that, but let's not forbid ourselves to prepare the future with option 3.
DID Resolution PR Processing
<Wip> https://
Wip: Markus is not on the call, but we can discuss some of the PRs.
w3c/did-resolution#180
swcurran: I think this one is ready to go. Manu made some suggestions.
Wip: OK, I will let Markus know.
… Please everyone also have a look at w3c/did-resolution#178 and w3c/did-resolution#179.
DID Resolution Issue Processing
<Wip> https://
w3c/did-resolution#38
Wip: we need to decide what we need to address this issue.
JoeAndrieu: I think we still need to deal with this.
… It fits within the scope of the "Resolution architecture and thread modelling" stream.
… We've made some progress since this issue was opened.
… There are related issues (on Threat modeling).
Wip: I'll put a link to the related issue
w3c/did-resolution#148
Wip: this one is a good "first issue" for submiting a PR
<manu> https://
manu: I'm looking at what the current reference is.
… Specref (link above) crawls all W3C and IETF specifications and allow to make references.
… The good news is that the refs are now auto-generated.
ottomorac: I can do it.
w3c/did-resolution#131
Wip: I guess this one is related to the threat modeling discussion.
JoeAndrieu: I have seen this, didn't have time yet to dig into it, but will do.
w3c/did-resolution#172
Wip: this one was originally raised against DID-core.
… We discussed this, concluding that DID Resolution should set a limit.
manu: it probably should not be in the Security Consideration section, it should go in the main text, and we should have a test for that.
… It will be painful to write that test, but it is important.
Wip: I'm trying to work through what the problem described is.
manu: you resolve a DID, find the verification method from the DID document, and the verification method lives in a separate document.
… that other DID document points back to the original document, creating a cycle.
… This would be an attack. To prevent it, you keep track of the URLs you join to and detect cycles and avoid looping forever.
Wip: so we need text in DID Resolution about detecting these cycles. Should be straighforward.
swcurran: it's at the level of a universal resolver. Most resolvers resolve a single method.
manu: it depends on the method. did:key can not have this problem, but did:web can.
… Not all implementation should demonstrate that they have cycle detection, but we only need two.
<dmitriz> heh the other thing I bet most resolvers don't currently deal with is -- controller logic
manu: May be what I just explained is not even possible with the spec, we need to explore this.
<dmitriz> like, if a did has no methods but its controller does, which resolvers fetch those
manu: We need to see what happens with did:web in particular.
… We could provide two did:web document that point to each other, which would prevent people from writing their own test.
Wip: I would like to assign this issue.
swcurran: I'll take it, sounds like fun!
w3c/did-resolution#133
<dmitriz> though I think this is ok because our spec currently is very light on Controller semantics
Wip: IIUC, this issue is about providing some architecture diagram from which we can derive Security and Privacy considerations.
JoeAndrieu: that's a good description
w3c/did-resolution#92
Wip: This test suite is pointing to a place controlled by the VC test suite.
… I'm wondering whether we should create our own repo.
manu: we could do that, and I think that's what Benjamin was thinking.
… we have gotten to a state where we have 3 such repositories...
… it would be nice to get down to 1 implementers repo.
… people could contribute their implementations and opt-in to different test-suite, regardless of the WG working on them
<Wip> w3c-ccg/
<Wip> w3c-ccg/
Wip: the did-resolution-mocha-test-suite repo, containing our test suite, is currently pointing to the vc-test-suite-implementations repo for the list of implementations
<Wip> https://
Wip: it is strange that the latter says "VC" but maybe that's ok.
<manu> Here's the other one, to make things even more complicated: w3c/
Wip: the JSON file above is how Danube Tech defines their implementation of the test suite
manu: I think we should get rid of the CCG repo
… and we should agree (amonst the CCG, the VC and DID WG) to put all our implementations in the same repo
… let's not fork it!
ivan: I presume that includes future WG as well...
… like the proposed DID Methods WG
manu: exactly
… that means that registered implementations must be able to indicate which test-suite their expect to pass
w3c/did-resolution#173
Wip: TallTed, do you want to talk about this?
TallTed: I know this is an issue, but I don't know what the answer is.
manu: TallTed is correct, it is a problem.
… I'm wondering if we need to say anything, though.
… In any context, when you run an HTTPS in a local environment, you need to jump through some hoops, that are not good security practices
… Maybe just a sentence in the Security Consideration section: "if you run an HTTPS service on a private IP range, consult your sysadmin"
… we should not explain *how* to solve it.
TallTed: I agree
Wip: I would like somebody to volunteer to write a PR for that.
… Otherwise we will have to close this.
manu: not volunteering, but this is the kind of job an LLM could help with.
w3c/did-resolution#174
Wip: this one is about specifying a new error code.
ottomorac: I can take it.
Wip: good, you should have a look at the error's section.
w3c/did-resolution#161
Wip: I don't remember where we are with this one.
… Currently, DID Resolution is specified with GET only. We discussed supporting also POST or only POST.
… Some people are reluctant to drop GET.
manu: reading through the minutes from last time, I think we agreed to do both.
… Markus argued that banning GET would make old resolvers non-conformants.
<swcurran> +1 to MAY on POST
manu: We could say "you MUST implement either POST or GET."
… It would create complexity for the test suite.
Wip: we need to figure out what we want as a group.
… It was a great call, we pretty much got through the first page of pending issues, and assigned a bunch of them.