Re: Current status of DID Core implementations (June 2021)

I skipped about nextUpdate.

On `relativeRef`:

> 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.

The only normative statement in the test is:

it('3.2.1 DID Parameters - relativeRef - If present, the associated value MUST be an ASCII string and MUST use percent-encoding for certain characters as specified in RFC3986 Section 2.1.', *async* () *=>* {

in [1]

This part of the test will not run without `didParameters` in the implementation JSON file, and the MATTR implementation JSON file lacks the parameter. For the conditional on this, See [2].

These parameters and their relationship with actual test execution are a bit confusing.

shigeya

[1] https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/did-identifier/did-parameters.js#L25-L32
[2] https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/did-identifier/did-parameters.js#L8-L9

On Tue, Jun 29, 2021, at 11:18, Shigeya Suzuki wrote:
> obviously,
> 
> > const did_clip = (v) => { return r; }
> 
> should be
> 
> > const did_clip = (v) => { return v; };
> 
> :<
> 
> shigeya
> 
> 
> On Tue, Jun 29, 2021, at 11:03, Shigeya Suzuki wrote:
>> Hi Kyle,
>> 
>> I will look into your report, but let me respond to your concern first.
>> 
>>> 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.
>> 
>> It is not `parsing off` parameters, but the output is truncated to up to 32 characters for method_specific_id for readability reasons -- there are several methods that produce extremely long DIDs.
>> 
>> The truncation is happening just before emitting the output to the table. So it does not affect the tallying process.
>> While I still think it is a good idea to truncate it, you can locally by modifying `did_clip` function here:
>> 
>> https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/report/report-generator/recursiveRenderSection.js#L2-L8
>> 
>> into something like:
>> 
>> const did_clip = (v) => { return r; }
>> 
>> Then, the whole DID string will appear without truncation.
>> 
>> more on later.
>> shigeya
>> 
>> On Mon, Jun 28, 2021, at 23:23, Kyle Den Hartog wrote:
>>> 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/
>>> 
>>> 
>> 
>