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

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

That makes sense, I must be mis reading the report then because I can't seem to find where it describes which parameters are missing.

Related to the part about relativeRef, I think there's been some confusion on what needs to be put in the various implementation reports. Looking at the dereferencer example, I didn't see any didParameters listed in the example. I did however see them in the did syntax parsing tests which is why I included them here[1]. Put another way, what part of my software am I expected to be checking with that section? The only thing I could remotely think off is my isDidUrl validator, but there's no input/output portion there so in my mind that's just a syntax checker, but how am I supposed to be generating the URLs for that syntax checking and what am I indicating if I include or exclude one there? Or am I supposed to be including that section in the dereferencer report?

https://github.com/w3c/did-test-suite/blob/992369bda6fd78314a4bae7f969e0a5fb11dbb2f/packages/did-core-test-server/suites/implementations/did-web-mattr.json

________________________________
From: Shigeya Suzuki <shigeya@wide.ad.jp>
Sent: Tuesday, June 29, 2021 2:49 PM
To: public-did-wg@w3.org <public-did-wg@w3.org>
Subject: 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/