Testing DID Method Interoperability using the Universal Resolver and Linked Data Signatures.

Sorry I won't be at the F2F in Amsterdam.

I wanted to share some recent work on testing interoperability of DID
Methods with the Universal Resolver and Linked Data Signatures.

Here is the github repo: https://github.com/decentralized-identity/context

There has been a lot of debate about JSON-LD recently.

I'm not here to convince anyone to use it.

I'm here to show you all how to test did methods that look like they
support it today.... the ones that currently have an `@context`.

There are 3 cases to consider:

1. Does the did document work with no changes?
2. Does the did document work with the did-core spec context (
https://www.w3.org/ns/did/v1 )
3. Does the did document work with a custom context (
https://identity.foundation/context/did-latest.jsonld )

The 3rd option demonstrates that all that is necessary to support JSON-LD
in a did document, is the ability to update markdown files and json files
in a git repo.

Here you can see how no network requests are being made for any of these
tests:
https://github.com/decentralized-identity/context/blob/master/tests/__fixtures__/documentLoader.js#L14

IMO, this work clarifies the technical barrier to entry for JSON-LD
adoption. I will summarize it as concisely as possible:

If you intend to allow did controllers to express their did documents as
linked data, you / they need only include an `@context` value that points
to a string, or an array of strings, in the thing that is returned from
your did method resolution process (we call this a did document, but it
might be JSON, CBOR, PDF)...

If you or did controllers who use your method add new properties to their
did document, you / they will be required to document them for the
community by updating markdown and json files... in a single github repo.

Here is an example of such a property change, which we fixed in our did
method, but which does not work when only relying on
https://www.w3.org/ns/did/v1

https://travis-ci.org/decentralized-identity/context/jobs/641895928#L292

You can see that the W3 context does not work by itself. Why? Because
"usage" was not defined.... But it works.... when usage is defined....

That's pretty much all you need to know about how to make a did method that
is linked data compliant. If you don't want to make a did method that is
linked data compliant, in my opinion, you should not include an
`@context`... I will be happy to remove did methods from this linked data
interoperability test suite, I'd love to get it to a passing state....

However, if you intend to allow did controllers in your method to include
an `@context` in their did documents, at any point in the future, please
help us develop shared a vocabulary and documentation.... by editing
markdown and json files in a single github repo.

Further, if we as a community would like to use a method other than JSON-LD
to ensure interoperability, I'm all for making a test suite for whichever
technology is picked, and I'm happy to help everyone figure out how to
support both models for ensuring interoperability assuming that is possible..

Method implementers are already able to choose between, centralized web
services, blockchains, public / private networks, supported cryptography,
capabilities like revocation, etc... Should method implementers also get to
choose if their DID Method supports JSON-LD or not?

As a Method Implementer you are responsible for making decisions about
security, extensibility and interoperability... Certainly we have community
members who would like to see Method Implementers also have the ability to
choose if `@context` is a MUST, MAY or SHALL NOT.

As a contributor to the did core spec, it's your job to remove optionality
from method implementers, to support interoperability by clearly defining a
shared core data model (schema / vocabulary).

Good luck at the F2F :)

Regards,

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>
ᐧ