Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wg/did] Did wg 2023 team proposal #448

Merged
merged 9 commits into from
Nov 30, 2023
Merged

[wg/did] Did wg 2023 team proposal #448

Changes from 8 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
bf15703
address #447
pchampin Sep 24, 2023
aacf57d
remove DID methods, and make DID resolution a REC track deliverable
pchampin Sep 24, 2023
a34539e
add specific exit criteria discussed during TPAC
pchampin Sep 24, 2023
9630c30
Update 2023/did-wg.html
pchampin Oct 3, 2023
ca925c4
Update 2023/did-wg.html
pchampin Oct 3, 2023
1ecaa35
rephrase the requirement for two independant DID methods
pchampin Oct 18, 2023
70a1458
typo
pchampin Oct 19, 2023
d8df047
Change DID Resolution success criteria
pchampin Oct 30, 2023
8cc49a2
Brent Zundel is now an IE
pchampin Nov 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 16 additions & 37 deletions 2023/did-wg.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,10 +78,9 @@ <h1 id="title"><i class="todo">PROPOSED</i> Decentralized Identifier Working Gro
<p class="mission">
The <strong>mission</strong> of the
<a href="https://www.w3.org/2019/did-wg/">Decentralized Identifier Working Group</a>
is to maintain the <a href="https://www.w3.org/TR/did-core/">Decentralized Identifiers (DIDs)</a>
specification and related Working Group Notes. The WG will also seek consensus
around the best way to achieve effective interoperability, possibly through the
specification of DID Resolution and/or DID methods.
is two-fold. First, it will maintain the <a href="https://www.w3.org/TR/did-core/">Decentralized Identifiers (DIDs)</a>
specification and related Working Group Notes.
Second, it will define common requirements, algorithms, architectural options, and various considerations for the DID resolution and DID URL dereferencing processes.
</p>

<div class="noprint">
Expand Down Expand Up @@ -151,12 +150,10 @@ <h2>Motivation and Background</h2>
level changes on the Recommendation.
</p>
<p>
The Working Group will also seek consensus around DID Method specifications, and
may produce related documents.
The Working Group will also take over the work started by the Credentials Community Group around <a href="https://w3c-ccg.github.io/did-resolution/">DID Resolution</a>, to define common requirements, algorithms including their inputs and results, architectural options, and various considerations for the DID resolution and DID URL dereferencing processes.
</p>
<p>
The Working Group will begin working toward a specification for DID Resolution
and DID URL Dereferencing.
It is expected that these two goals will be taken by distinct task forces in the WG.
pchampin marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It is expected that these two goals will be taken by distinct task forces in the WG.
It is expected that these two goals will be taken by distinct task forces in the WG.
The Working Group MUST pursue consensus in any task pursued under the name of the working group--whether by Chairs, Editors, or other contributors--including any Notes for publication by the WG and any Charters for a future DID WG.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Along with my proposed changes, I support this change and have budgeted my time and energy to continue to escalate objections against any further work planned by this WG that could possibly abuse process in the ways that I have so painfully observed when its members are not properly constrained.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have always assumed that this proposed language applies anyway, but I guess it helps to emphasize it, so I'd support this too.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have always assumed that this proposed language applies anyway

I would be willing to resubmit a pull request substantially similar to DID Implementation Guide pull #36 if this WG, under the current heightened scrutiny, agrees that pursuing consensus is required for Notes.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that although the email summaries reference the original change proposed by @pchampin , which looks like:

It is expected that these two goals will be taken by distinct task forces in the WG.

the current text under discussion is:

The Working Group MUST pursue consensus in any task pursued under the name of the working group--whether by Chairs, Editors, or other contributors--including any Notes for publication by the WG and any Charters for a future DID WG.

So if you are only reading along in email then you will be misled.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jandrieu just to be clear about the changes you suggest above :
by "pursue consensus", do you mean to rule out completely recourse to Section 5.2.2. Managing Dissent and Section 5.2.3. Deciding by Vote of the process?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not. I mean to make sure that staff & chairs don't assert that actions taken in the name of the group do not require the seeking of consensus.

</p>
</section>

Expand All @@ -182,10 +179,7 @@ <h2>Scope</h2>
</ul>

<p>
The Working Group may also publish new Working Group Notes, Editors Drafts, or
Working Drafts for DID Resolution or DID URL Dereferencing, or of DID Method
Specifications. Any new documents intended for Recommendation will be
limited to the Working Draft maturity level.
The Working Group may also publish new Working Group Notes.
pchampin marked this conversation as resolved.
Show resolved Hide resolved
Copy link

@rxgrant rxgrant Oct 29, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Working Group may also publish new Working Group Notes.

Remove the Notes. The working group will not publish any new notes. See also change in "Out of Scope" section.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot suggest changes in the "Out of Scope" section, because this is not my pull request. @pchampin , please implement @iherman 's suggestion to state that Notes are out of scope.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making all possible Notes out of scope for the next DID WG would be a severe limitation. I'm not understanding the reasoning behind this?
The nature of a Working Group is to produce Recommendations. Sometimes these Recommendations are benefitted by the additional publication of useful documents that are associated with the Recommendation.
A ban on all Notes would prohibit the next DID WG from publishing anything other than Recommendation track documents. It would formally put out of scope any updates to the DID Method Rubric, DID Use Cases, DID Implementation Guide, etc.
Without a strong argument from a large group in support of removing Notes from the charter, I could not support this step.

Copy link
Member

@msporny msporny Oct 30, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @brentzundel. I can't think of a recent W3C WG that was limited in this way from publishing Notes. Digital Bazaar would not support such a limitation because part of what a maintenance WG needs to do is maintain the Notes it has already published... the Use Cases, Rubric, and Implementation Guide being at least among the set of Notes that need to be maintained.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@brentzundel

It would formally put out of scope any updates to the DID Method Rubric, DID Use Cases, DID Implementation Guide, etc.

This is a straw man argument. I have not proposed a ban on all notes. I have proposed a ban on new notes. If there are new notes that you want, let us know now.

@msporny

You are supporting a straw man argument. If there are new notes that you want, let us know now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rxgrant, my understanding is that @jandrieu's proposed change adequately addresses your issue about notes (that's how I read your response). Therefore, I'm resolving this conversation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unresolving this conversation, as I had misunderstood @rxgrant's comment. My apologies.

Copy link

@peacekeeper peacekeeper Nov 17, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Working Group may also publish new Working Group Notes.
The Working Group may also publish new Working Group Notes. Working Group Notes will not include DID method specifications. The Working Group however welcomes and may support efforts to standardize DID methods in other Working Groups and/or organizations.

@rxgrant and others, how about something like this as an idea?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Working Group however welcomes and may support efforts to standardize DID methods in other Working Groups and/or organizations.

It's not okay to me to ask the WG to "support efforts" elsewhere. That has all the same problems as doing something in the WG!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

proposal: Notes should not include submissions for DID Methods and should not address issues regarding any particular DID Method. The WG welcomes DID Method standardization outside the WG (whether in the W3C or in other standards bodies).

</p>

<section id="section-out-of-scope">
Expand Down Expand Up @@ -224,7 +218,7 @@ <h3>
The Working Group will maintain the following W3C normative specification:
</p>

<dl>
<dl id="deliverable-did-core">
<dt class="spec"><a href="https://www.w3.org/TR/did-core/">Decentralized Identifiers (DIDs) v1.0</a></dt>
<dd>
<p>This specification defines new type of identifier that enables verifiable, decentralized digital identity.
Expand All @@ -240,34 +234,18 @@ <h3>
<b>Exclusion Draft Charter</b>: <a href="https://www.w3.org/2020/12/did-wg-charter.html">https://www.w3.org/2020/12/did-wg-charter.html</a>.
</p>
</dd>
</dl>
<p>
The Working Group may begin work on the following W3C normative specifications:
</p>

<dl>
<dt class="spec">Decentralized Identifier (DID) Method Specification</dt>
<dd>
<p>
DID Method Specifications may be produced by the working group.
</p>
<p class="milestone">
<b>Expected Completion:</b> It is not intended that any DID Method Specification developed by the working group will advance beyond <a href="https://www.w3.org/Consortium/Process/#RecsWD">Working Draft status</a>.
</p>
<p>
<b>Adopted Draft:</b> The <a href="https://www.w3.org/TR/did-spec-registries/#did-methods">DID Specification Registries</a> contains many links to examples of DID Method Specifications, some of which may be selected by the working group for development into a Recommendation. The group might also choose a similar starting document not listed in the Registry.
</p>
</dd>
</dl>
<dl id="deliverable-did-resolution">
<dt class="spec">Decentralized Identifier (DID) Resolution and DID URL Dereferencing v1.0</dt>
<dd>
<dd>
<p>
This document specifies the algorithms and guidelines for resolving DIDs and dereferencing DID URLs.
</p>
<p class="draft-status">
<b>Draft State:</b> Draft Community Group Report
</p>
<p class="milestone"><b>Expected completion:</b>
It is not intended that DID Resolution and DID URL Dereferencing will advance beyond <a href="https://www.w3.org/Consortium/Process/#RecsWD">Working Draft status</a>.
<i class="todo">START+24M</i>.
pchampin marked this conversation as resolved.
Show resolved Hide resolved
</p>
<p><b>Adopted Draft:</b>
DID Resolution v0.3, <a href="https://w3c-ccg.github.io/did-resolution/">https://w3c-ccg.github.io/did-resolution/</a>, published 2023-01-18, may serve as a starting point.
Expand Down Expand Up @@ -337,13 +315,17 @@ <h2>Success Criteria</h2>
more implementations interoperating with each other. In order to advance to
Proposed Recommendation, each normative specification must have an open
test suite of every feature defined in the specification.</p>

<p>In order for <a href="#deliverable-did-resolution">DID Resolution</a> to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, it is expected that each of the independant implementations mentioned above support at least two DID methods with an open specification (i.e. a specification that is accessible to all for implementation and deployment). It is also expected that each pair of the independant implementations mentioned above support at least one common DID method with an open specification.</p>
Copy link
Member

@jyasskin jyasskin Nov 30, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should set a more specific bar than just "open specification". @cwilso and I suggested over email that it be something like

Suggested change
<p>In order for <a href="#deliverable-did-resolution">DID Resolution</a> to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, it is expected that each of the independant implementations mentioned above support at least two DID methods with an open specification (i.e. a specification that is accessible to all for implementation and deployment). It is also expected that each pair of the independant implementations mentioned above support at least one common DID method with an open specification.</p>
<p>In order for <a href="#deliverable-did-resolution">DID Resolution</a> to advance to <a href="https://www.w3.org/Consortium/Process/#RecsPR" title="Proposed Recommendation">Proposed Recommendation</a>, it is expected that each of the independant implementations mentioned above support at least two DID methods with open specifications at at least the Candidate Recommendation Snapshot level, or a level with equivalent vetting and patent grants at another standards body. It is also expected that each pair of the independant implementations mentioned above support at least one common DID method with an open specification.</p>

Copy link
Contributor

@jandrieu jandrieu Nov 30, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would oppose this.

None of the DID methods are at that level of maturity.

However, I agree that some further definition of "open" might be useful.

</ul>

<p>There should be testing plans for each specification, starting from the earliest drafts.</p>

<p>To promote interoperability, all changes made to specifications
in Candidate Recommendation
or to features that have deployed implementations
should have <a href='https://www.w3.org/2019/02/testing-policy.html'>tests</a>.
Testing efforts should be conducted via the <a href="https://github.com/web-platform-tests/wpt">Web Platform Tests</a> project.</p>
</p>

<!-- Horizontal review -->

Expand All @@ -360,9 +342,6 @@ <h2>Success Criteria</h2>
TAG <a href="https://www.w3.org/TR/design-principles/">Web Platform Design Principles</a>.
</p>

<!-- Relevance and momentum -->
<p>All new features should be supported by at least two intents to implement before being incorporated in the specification.</p>
pchampin marked this conversation as resolved.
Show resolved Hide resolved

</section>

<section id="coordination">
Expand Down