We would like to open up the design process for the did:pkh method specification to a more consultative/deliberative conversation for the broader W3C-CCG community.
Regular meetings for this CCG work item will be held every four weeks on Wednesdays, from April 20th, 2022, onwards, at 12.15PM Eastern Time, on a workitem-specific jitsi room hosted by the CCG. Minutes will be published in the meetings directory here in the repo.
Our standing agenda is first PR review, then issue review (prioritized by labels, then by stalest-first). At least one of three work item owners will moderate PR review and issue review (respectively) at each meeting, with the prioritization of the latter at the discretion of the chairs. Implementers, researchers, and community members are welcome to open issues if they would like clarification of the intended or possible usages of the method. We will use the "next meeting" tag for issues and PRs that we want to discuss soon, so the next meeting label view is the fastest way to see an up-to-date agenda for the upcoming meeting(s). We are also glad to take requests for older issues to receive that label at the end of all meetings.
When agendas of interest to the general community (including ratification and review period resolutions) come up, we will manually set an agenda on the CCG mailing list in addition to this GitHub-based tracking.
Draft spec here (plain markdown)
- Juan Caballero, Spruce, @bumblefudge
- Charles Lehner, Spruce, @clehner
- Joel Thorstensson, 3Box/Ceramic, @oed
-
Explain what you are trying to do using no jargon or acronyms.
We would like to open up the design process for did:pkh to a more open and consultative/deliberative conversation in the open.
did:pkh is a generative "pseudo-DID method" like did:key that generates a DID document from blockchain addresses, conformant with the CAIP-10 specification for expressing blockchain addresses (usually based on public key hashes or "pkh"). This allows the keypairs driving most major blockchain identity systems to generate instantaneously a "pseudo-DID" (essentially a did:key) with an account. This allows short-lived, low-security DIDs to be generated on the spot anywhere a blockchain "web wallet" can be used, leaving security, account recovery, and other hard problems on the side of the blockchain that governs the address.
-
How is it done today, and what are the limits of the current practice?
Today, each blockchain needs to have its own DID method(s), and create additional software to run these. This DID method exists to create a "bridge" to blockchain-specific identity systems (and wallets, and wallet/dApp ecosystems).
-
What is new in your approach and why do you think it will be successful?
Our approach builds on other pragmatic "cross-chain" efforts in the blockchain space, including the CAIP-10 specification that it relies on to abstract out the relationship between keypairs and addresses, making it easier and more ergonomic to support many blockchains.
-
How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)
We are hoping that by opening up our DID method design process to be more open, we will hear from business and technical voices far and wide, particularly since the dApp ecosystem is fairly international and open-source in nature. If many weeks pass without input, we may do active outreach via the ethereum community and DIF.
-
What actions are you taking to make this work item accessible to a non-technical audience?
We have tried to craft a did method specification draft that is accessible and welcome PRs if it can be made more accessible.