Scope

[nadalin]

This charter does not make sense if there is nothing to interoperate on, there needs to be some DID methods defined, w/o this you can never be assured of interop, I understand there may some proprietary ones but there needs to be a base line here,

[brentzundel]

What if the WG took as a work item in their charter to publish the peer DID method spec? It is intended as a platform and data registry agnostic way to use DIDs.

This would provide:

• a means of real interoperability
• a reference implementation of a DID Method Spec
• a defined baseline for expected functionality of DID Methods

[talltree]

@brentzundel While it is tempting to expand the scope of the charter to include defining one "common DID method", that would actually violate the design principle of separating the scheme spec from any scheme instances. The pattern for the DID spec is the URI spec (RFC 3986). That spec defines the generic syntax for URIs, and all URI schemes are separate specs (in fact, the DID spec is one of those specs, i.e., a fully RFC 3986 conformant URI scheme). The goal of the DID spec is to do exactly the same for DIDs, i.e., for this WG to define the generic DID spec, and then for others to define DID method specs.

[nadalin]

@talltree Without defining methods you can't stipulate the semantics of "decentralized" (what ever that means) and thus anyone can have any method that does what it wants, and thus there will be interoperability issues.

The charter does not state the design principle of separating the scheme spec from any scheme instances.

[brentzundel]

@talltree I do not believe that allowing the WG to also publish the peer DID spec would constitute defining "one common DID method." I agree that the great power of the DID spec is the ability to define separate method specs. There are already many great method specs that have been written.

The great thing about the peer DID method spec is that it is platform agnostic. This makes it uniquely qualified to be added as a work item for the WG to provide an example of the decentralized functionality of DIDs.

My suggestion is that in addition to defining the DID spec and the DID resolution spec, the WG publish the peer DID method spec. I do not think the peer DID method spec should be part of the DID spec. It should be an additional output of the DID WG.

[peacekeeper]

I agree with @talltree that publishing individual method specs should probably be out of scope and happen elsewhere. While the "peer" method is very useful and quite different from other methods, it is still only one concrete implementation - among many - of the DID concept. In the future we may see more methods like "peer" that don't require a blockchain/ledger but use a different protocol than the Indy protocol used by "peer".

[kimdhamilton]

5/16/2019 discussion:

• proposed compromise: WG will attempt to define a DID method (as a stretch goal, if everyone can agree on it)
• counter: conflicts with URI model

[msporny]

I suggest that the interoperability criteria is the same as for the Uniform Resource Identifier and Verifiable Credentials Data Model specifications. That is, we are demonstrating syntax and data model interoperability. If the VC Data Model specification is published as a PR/REC, then it's clear that this is an appropriate path forward and what @nadalin is requesting is not necessary.

If W3C Membership determines that data model interoperability is not sufficient (demonstrated by the failure of the Verifiable Credentials Data Model 1.0 specification to achieve official W3C Recommendation), then W3C Management can add a public-key based DID Method to the DID WG as a deliverable.

Suggest that we close this issue with the plan of action noted above.

[nadalin]

@msporny Please read issue #43 as I'm asking for either method or operation level interop, I don't agree with closing this, without a statement on interoperability that all can understand

[msporny]

@nadalin, please define what you mean by "either method or operation level interop".

I also suggest that you re-read the charter as several new statements related to expected interop have been added to the charter based upon your request, namely:

The Working Group will seek evidence of independent interoperable uses of the DID syntax and data model from at least two independent implementations of each feature defined in the specification.

The group will maintain and advance a test suite enabling interoperability testing, which will ensure the deterministic production and consumption of DIDs (URI syntax) and DID Documents (data model).

Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications. (pending in PR #57)

Out of Scope: Specific DID Method specifications or Protocol specifications

This means that the group has decided to focus on interop for DID URI syntax and DID Document syntax and the production and consumption of that data. We are not focusing on defining specific DID Methods (largely protocol specifications), or the interoperability of operations provided by those methods (again, DID Method protocols are out of scope). That work is experimental and continues in the W3C CCG, DIF, Hyperledger, and other venues.

[msporny]

We discussed this on the 2019-07-02 call and the group decided to further clarify interoperability through PR #32 and PR #57 (among others that clarified deliverables and defined interop).