Meeting minutes
ottomorac: reviews current progress and agenda
… Any questions?
pchampin: Email from Julian from ISO about the decentralized identity architecture.
… basically very positive. we can go for category A liason for TC307
… I'll work on that form with a goal of end of this week
Debrief DID Test Suite Special Topic - 23rd July w3c/did-resolution#92
ottomorac: first topic: test suite topic call
wip: It was a great discussion. Markus wasn't there, so we want some feedback.
… We want to pick 1-5 normative statements in the spec we feel are stable ...
… Manu?
manu: Good discussion. The things we talked about were like what would be the best way to create the test. 1. We have to extract all the normative statements.
… initial extract: 82 statements.
… Concern that is a lot of statements.
… Concern raised that these tests take a lot of effort
… and we want to avoid problems we had with previous approaches.
… specifically avoiding static tests
… we want to ensure that the test suite can be regularly run to make sure conformance is maintained
… There was a discussion about starting small and focused and get to an end-to-end scenario with at least two different implementations?
… If we can, then we can expand to more tests
… Also discussed how disruptive it is for the spec to change after tests are written.
… So we discussed how we as a group figure out how implementers should run the test
… No one signed up for leading the test suite. Will mentioned willingness to help, as did Digital Bazaar, but neither could take the lead.
… Then, towards the end, we talked about concrete things to move the test suite forward.
… 1. Pick an architecture. (Reuse VC 2.0 or something else)
… I can go into detail about what that means, but if we have consensus on that, the downstream decisions get easier.
… Next question is what are the first 5 tests and what organizations are going to provide endpoints?
… Another key decision to make: do we require that each resolver work against at least one did method? or do resolvers bring their own method
ottomorac: some of these tests might be automated. Was there a discussion about hiring a tester?
manu: I think it would be good for us to take some resolutions with the test suite
<Wip> +1 to resolutions
manu: Will had suggested some proposals. I have some rough ones written up.
ottomorac: let's go to that
manu: I have three rough proposals
… first is to make the test suite did method agnostic
… the alternative is we would need to require that all resolvers resolve a specific DID method for testing, such as a did:key
… So the resolver tells the test suite which methods it supports
markus_sabadello: I think its a good idea based on our experience.
<Wip> *chair hat off* I strongly prefer the BYO DID Method approach
markus_sabadello: when you submit your implementation, you specific a number of DIDs and expected results and we run against that.
ivan: Nothing against it, but to make it automatic, we'll need a clear way to identity each method.
manu: it will literally be a DID that it supports
ivan: ok. that works.
<JoeAndrieu> +1
<ottomorac> PROPOSAL: Make the DID Resolution test suite "DID Method agnostic" (each endpoint specifies legitimate and invalid DIDs to use against the implementation)
<ivan> +1
<manu> +1
<Wip> +1
<JoeAndrieu> +1
<ottomorac> +1
<pchampin> +1
<markus_sabadello> +1
<KevinDean> +1
RESOLUTION: Make the DID Resolution test suite "DID Method agnostic" (each endpoint specifies legitimate and invalid DIDs to use against the implementation)
<TallTed> +1
ottomorac: ok. thanks for that.
…
manu: two more to consider
… The next one is imperfect, but the general architecture of VC 2.0 can be reused
… I think this is a solid improvement over the original DID test suite
… these are mocha driven tests that output JSON we format for humans
… hundreds of thousands of dollars of work that we can reuse
… Then we just need to write the literal tests
… The only thing I'm concerned about is that Danube Tech did build a test suite.
markus_sabadello: I would have suggested the same thing. All these tests suites (VC-related) have been successful, so starting with that as a basis is great.
… And we can help with specific tests by copying what we have into the VC framework
ottomorac: Does this architecture require the use of Mocha?
manu: Yes. It does use Mocha. We don't have to use it, but it would be more work to replace it
… Let's reuse as much as possible
bigbluehat: what we're getting from Mocha is the reporter integration. We could use something else, but it would basically be starting over.
… The tests can be rewritten in another language, but the framework with mocha/chai/javascript would be non-trivial to replace that
<ottomorac> PROPOSED: For the DID RESOLUTION test suite - adopt the test suite infrastructure that was used for VC v2.0; configuration based, HTTP API driven, runs at a regular interval, generates JSON output, formatted into a human-readable report.
<Wip> +1
<JoeAndrieu> +1
<bigbluehat> +1
<markus_sabadello> +1
<TallTed> +1
<ottomorac> +1
<JennieM> +1
<manu> +1
<pchampin> +1
<KevinDean> +1
<ivan> +1
<smccown> +1
RESOLUTION: For the DID Resolution test suite - adopt the test suite infrastructure that was used for VC v2.0; configuration based, HTTP API driven, runs at a regular interval, generates JSON output, formatted into a human-readable report.
manu: hopefully an easy one. We're going to start small.
<ottomorac> +1 , fully agree to start small
manu: this is modest guidance to the person writing the initial tests
… Then we will decide how to flesh out the rest of the tests as things stabilize
<ottomorac> PROPOSAL: For the DID Resolution test suite, focus on a small number (~5) of end-to-end tests with at least two implementations to start.
<manu> +1
<ivan> +1
<pchampin> +1
<JoeAndrieu> +1
<ottomorac> +1
<Wip> +1
<markus_sabadello> +1
<TallTed> +1
<smccown> +1
<bigbluehat> +1
<KevinDean> +1
<JennieM> +1
RESOLUTION: For the DID Resolution test suite, focus on a small number (~5) of end-to-end tests with at least two implementations to start.
<Zakim> JoeAndrieu, you wanted to ask DDOS question
JoeAndrieu: I wanted to ask, If I have resolver that wants to work with these tests... I think we agreed that I need to have resolver up and running to respond to these tests, how to handle denial of service?
manu: I think we had this concern before, we could use a docker based approach....
manu: yes. that was a concern with VC 2.0, but nobody had a problem with that. We do have a docker option.
… that could be a way to provide a non-DDOSable way to do it.
<bigbluehat> +1
manu: Also we have authorization turned on for some of the VC services.
… So that would also be a way to do it. Oauth or ZCAPs.
… Github secrets manage the access tokens
<Wip> My connection is still a little spotty. I just wanted to flag, that we will aim to schedule another special topic call soon to make progress on the test suite work. Especially focusing on selecting the 1-5 statements
Unaddressed denial of service vector #897
Issue raised by Victor Dods in regards to possible loophole for infinite did resolutions related to various way in which we refer to the term controller in the spec. He sees a risk for infinite loops which he thinks should be addressed in the security considerations section. Will has provided some comments on it. And Manu is suggesting that we perhaps move it to DID resolution.
ottomorac: manu thought this might be more a did resolution issue than did-core
manu: I can do the move. Basically we had to provide advice that did resolvers need to detect cycles and make sure they don't get lost in infinite loops
DID Resolution PR Processing
add security consideration about how noCache can lead to DDOS so clients should expect that servers may deny cache bypass #171
Feedback has been provided by Manu and Will on the PR.
ottomorac: feedback from Manu and Will. Markus anything to point out?
markus_sabadello: I haven't been able to review yet. It makes sense.
wip: Wanted to add, the PR is great. But there is a mention of an error in there. We probably need to add the error to our error list.
<Wip> This bit "Resolvers that deny resolution without caching can respond with an error that makes it clear that bypassing the cache was not permitted "
markus_sabadello: I agree. If we say there's an error, we should also define that using problem details and error codes
… we already have a few errors specific to resolution. So we should add it
Remove "Future Work" section #170
Suggestion from Markus to remove this section from the spec since we haven’t had much suggestions and corresponding issues have been closed and/or moved to DID Extensions
ottomorac: this seems to have general agreement
markus_sabadello: it just made sense to me. There were three topics: JSON Pointers, Introducing Proxy Service and Introducing redirection functions.
… Those discussions, we moved these things to extensions
… Unless we want a list of future extensions, we can just remove this
… But I'm not sure we should have such a list
<ivan> +1 to remove this
<JoeAndrieu> +1 to remove
<pchampin> +1
Write examples as text instead of PNG images. #168
ottomorac: this next one is examples in text instead of images
markus_sabadello: used to be a lot of PNG documents, largely replaced with SVG docs
… this one replaces images directly with text (JSON)
Remove a few issue markers #169
ottomorac: mostly editorial.
markus_sabadello: In some sections there are references to old issues. So this just removes the ones that have been closed.
DID Resolution Issue Processing
Add DID Resolution architecture security and privacy considerations #133
Add DID Resolution architecture security and privacy considerations #133
What considerations do implementers of the resolvers need to have in mind. Joe had referenced “RFC 3552 Guidelines for Writing RFC Text on Security Considerations” indicating that in the work with Simone this was incorporated.
JoeAndrieu: Simones suggestion is that security consideration sections be done as threat model and the walk through the various types of threats....
JoeAndrieu: I am still working with Simone, so we should probably revisit later
ivan: would that kind of requirement be there for already existing recommmendations that get republished. Do we need it for DID spec as well.
Ivan: Is this something that we should do for the did spec as well?
JoeAndrieu: I think it is desirable, but perhaps not required.... The goal we have is to have a threat model framework that any spec in the W3C VC spec can fit into...
Ivan: I have some doubts about it.....
markus_sabadello: I've been thinking about security consideration. I agree we need more work. The threat modeling sounds useful.
… One thing is the specification has a section about resolver architectures. Which introduces some security related topics.
… How to read from a VDR, how to talk with a resolver, and proofs and meta data.
… So how does that relate?
JoenAdrieu: the diagrams are the right place to start the work....
S /JoenAdrieu/JoeAndrieu/
manu: Just to react to did-core consideration request. I'm not sure what the ask would be.
… I don't think it's quite there yet. It's a lot of work. I'd rather not redo that section until we have a good guidance on what to do.
Complete threat modelling analysis for different DID Resolution architectures #132
ottomorac: there is another issue.
ottomorac: should we merge these?
markus_sabadello: Will created that one.
… My recollection is that there is maybe an interest in describing the architectures in a general way (as it is now) but maybe also concrete examples.
… This feels like adding the specific examples.
ottomorac: sounds like this is more specific for each architecture.
… this is also blocked by having more guidance
JoeAndrieu: this is not blocked by Simone's guidance.... I think the security considerations section does need to wait, but the let's dive into the diagrams....
<Wip> Yep I think so. We first select the architectures, then model the threats
<manu> agree ^