- From: Kyle Den Hartog <kyle.denhartog@mattr.global>
- Date: Mon, 28 Jun 2021 14:23:10 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>, Oliver Terbu <oliver.terbu@mesh.xyz>
- CC: W3C DID Working Group <public-did-wg@w3.org>, Joel Torstensson <oed@3box.io>
- Message-ID: <SY4P282MB07964E60455C2990673F4E79FC039@SY4P282MB0796.AUSP282.PROD.OUTLOOK.COM>
I think we might be getting confused based on the report. The problem appears to be that the report is parsing off the parameters with ... and instead shows each one as independent implementations in the report instead. For example, in section 3.4.5 [1] our implementation is submitted as a single report, but appears as an independent implementation for each input/output case we included in our implementation report. I don't have any suggestions on how to improve this though, just want to call it out as why we're probably talking past each other. Here's [2] the did:3 implementation which contains the nextUpdate and nextVersionId properties. This shows up as "@ceramicnetwork/3id-did-resolver" in the implementation report, but leaves method undefined on the report. Here's [3] the did:ethr implementation which contains the nextUpdate and nextVersionId properties. This shows up as "ethr-did-resolver" in the implementation section, but leaves method undefined on the report. Here's [4] the MATTR implementation of relativeRef and service parameters. This shows up as "MATTR internal libraries" in the implementation report but leaves method undefined on the report. Here's [5] the "https://github.com/OR13/deno-did-pm" (Orie's implementation) for relativeRef and service parameters. This shows up as "https://github.com/OR13/deno-did-pm" in the implementation report and leaves the method undefined on the report. As far as I can tell, those URL parameters are covered. Scouring through the dereferencer reports (all prefixed with dereference-*) here [6] though, I'm not seeing any that use the hl parameters. Hence me offering to implement one if someone else is willing to commit to it as well. [1]: https://w3c.github.io/did-test-suite/#report-by-test-suites-did-url-dereferencing [2]: https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/suites/implementations/dereferencer-3-3box-labs.json#L25 [3]: https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/implementations/dereferencer-ethr-2021-consensys-mesh.json#L24 [4]: https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/implementations/dereferencer-mattr.json#L108 [5]: https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/implementations/dereferencer-web-transmute.json#L22 [6]: https://github.com/w3c/did-test-suite/tree/main/packages/did-core-test-server/suites/implementations ________________________________ From: Manu Sporny <msporny@digitalbazaar.com> Sent: Tuesday, June 29, 2021 2:00 AM To: Oliver Terbu <oliver.terbu@mesh.xyz> Cc: W3C DID Working Group <public-did-wg@w3.org>; Joel Torstensson <oed@3box.io> Subject: Re: Current status of DID Core implementations (June 2021) On 6/28/21 9:59 AM, Oliver Terbu wrote: > I briefly checked with @Joel Torstensson <mailto:oed@3box.io> and he has a > different opinion. It is quicker if he replies since he thinks that did:3 > is not a partial implementation of `nextUpdate` and `nextVersionId`. What would be more convincing is just submitting an implementation report that demonstrates the unimplemented features. :) I'm sure it's implemented... just submit an implementation report for did:3 that demonstrates that. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Monday, 28 June 2021 14:23:30 UTC