Issue taken over from the CCG (w3c-ccg/did-use-cases#6).

rename the github registry (Ivan Herman) (see details)

Cc: @iherman

Block any merges when changes are requested.

Dismiss stale reviews (request re-reviews)...

make it clear when things are ready to merge, and when things are blocked... and by who they are blocked (so you can ask for feedback).

Summary

We should rename the branch master to main and use that going forward for our work.

From Problematic Terminology in Open-Source on master/slave terminology in software:

Use of this term is problematic. It references slavery to convey meaning about the relationship between two entities.

Removing this terminology from our workflow is a small gesture to include more people from marginalized groups in this project.

(I’m open to names other than main)

Technical Steps

• create main branch from master
• make main the default GitHub branch
• modify github/central to use main for release notes reloading
• redirect PRs to main in all did wg repos
• move branch protections from master to main
• modify docs to reference main instead of master
• delete master branch to avoid confusion?

Feedback?

In did-imp-guide pull/27 there is an attempt to address the formal objections with wording that cannot in detail meet the concerns of the objectors, and that - in its current vague disapproval of proof-of-work DID methods as shown by calling them out under special requirements - cannot gain consensus.

It is possible to meet some possible concerns of the formal objectors if more precisely answering the implicit accusation with details about a specific DID method.

As one of the authors of a DID method relying on proof-of-work, I'm volunteering to lead writing a response that other WG members may sign on to if they agree. This could end up as a WG Note, but if it's voted down then it will end up as a mailing list email.

In particular, I believe that along with practical reasoning, a causal model connecting the anchoring of DIDs on the Bitcoin blockchain to the alleged "fail" of the TAG/EWP sustainability goal will help all parties speak more intelligently about the issue.

Using this form of reasoning it is possible to examine the addition of each DID method anchoring transaction to the Bitcoin blockchain and quantify the additional motive to burn carbon-based fuels for electricity. This metric can be used to offset the carbon polluted into the atmosphere.

Two DID methods that will be discussed are did:btcr and did:ion. I will also critique conflicting TAG/EWP goals, discuss other moral concerns, point to transistions underway in the energy sector and speak about the economic incentives to use renewable energy, offer an example criteria to add to the Rubric so that end users can make later use of the reasoning, and offer to act as editor coordinating sections on other aspects of the formal objections, such as the request for a mandatory reference method.

Based on feedback so far, most people think that references to TAG/EWP in the Implementation Guide is enough. If that's the only response, then the concerns of the formal objectors will not be addressed directly.

pre-process the WoT issue list with Manu at w3c/wot#932 (Markus Sabadello) (see details)

Cc: @peacekeeper

create the did-imp-guide repo (Ivan Herman) (see details)

Cc: @iherman

create the did-core-registry repo (Ivan Herman) (see details)

Cc: @iherman

How does our company register a did method，Such as did:transfer, and what materials need to be provided。
Then it can be displayed on the web page (https://w3c.github.io/did-spec-registries/#did-methods)

From https://www.w3.org/TR/did-core/#path

A DID path is identical to a generic URI path and conforms to the path-abempty ABNF rule in RFC 3986, section 3.3. As with URIs, path semantics can be specified by DID Methods, which in turn might enable DID controllers to further specialize those semantics.

As far as I could tell, there are no DID methods that use these path semantics. Moreso, it is not clear from this description what these path semantics are envisioned to represent. A DID URL made by adding a query or fragment to a DID can be understood as acting on or referencing the metadata resolved from the DID. However, it is unclear if a URL made by appending a path to a DID has any particular relationship with the subject or the controller.

To put it a different way, I'm unclear what the resource is of a DID URL with a path - while a DID URL without a path is unambiguously referencing the subject as the resource.

If there are no semantics defined for it, why not leave path components reserved?