search

w3c / did-core

W3C Decentralized Identifier Specification v1.0
https://www.w3.org/TR/did-core/
Other
395 stars 93 forks source link

Decentralized Identifiers Improvement Proposal (DIIPs) #530

Open jonnycrunch opened 3 years ago

jonnycrunch commented 3 years ago

Similar to the Ethereum Improvement Proposals and the Aries-RFCs, I like to proposal a framework for updating the DID core and DID-spec registries.

OR13 commented 3 years ago

I think this is necessary, so we have a place to collaborate on improvements, before we see concrete PRs.

peacekeeper commented 3 years ago

Hmm has anyone ever done this for something that is specified/maintained by a W3C WG? When would you create a DIIP vs. raising an issue on a spec repo?

rhiaro commented 3 years ago

It does seem like the CCG would be the place to incubate such proposals (before then presenting them to the maintenance WG), but I'm not sure if any additional process would be required on that end specifically for DIDs, or if the existing task force structure would suffice.

msporny commented 3 years ago

Hmm has anyone ever done this for something that is specified/maintained by a W3C WG?

I'm not aware of any WG that has taken this route, specifically because there are maintenance WGs and spec revisions that deal with this issue.

Similar to the Ethereum Improvement Proposals and the Aries-RFCs, I like to proposal a framework for updating the DID core and DID-spec registries.

Improvements are typically done via our existing DID Spec Registries process (which we have a preliminary process for at the top of the spec). That is:

  1. Raise an issue wherever you think it's most useful to do so, discuss, propose some sort of solution, discuss until there seems to be consensus.
  2. Write a spec/PR of some kind in whatever community in which you want to operate. Defaulting to W3C CCG and using their work item process is fine.
  3. Register your spec as a DID Spec Registries extension.

If you need to make a change to DID Core (which you shouldn't have to do in a large number of cases) put in a PR to the main DID Core spec.

As a general rule, I'd like to avoid the "Improvement Proposal" pattern for the core spec -- it's always very confusing when it comes to which DIIP would override language in the core spec, and which does not. W3C tends to just re-issue a new spec when core stuff changes and that makes implementers lives much easier -- you always know that the spec you're looking at contains everything you need to know in order to do a conformant implementation.

jonnycrunch commented 3 years ago

I have a template ready that I've used for other projects, but would love feedback from the group that this is a good direction. Personally, I like to have a formal process of proposing new additions / improvements to the spec and would certainly help wrangling all data in the spec.