Meeting minutes
scrbe+
Agenda Review
Scheduling for June 19th
Wip: Next week's meeting June 19th is a US holiday - skip it?
Wip: inclination to have the call on the 19th.
APAC DID Wg Collaboration
Wip: APAC attendance has been low. Relationship with Asia Pacific colleagues collaboration ideas? Next APAC meeting is in the Asia Pacific.
ottomorac: cancel APAC calls until TPAC to re-engage at that point. Manu suggested the Shigeyu (sp) might worth consulting to get ideas for jumpstarting the group.
Wip: Concerned about cancelling the calls. Who should we be talking to in the Asia Pacific region?
Wip Will reach out to Shigeya and others to search for ideas.
DID Method Standardization Wg Update
Wip: Marcus wanted to update us on standardization work.
<pchampin> https://
<pchampin> w3c/
pchampin: has a few PRs open. Scope of EU methods, excluding blockchain, and look a whether the scope fits in the attention of this group.
DID Resolution PR Processing
<Wip> https://
w3c/did-resolution#157
Wip: majority of PRs are ready to be merged so everyone should take a close look at them.
Wip: DiD resolvers should be aware of requesters - questions?
<ottomorac> Looks good
DID Resolution Test Suite
Wip No one on the queue. Or input to this PR.
w3c/did-resolution#92
<Wip> w3c-ccg/
Wip: Test suite for the DID resolution - good start but needs significant changes. 87 MUST statements need tests.
<ottomorac> Seems to be using the cypress testing library
Wip: Resolver URL and set of tests in the /fixtures folder. Does the test suite expect HTTPS url bound to the results. Every resolver needs test cases that may use different DIDs. How are we handling errors? No place to submit resolver implementations
Wip: if there are 87 MUST statements do all need tests?
dmitri: Ideally yes.
Benjamin Young: W3C testing requirements are testing the spec not necessarily the code though you are doing both. Need to assure the test suite is aligned with the spec to make it implementable. Can have requirements on other specs, downstream specs, etc. MUST doesn't mean it's a requirement of the code. Are the tests automatable
Wip: for these resolvers this DID support the implementation and resolve per the spec
Wip: next step to move test suite forward? SHould we continue to work on the CCG test suite or leave them to work on it?
ottomorac: most of this work was done for folks working under Marcus. Is it a you can have untestable MUST statements, is that something that needs to be addressed or left for testing in non-code ways?
bigbluehat: just kept a list of those that they couldn't implement them. Helpful in development. Ultimately had to take them out or comment them out as it concerned people if they appeared in the report. Provided a separate list of those were unimplementable because they weren't for software.
Benjamin Young: this didn't cause any raised eyebrows. These are implementation not test but spec tests
swcurran: should be a list of tests that a DID method should implement. List what you want to test (the inventory), then the DID method would construct DIDS and some bad DIDs to test different conditions. DID resolution test resolves the DID in layered approach. Creating the inventory is key.
Wip: Resolver implementations need to prove the resolve the DIDs in all the cases they are for.
bigbluehat: creating a test suite API sounds like what we're talking about. Just a minimal API. If you were doing something different from VC-API you could wrap it in VC-API then the test suite is always communicating with the same 2 or 3 endpoints. Someone needs to look at the shim to make sure that's not introducing issues. Test suite authors
will be few and stressed to do their work
<Wip> w3c/
Note Benjamin Young is bigbluehat in the above comments
swcurran: you have a test that's a list of DIDs and run them through the resolver. Any DID resolver needs a way to pass in a DID to it.
<ottomorac> +1 to universal resolver as swcurran suggests
Wip: want DIDs and resolutions options as a package as required by the API
swcurran: it's the DID url not just the DID
<Zakim> JoeAndrieu, you wanted to suggest it's not the resolver but the method that needs it
JoeAndrieu: every resolver doesn't need http interface. A resolver might be a library, does that library need to open of an http socket?
JoeAndrieu: for the sake of testing we're using http
Wip: would like some help moving this forward - perhaps from the CCG
bigbluehat: the test suites are a working group products. They can begin in the CCG but final test suites need to be workgroup produced. Can work on both at the same time. Bitstringstatus list didn't get into the WG until the last minute but that's an exception. The WG needs to say these are our tests.
swcurran: sounds like there is a test suite is in scope for this group. But isn't it just a list of tests the DID method should implement
Wip: Disagree, as we're testing resolvers. This group needs to define the tests then hit the resolver to see they work.
Wip: verifying the test is they are resolved.
Swcurran: need to define a set of tests
bigbluehat: yes, define the tests and see who can implement them. You're testing the implementation not the Spec. One did method testing the resolution spec but there is value in each of the methods showing up with the test suite showing the resolution spec is implemented against the MUST statements.
<Zakim> JoeAndrieu, you wanted to say this is interoperability
Wip: resolvers abstract over the different DID methods.
JoeAndrieu: point of the tests is test the resolver not the methods. If every resolver has a http endpoint. What's the common interface that makes sense so we have a standard interface
Wip: next step - look at the MUST statments and figure out what the test are for them.
Wip: need a place for doing that work
bigbluehat: recoommend putting MUST statements in an md file and go through what it would take to test them.
ottomorac: going back swcurran, leverage what the universal resolver is doing to accomplish these test. Enshrine universal resolver as a way of testing this.
Wip: universal resolver is one way to do this but there should be others.
Wip: agrees with bigbluehat's point that we reach out to others on this.
swcurran: universal resolver could be a good tool for the resolution spec itself. But there is one implementation per DID method. DID methods may need 4 implementations of their DID method and need four ways to resolve. The universal resolver is only one.
bigbluehat: agree's what swcurran's suggesting but for the W3C's process
bigbluehat: the only must is between the resolver and the implementation spec.
<swcurran> For context to what Benjamin is saying -- in the did:webvh group, we are doing all the same things -- inventorying MUSTs, defining tests, creating DIDs for resolution.
<ottomorac> noted
bigbluehat: If there not requirements by W3C we should leave them for the CCG and others. Narrowing for getting WG effort done. If it's not a W3C spec it's not formally needed.
Wip: could define a common data structure as one output.
sriibe 1
scrb