In April, I appealed a decision by the W3C Chairs to place DID Methods in scope in the next DID WG Charter.

That appeal was ignored and the charter advanced to AC Review.

This is our Formal Objection to that charter.

We oppose this charter on several grounds.

1. Process
2. Collaboration
3. Technical Fundamentals
4. Interoperability Goals

PROCESS

We stand by our appeal (https://blog.joeandrieu.com/2023/04/12/fighting-for-consensus-at-the-w3c/), which we feel was improperly handled. The Process rules, about consensus, appeals, and Formal Objections, in our opinion, were ignored.

The incident (and the appeal) were filed under Process 2021; the current process is Process 2023. Staff’s response meets the requirements of neither Process. Since Philippe Le Hegaret cited Process 2023 in his response to my appeal, let’s look at what Process 2023 requires.

Process 2023 requires Groups to formally address issues with a response that includes a rationale for decisions that “a W3C reviewer would generally consider to be technically sound”. Neither Philippe Le Hegaret’s nor the Chairs’ responses met that standard. Philippe simply claimed that “this charter is the most acceptable for the majority of the group (an assessment that was confirmed by a recent poll); and that 2) the charter is not a WG deliverable, and consensus must be reached at the AC level anyway, so Joe’s argument should be raised during AC review, not prior to it.”

Unfortunately, the cited poll did not even attempt to gauge consensus. It merely gauged the popularity of advancing the WG, without consideration of the multiple options under consideration by members of the group. Rather than attempting to establish a legitimate vote, Staff created a poll that, like a Politburo election, only offered one candidate to vote on, where, in fact, it should have been inquiring about any objections to best understand the proposal with the weakest objections, instead of blatantly attempting to rubber stamp the offending decision.

More problematic is that the rules for Formal Objections were not followed. There should have been a W3C Council formed to evaluate the objection on its own merits, prior to AC Review.

Staff’s assertion that “consensus must be reached at the AC level anyway” is fundamentally in error. The AC is not involved in resolving formal objections. Councils are.

According to Process 2023, a Council MUST be formed to consider the merits of the objection.

Given that the objection was filed April 12, Staff should have started a council no later than July 11, 2023. PRIOR to sending the Charter to review by the AC. Unfortunately, no council was formed. Instead, on July 26, Philippe finally responded to the appeal by saying Staff is going to ignore it. On August 8, the charter was proposed, unchanged, to the AC for review.

One may raise the concern that the new process was not adopted until June 12, leaving Staff only a month before the deadline. However, Staff did not have to wait until the process was adopted. They could have responded under the previous process any time before June 12 or, realizing that the process was likely to be adopted, they could have begun the prep work to start the council in a timely manner, as required. The idea of councils had been extensively debated and iterated on months before I filed my appeal to the chair decision. And yet, we still have no council.

Further as part of its obligations under Process 2023 when there are Formal Objections, Staff is tasked with investigation and mediation. Since Staff’s efforts in that regard did not lead to consensus–by Staff’s own acknowledgement–its only option is to form a council and prepare a report:
“Upon concluding that consensus cannot be found, and no later than 90 days after the Formal Objection being registered, the Team must initiate formation of a W3C Council, which should be convened within 45 days of being initiated. Concurrently, it must prepare a report for the Council documenting its findings and attempts to find consensus.”

As a result, the AC is reviewing not the legitimate continuation of the DID Working Group, but rather a hijacking of the work that I and others have given years of time and effort to advance.

---

COLLABORATION

Taking the charitable position that everyone involved continues to act in good faith and the process as defined was properly followed (even if its documentation might be inadequate), then we still oppose this charter on the grounds that the development of the charter violated the fundamental purpose of the W3C: collaboration through consensus.

The question we ask is this: should WG chairs be able to propose a continuation of that WG without consensus from the WG itself? Should anyone?

This is the situation we’re in and I did not expect that collaboration at the W3C would look like this.

I first got involved with W3C work by volunteering feedback to the Verifiable Credentials Task Force on their draft use case document. From those early days, I was asked to join as an invited expert and have since led the use case and requirements efforts for both Verifiable Credentials and Decentralized Identifiers, where I remain an editor. I also developed and continue to edit the DID Method Rubric a W3C NOTE. Somewhere in that tenure I also served as co-chair of the W3C Credentials Community Group.

During this time, I have been impressed by the organizations’ advocacy for consensus as something unique to its operations. The idea of consensus as a foundational goal spoke not only to my heart as a human being seeking productive collaborations with others, but also to my aspirations as a professional working on decentralized identity.

And then, citing a non-binding recommendation by the then-acting director in response to previous Formal Objections, the chairs of the DID WG turned that narrative of consensus upside down.

---

Here’s what happened:

June 30, 2022 – DID Core decision by Director “In its next chartered period the Working Group should address and deliver proposed standard DID method(s) and demonstrate interoperable implementations. The community and Member review of such proposed methods is the natural place to evaluate the questions raised by the objectors and other Member reviewers regarding decentralization, fitness for purpose, and sustainable resource utilization.” Ralph Swick, for Tim Berners-Lee
https://www.w3.org/2022/06/DIDRecommendationDecision.html

July 19, 2022 – DID WG Charter extended, in part “to discuss during TPAC the rechartering of the group in maintenance mode.” Xueyuan xueyuan@w3.org https://lists.w3.org/Archives/Public/public-did-wg/2022Jul/0023.html

August 18, 2022 – Brent Zundel proposed to add DID Methods in PR#20 https://github.com/w3c/did-wg-charter/pull/20

September 1, 2022 – Group email from Brent Zundel about TPAC “We plan to discuss the next WG charter and will hopefully end up with a draft ready to pass on to the next stage in the process.” Brent Zundel https://lists.w3.org/Archives/Public/public-did-wg/2022Sep/0001.html

The Charter at the time of announcement https://github.com/w3c/did-wg-charter/blob/af23f20256f4107cdaa4f2e601a7dbd38f4a20b8/index.html

September 12, 2022 – Group meeting at TPAC “There seems to be strong consensus that we’d rather focus on resolution” https://www.w3.org/2019/did-wg/Meetings/Minutes/2022-09-12-did

September 20, 2022 – Summary of TPAC. Manu Sporny msporny@digitalbazaar.com “The DID Working Group meeting had significant attendance (40-50 people). The goal was to settle on the next Working Group Charter. […] There were objections to standardizing DID Methods. […] There didn’t seem to be objections to DID Resolution or maintaining DID Core.”
https://lists.w3.org/Archives/Public/public-credentials/2022Sep/0177.html

September 21, 2022 – PR#20 from Brent Zundel merges, without discussion or any notice to the WG, PR#20 DID Method resolution into spec, saying “I am merging this PR over their objections because having the flexibility to go this route could be vital should our efforts to move DID Resolution forward be frustrated.”

October 18, 2002 – DID Resolution PR #25 created to add DID Resolution

October 24, 2002 – DID Resolution PR #25 merged, adds DID Resolution

October 25, 2022 – Reviewing other work, I discovered the unannounced merge of #20 and commented asking to revert. https://github.com/w3c/did-wg-charter/pull/20#issuecomment-1291199826

December 14, 2022 – Brent Zundel created PR #27 to add DID Methods and DID Resolution to the deliverables section.

December 15, 2022 – DID WG Charter extended to “allow the group to prepare its new charter” Xueyuan xueyuan@w3.org https://lists.w3.org/Archives/Public/public-did-wg/2022Dec/0000.html

The Charter at the time of the December 15 extension https://github.com/w3c/did-wg-charter/blob/b0f79f90ef7b8e089335caa301c01f3fc3f8f1ef/index.html

December 15, 2022 – Brent Zundel asserts consensus is not required. “There are no WG consensus requirements in establishing the text of the charter.” And “The time and place to have the conversation about whether the charter meets the needs of the W3C is during AC review.” https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1353537492

January 19, 2023 — Christopher Allen raised issue #28 suggesting DID Resolution WG instead of DID WG. https://github.com/w3c/did-wg-charter/issues/28

January 23, 2023 – Brent Zundel initially welcomes seeing a DID Resolution WG charter. https://github.com/w3c/did-wg-charter/issues/28#issuecomment-1401211528

January 23, 2023 – Brent Zundel continues to argue that consensus does not apply: “This charter is not a DID WG deliverable. It is not on the standards track, nor is it a WG Note, nor is it a registry. Thus, the strong demands of WG consensus on its contents do not apply. Consensus comes into play somewhat as it is drafted, but primarily when it is presented to the AC for its consideration.” https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1401199754

January 24, 2032 — Brent Zundel creates PR #29 offering an alternative to PR #27, excluding the offending language. https://github.com/w3c/did-wg-charter/pull/29

March 13, 2023 — Christopher Allen raises Pull Request #30 proposing a DID Resolution WG charter. https://github.com/w3c/did-wg-charter/pull/30#issue-1622126514

March 14, 2023 — Brent Zundel admits he never actually considered PR #30 “It was never my understanding that a DID Resolution WG would replace the DID WG. I do not support that course of action. If folks are interested in pursuing a DID Resolution WG Charter separate from the DID WG Charter, the place to do it is not here.” https://github.com/w3c/did-wg-charter/pull/30#pullrequestreview-1339576495

March 15, 2023 – Brent Zundel merged in PR #27 over significant dissent “The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year.” “The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary.” https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

March 21, 2023 – Announcement of intention to Appeal Joe Andrieu joe@legreq.com https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1478595775

March 23, 2023 – Clarification from Philippe Le Hegaret
‘The “should” is NOT a “must”, otherwise it would say so explicitly in the Director’s decision. In other words, the Working Group is allowed to disagree with the direction set by the Director.’ Personal email from Philippe

March 30, 2023 – DID WG Charter extended. “The goal of this extension is to allow the group to propose its new charter [2], which the chairs consider reasonably stable now. ” xueyuan xueyuan@w3.org https://lists.w3.org/Archives/Public/public-did-wg/2023Mar/0000.html

April 12, 2023 — Appeal of Chair Decision filed https://blog.joeandrieu.com/2023/04/12/fighting-for-consensus-at-the-w3c/

June 12, 2023 — A new process document is adopted. Removes Director. Rather than the “Director, the W3C Council, which is composed of TAG+AB+CEO, will now hear and resolve formal objections.” “Merge Chair Decision Appeal, Group Decision Appeal, and Formal Objection; clarify what can be objected to.” https://www.w3.org/2023/Process-20230612

May 9-10, 2023 – Advisory Committee meeting in Sophia Antipolis. Joe Andrieu attended. Neither co-chair attended.

May 11, 2023 — Joe Andrieu reports success on conversations with prior formal objectors ‘There was exceptional support for focusing on resolution rather than DID methods as the route to interoperability. “That would go a long way to addressing our concerns” and “Yep, that seems like the better way to do it” and “That seems reasonable, but I need to think on it a bit more [before I say it resolves the issues of our FO].” I think it’s fair to say that a focus on resolution (without any DID methods) would likely avoid a FO from 2 out of 3 and, quite possibly all 3. https://github.com/w3c/did-wg-charter/issues/28#issuecomment-1543579206

May 11, 2023 — Brent Zundel claims confidence that we can “move through the charter development process and end up with something that no one objects to.“ https://github.com/w3c/did-wg-charter/issues/28#issuecomment-1544358479

May 22, 2023 – Pierre-Antoine Champin published survey to did-wg charter.
“Would you agree to sending the current version of the charter proposal to the Advisory Committee for review?”
This questionnaire was open from 2023-05-22 to 2023-06-20.
40 yes (85%)
6 no (15%)
https://www.w3.org/2002/09/wbs/117488/rechartering_survey/

July 26, 2023 — Philippe Le Hegaret dismisses appeal. “W3C team concurs there is no consensus” https://lists.w3.org/Archives/Public/public-did-wg/2023Jul/0000.html

August 8, 2023 – Proposed DID WG Charter Call for Review “There is not consensus among the current working group participants as to whether the charter should permit work on the specification of DID methods. This charter proposal includes the option for the group to do that work if there is sufficient interest. This follows the director’s advice in the DID Core 1.0 Recommendation decision [3] to include the specification of DID methods in the future scope of the work.” https://www.w3.org/2002/09/wbs/33280/did-wg-2023/

August 8, 2023 – Brent Zundel asserts in W3C Credentials Community Group meeting that “In my experience, Formal Objections are noted and are usually overridden…” https://w3c-ccg.github.io/meetings/2023-08-08/

No DID WG Meetings whatsoever after January of 2022.

These, I believe, are the relevant facts of the situation, covering the thread of this debate from its beginning through to today.

---

Why does it matter?

Because consensus is how the W3C delivers legitimate technical specifications.

Because the record clearly shows that the chairs never intended nor attempted to seek consensus and resolve objections to their initial proposal. In their defense, they argue consensus doesn’t apply, which if correct, would justify their behavior. However, we can’t see anything–neither in the member agreement nor in the process document–that constrain’s the requirement that chairs seek consensus to any particular activity.

We believe three points should prevail in this discussion:

First, we see the deference to the past director’s comments as completely outside the Process.

Second, regardless of intent or process, we believe that charter development for an existing working group MUST achieve consensus within that WG before advancing to AC Review.

Third, we see the chairs’ argument regarding the inapplicabilty of consensus to violate the fundamental point of the organization: consensuse-based collaboration.

Let’s look at each of these in terms of what it would take to deny these points.

---

For the first point, we could interpret the will of “The Director” in his response to the prior Formal Objections as a mandatory requirement.

As we asked formally in our appeal, it may well be that this outcome was always the intention of Staff. “Since the chairs are claiming a mandate from the Director as the justification for their decision, I am directly asking the Director if what is happening is, in fact, what the Director required.”

Staff answered this question by endorsing the Chairs’ decision, relying on the “Director’s comments” as justification. Staff and the chairs believe that it is appropriate for a past decision by the past Director to bind the future work of a Working Group.

I find this unreasonable and contrary to Process. Nowhere in any Process document does Staff or the Director get the right to mandate the work of working groups. Nor does the Process give Staff, Director or otherwise, the right to bind future work of WGs.

Even Phillippe Le Hegaret acknowledged that the Director’s comments did not require the group adopt that recommendation: “It’s a SHOULD not a MUST.” And yet, he claims that his decision to advance the current Charter “follows the director’s advice in the DID Core 1.0 Recommendation decision”.

Working Groups should be the sole determinant of the work that they perform. It is not Staff’s role to direct the technical work of the organization. It’s Staff’s role to support the technical work of the organization, by ensuring the smooth operation of Process.

We do not buy the argument that Ralph Swick, acting on behalf of the past Director in a decision made about a previous work item, appropriately justifies the willful denial of consensus represented by this charter.

The fact of the matter is that DID interoperability is a subtle challenge, not well understood by everyone evaluating the specifications. If we could have had a conversation with the Director–which I asked for multiple times–perhaps we could have cleared up the confusion and advanced a proposal that better resolves the objections of everyone who expressed concerns. But not only did that conversation not happen, it CANNOT happen because of the change in Process. We no longer have a Director. To bind the future work of the DID WG to misunderstandings of Ralph Swick, acting as the Director, is to force technical development to adhere to an untenable, unchallengeable mandate.

What we should have had is a healthy conversation with all of the stakeholders involved, including the six members of the WG who opposed the current charter as well as anyone other participants who cared to chime in. The chairs explicitly prevented this from happening by cancelling all working group meetings, failing to bring the matter to the groups attention through the mailing list, or otherwise attempting to arrange a discussion that could find a proposal with weaker objections as required by process.

Failing that, we should have had a W3C Council to review my appeal as per Section 5.5 and 5.6 of the current Process. That council may well have been able to find a proposal that addressed everyone’s concerns. That also did not happen. Rather than respond to my objection in a timely manner, staff advanced the non-consensual charter to AC review.

Finally, even if we accept that Ralph Swick, acting as the Director, in fact, officially represented the consensus of the W3C in the matter of the DID Core 1.0 specification (for the record, we do), the recommendation that resulted represents the formal W3C consensus at the time of the DID Core 1.0 specification, solely on the matter of its adoption as a Recommendation. It cannot represent the consensus of the W3C on the forced inclusion of unnamed DID Methods in the next DID WG Charter, because the organization has not engaged in seeking consensus on this matter yet. Not only did the chairs ignore their responsibility to seek consensus, Staff has as well.

I would like to think that every WG at the W3C would like to be able to set their own course based on the consensus of their own participants, rather than have it mandated by leadership.

---

---

For the second point, you could endorse that charter development is not subject to consensus, as argued by the Chairs.

The chairs claim that “This charter is not a DID WG deliverable. […] Thus, the strong demands of WG consensus on its contents do not apply.”

I find this untenable on two different grounds.

First, the Process does not restrict the commitment to consensus to just Working Group deliverables. The language is broad and unambiguous: “To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).”

The Process in fact, includes examples of seeking consensus that have nothing to do with formal deliverables.

Second, this interpretation would mean that, according to process, ANYONE could propose a new Working Group charter, with the same name and infrastructure as a current Working Group, WITHOUT seeking the consensus of the Working Group involved. All one needs is for Staff to support that effort. On their own initiative, Staff can simply hijack the work of a working group by recruiting chairs willing to propose a new charter without the input of the current group.

This is untenable. If a Working Group is still in existence, it should be a fundamental requirement that any charter proposals that continue that work achieve the consensus of the working group. Of course, if the WG is no longer operating, that’s a different situation. But in this case, the WG is still active. We even discussed the Charter in our meeting at TPAC where upon its first presentation no fewer than five participants objected to including DID Methods in scope.

Frankly, if a Charter proposal does not represent consensus of the group selected by staff to develop the charter… it should not advance to AC Review. Full stop.

That’s the whole point of charter development: for a small group of motivated individuals to figure out what they want to do together and propose that to the organization. If that small group can’t reach consensus, then they haven’t figured it out enough to advance it to AC Review. They should go back to the drawing board and revise the proposal until it achieves consensus. THEN, and only then, should it be proposed to Staff for consideration. When Staff receives a charter proposal that lacks consensus, it should reject it as a matter of course, having not met the fundamental requirements.

---

---

For the third point, you could accept the position that the chairs met their duty to seek consensus simply by asserting that there is no consensus.

This argument was raised by other W3C members (not the chairs or staff): the W3C has historically given broad remit to chairs to determine consensus, so whatever they do for “consensus” is, by definition, canon. This disposition is noted in the process itself “Chairs have substantial flexibility in how they obtain and assess consensus among their groups.” and “If questions or disagreements arise, the final determination of consensus remains with the chair.”

As the current discussion has shown, that latter statement is, as a matter of fact, incorrect. The chairs asserted a determination of consensus in this matter “PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year” which Staff judged inadequate: “There is not consensus among the current working group participants as to whether the charter should permit work on the specification of DID methods.” So, either the policy is in error because, in fact, the Staff is the ultimate determiner of consensus, or, Staff ignored process to impose their own determination.

However, even if Chairs have wide remit to determine consensus, the process unequivocally requires chairs to do two things:

• ensure that groups consider all legitimate views and objections
• endeavor to resolve [those objections]

In short, the chairs must actively engage with objectors to resolve their concerns.

The chairs did not do this.

First, they did not do any of the following suggestions in the process document about how to seek consensus:

• Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people. (5.2.2. Managing Dissent https://www.w3.org/2023/Process-20230612/#managing-dissent)
• A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock. (5.2.3 Deciding by Vote) https://www.w3.org/2023/Process-20230612/#Votes
• A group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound. (5.3 Formally Addressing an Issue https://www.w3.org/2023/Process-20230612/#formal-address )
• The group should reply to a reviewer’s initial comments in a timely manner. (5.3 Formally Addressing an Issue https://www.w3.org/2023/Process-20230612/#formal-address )

The record shows that chairs, rather than doing any of the above recommended actions for consensus, consistently avoided seeking consensus by dismissing concerns and merging PRs without actually seeking to address objectors’ concerns.

PR #20 still has no comments from either Chair. It was merged in over objections despite the working groups exceptionally consistent practice that unless there is consensus for a given change, PRs don’t get merged in.

In fact, controversial edits in this working group regularly receive a 7-day hold with, at minimum, a Github label of a pending action (to close or merge), and often an explicit mention in minutes of the meeting in which the change was discussed. PR #20 was merged by executive fiat, without adherence to the norms of the group and the requirements of process. If you feel charters don’t need consensus, maybe you’re ok with that. We’re not.

It’s clear that in the case of PR #20, Brent Zundel made an executive decision that was contrary to the groups established norms of requiring consensus before merging. Given that Brent never wavered in his commitment to the specific point of including DID Methods in scope as the “only option”, it’s clear that, at least on that point, he never intended to seek consensus.

In PR #27 Brent Zundel and Pierra-Antoine Champin (team contact) dismissed the concerns of objectors rather than “endeavoring to address” them.

Brent asserts that “flexibility in the charter does not require a group to perform any work” And “a future charter that doesn’t include possible DID Methods will be rejected” and “the strong demands of WG consensus on its contents do not apply.”

Pierre-Antoine asserts that “Considering the two points above, the chairs’ decision is in fact quite balanced.” and “But I consider (and I believe that others in the group do as well) that plainly ignoring this recommendation from the director amounts to painting a target on our back.”

Not once did Brent, Dan, or Pierre-Antoine acknowledge the merit of the concerns and attempt to find other means to address them.

PR #29 Remove mention of DID Methods from the charter was ostensibly created to seek input from the WG on the simplest alternative to #27. Unfortunately, not only did the chairs fail to make any comments on that PR, there remain four (4) outstanding change requests from TallTed, kdenhartog, Sakurann, and myself. This PR was never more than a distraction to appear magnanimous without any actual intention to discover a better proposal. If the chairs had been actually exploring PR #29 as a legitimate alternative to PR #27, they would have engaged in the conversation at a minimum, and at best, actually incorporated the suggested changes so the group could reasonably compare and discuss the merits of each approach.

PR #30 Charter for the DID Resolution WG was created in response to a request from TallTed, and initially supported by Brent Zundel, only to see him reverse course when he understood it was an alternative proposal to the DID WG Charter: “I do not support that course of action. … the place to [propose an alternative] is not here.”

Not once, at any time, did Brent, Pierre-Antoine, or Dan Burnett acknowledge the merit of our concerns. They did not ask objectors how else their concerns might be addressed. Not once did they attempt to address my (and others’) concerns about DID method over-centralization caused by putting DID Methods in scope.

Instead, they simply refused to engage objectors regarding their legitimate matters of concern. There were no new proposals from the chairs. There were no inquiries about the “real motivation” behind our objections in an effort to understand the technical arguments. There weren’t even rebuttals from leadership to the technical arguments made in opposition to DID Methods being in scope. It was clear from ALL of their correspondence that they simply expected that the rest of the WG would defer to their judgment because of the prior Director’s comments.

It is our opinion that in all their actions as chairs, WG Chairs MUST seek consensus, whether it is a WG deliverable, a charter, or any W3C matter. That’s the point of the W3C. If chairs can ignore process, what good is process? If staff can ignore the process, how are we to trust the integrity of the organization?

Finally, on the matter of the chairs and process, I find Brent Zundel’s assertion in the August presentation to the Credentials Community Group particularly problematic: “In my experience, Formal Objections are noted and are usually overridden”.

In other words, Brent believes that the Process, which describes in great detail what is to happen in response to a Formal Objection, doesn’t usually apply.

The fact is, he may end up being right. Given the improper dismissal of my appeal, the Process, in fact, does not appear to matter when it comes to the DID WG charter.

---

TECHNICAL FUNDAMENTALS

The primary technical objection to putting DID Methods in scope is simple conflict of interest. By empowering the DID WG to develop specific DID Methods, it would result in the group picking winners and losers among the 180+ DID Methods currently known. Not only would that give those methods an unfair advantage in the marketplace, it would affect WG deliberations in two important ways. First, the working group would, by necessity, need to learn those selected methods, placing a massive burden on participants, and elevating the techniques of that particular method to accepted canon–which will inevitably taint the DID Core specification with details based on those techniques. Second, this will require the group to evaluate, debate, and select one or a few of those 180+ methods, which will suck up the available time and energy of the working group, forcing them to work on “other people’s methods” rather than advancing the collective work that all DID Methods depend on. Those who want to pursue DID Methods at theW3C should propose their own charter based on a specific DID method.

Our second technical objection is more prosaic: there are no DID Methods ready for W3C standardization, as evidenced by the blank check in the current charter request. It may be within the bounds of the W3C process to authorize such an open ended deliverable, but we believe it is a fundamental problem that the chairs cannot even recommend a specific method for inclusion in the charter. Frankly, this weird hack of not specifying the method and restricting that work to First Public Working Draft (FPWD) status lacks integrity. If it is important for the group to develop a method, name it and make it fully standards track, without restriction. This middle-way is a false compromise that will satisfy no one.

INTEROPERABILITY GOALS

A significant failing of the initial DID Core specification was a failure to develop interoperability between DID Methods. This lack of interoperability was cited as a reason for multiple Formal Objections to that specification. We concur, it’s problem.

However, the problem was not a result of too many DID Methods, nor would it be resolved by forcing the standardization of one or more exemplars. It was a problem of scope. DID core was not allowed to pursue protocols and resolution was intentionally restricted to a mere “contract” rather than a full specification.

The result of those restrictions meant the WG could NOT achieve the kind of interoperability we are all seeking.

We believe the answer is simple: standardize DID Resolution. Not restricted to FPWD status, but actually create a normative global standard for DID Resolution as a W3C Recommendation.

By defining a common API that all DID Methods can implement to provide an interface for a back-end verifiable data registry, we allow any system that can support those implementations an equal opportunity to interoperate with any other, just like HTTP allows any browser to reach any website, regardless of the back-end technology that does the heavy lifting.

That’s how we get to interoperability.

Distracting the group with DID Method specifications would just limit the time and resources the DID WG can bring to bear on solving the real issue of interoperability between methods.

More technical and interoperability details are discussed in our appeal.

RESPONDING TO CRITISMS

Finally, for those still reading, I’d like to address some criticisms that have been raised about my approach to this problem.

First, the assertion that this debate is going to end up in AC Review, so we should have it there and not in the WG.

The debate was not predestined to go to AC review. Like all objections under Process 2023, it should have been resolved in a council. Staff inappropriately accelerated the charter to AC Review despite an ongoing objection and requests by the objector to delay advancement until the matter could be resolved.

Second, the AC is not the appropriate place for a working group to work out its internal disagreements. The AC is the place where other member organizations have a chance to review and comment on proposed work done by the organization as a whole. This is a fundamental principle that, in other contexts, is known as federalism. It isn’t the job of the AC to tell every WG what to do. It’s the job of the AC to vet and confirm the work actually done by the WG. For staff and chairs to deny due process to my objection is, in fact, denying the ability for the AC to review the best proposal from the Working Group and instead requiring the AC to have a meaningless debate that will absolutely result in a council.

To reflect Philippe’s argument back, since the underlying objection is going to be decided in a council anyway, why didn’t we start there? Especially since that is what process requires.

Third, Philippe quoted the following Process section in his discussion of my appeal, despite ignoring the first part of the sentence.

“When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group SHOULD move on.” [emphasis mine]

The group did NOT duly consider the legitimate concerns of objectors. Instead, the chairs intentionally avoiding any substantive discussion on the topic. There is no evidence at all that the chairs ever considered the legitimate concerns of objectors. They dismissed them, ignored them, and argued that the WG’s github is not the place to have this debate, the AC is.

So, because Staff and the chairs believed it was ultimately going to AC Review, they collectively decided to ignore their obligations: of Chairs to seek consensus within the WG and of Staff to seek consensus through a W3C Council after my appeal.

Finally, I’ll note that my disagreement has been described by one of the chairs as “Vociferous”, “Haranging”, and “Attacking”. I find this characterization to be inappropriate and itself a CEPC failure. “When conflicts arise, we are expected to resolve them maintaining that courtesy, respect, and dignity, even when emotions are heightened.”

The civil exercise of one’s right to challenge authority is fundamental to a free society and vital to any collaborative institution. To be attacked because I chose to engage in conversations that the chairs were trying to avoid, is inappropriate. To be attacked because I filed an appeal, as clearly allowed in the Process, is inappropriate. To attack those who disagree with you is neither collaborative, nor is it an effective mechanism to seek consensus.

SUMMARY

This charter never should have made it to the AC. It unfairly hijacks the DID WG name and its work, without the consent of the current DID WG. Worse, it does so in a way that fundamentally undermines the decentralized nature of Decentralized Identifiers.

This charter should be rejected and returned to the DID WG to find a proposal with weaker objections, one that represents the collective will of the working group and legitimately continues the work in which we all have invested our professional careers.

Fighting for Consensus at the World Wide Web Consortium (W3C)

From “W3C Process Document” https://www.w3.org/2021/Process-20211102/

It’s unfortunate that I find myself formally appealing a decision by the W3C Decentralized Identifier Working Group (DID WG) chairs. Simply put, the decision was not made according to the applicable W3C Process, which requires seeking consensus through selecting proposals with the weakest technical objections.

The decision to appeal was not made lightly. It will force into the public view a disagreement between parties who generally have high mutual regard and respect. I personally think the DID WG chairs are well-intentioned and doing their best to resolve the challenges of the underlying work. However, in this particular case, we have a failure to secure consensus and an unfortunate autocratic imposition of the chairs’ position on a group in significant dissent.

I got involved in this particular stream of work after attending the first ID2020 and Rebooting the Web of Trust II after over ten years in the user-centric identity movement as championed by the Internet Identity Workshop and ProjectVRM. I became (and remain) an editor for Verifiable Credentials Use Cases and Use Cases and Requirements for Decentralized Identifiers and the DID Method Rubric, all W3C publications. I am treasurer and board member of Rebooting the Web of Trust, a collaborative writing workshop that incubated early Decentralized Identity technologies like DIDs and VCs. My business is a small consulting company that helps clients better understand the human requirements for decentralized identity systems and applications. I also created the DID Directory DID Directory and host a podcast about DID methods, The Rubric. In short, I have over 15 years invested in bringing this technology to realization, as a consistent contributor to the shared work of the broader community and as a leader in both W3C and external efforts.

After years of serving as invited expert to the VCWG and DIDWG, we joined the W3C this year to specifically to oppose the Chairs’ decision in this matter.

Technical Background

While this appeal does not rely on a technical argument for overturning the chairs decision, our primary technical reasoning is straightforward.

Enabling the DID WG to develop specific DID methods will actively undermine the work’s fundamental goal of decentralization.

A New Architecture Building on the Old Architecture

We have an opportunity in decentralized identifiers to reinvent outdated architectures that rely on, and extend, the innate authority of centralized actors. The World Wide Web is an amazing achievement in operational decentralization. Unfortunately its naming system is fundamentally based on centralized authority, and therefore subject to manipulation and abuse in ways that decentralized systems are designed to avoid. DIDs represent an opportunity for identifiers to be first class citizens for the World Wide Web, without needing to defer to any centralized authority. Not IANA. Not DNS. DIDs provide a way for anyone to stand up an identification system and for anyone to use that system. It is, in its way, a profound restructuring of what identity means in digital systems. Combined with Verifiable Credentials, this emerging identity system provides a decentralized way for individuals to engage digitally with promise of greater privacy, improved user control, and increased respect for our humanity.

A fundamental innovation of DIDs relative to public key cryptography is the level of indirection between the identifier and the cryptography, with different DID methods providing different means for managing this level of indirection.

DIDs resolve to DID Documents, where resolution is defined by the DID method specified in the DID itself. The data required to determine the current authoritative DID document for a given DID is stored in the Verifiable Data Registry of that method.

Consider the DID did:example:abc. This is a well-formed DID using the “example” method. The mechanism to turn that DID into a DID document based on that DID method’s Verifiable Data Registry is called resolution.

First, client software sends the DID to a resolver expected to handle that particular method (“example”). The resolver then uses operations defined by the “example” method to retrieve salient data from the Verifiable Data Registry. Finally, the resolver produces a well-formed DID document and returns that to the client. The client can then interpret the DID document to use the current cryptographic and service endpoint information for that DID.

Because of this level of indirection between the DID and the DID document, DID controllers can update the DID’s cryptographic material without changing the identifier itself (and without relying on a trusted third party). This means that normal, operational security actions like key rotation and revocation can be implemented without requiring direct communication with relying parties. The VDR acts as the intermediary. In fact, the DID controller does not even need to know who is relying on the DID; there is no requirement for direct communication about updates to the DID document. In contrast, updating private key information with traditional public/private key cryptography requires communicating the new public key to all dependent parties.

By design, DIDs enable any form of Verifiable Data Registry. As long as a method can specify how you perform the Create, Read, Update, and Deactivate operations for a DID using that VDR, it’s a valid method. This has allowed DID methods based on bitcoin (did:btcr and did:ion), ethereum (did:ethr and did:elem), bespoke blockchains (did:v1 and did:cosmos), Amazon’s QLDB, and even public keys actually stored in the DID itself (did:key and did:jwk). This fundamental goal of allowing any type of VDR means that interoperability stops at the resolver, which itself provides the integration between resolver clients and a method’s VDR, allowing any method to define its own mechanism for transforming a DID into its DID document, using any kind of VDR.

Parallels to HTML and HTTP

The architecture of DID methods is a lot like the architecture of the web itself, where browsers dereference URLs to access webservers that interact with a backend to provide a resource back to the browser. By design, the browser doesn’t need to know how the web server and back end communicate, nor how the data is stored in the backend. All the browser needs to know is the interface HTTP and HTML.

The equivalent is true for DIDs. With a standard for DID resolution, any DID client would have a standard mechanism (resolution) that can be provided by any conformant DID method, allowing the retrieval and use of DID documents without intimate knowledge of how the VDR works.

That’s the route to interoperability for DIDs, just as it was and is for the web.

Progress to date

We built the first two components of the DID system in the DID Core 1.0 specification, namely, a URL syntax for DIDs and a data model for DID documents, which provide the cryptographic material for verifiable interactions related to that DID. In effect, this is like defining URLs (RFC3986) and HTML (originally RFC1866). At the time of the groups initial chartering, we intentionally left DID resolution out of scope, instead merely defining a contract for what DID resolution should provide (without specifying how it is to be provided). Resolution is how one takes a given DID and retrieves the associated DID document. Resolution is the http of DIDs. It takes a well-formed URL (the DID) and specifies how you process bits sent & received over the wire to get the resource indicated (the DID document in this case).

This is the next step in the work: defining an interoperable mechanism for resolving DIDs for different DID methods. Under the hood, resolution is necessarily method-specific because each method is free to use any verifiable data registry (VDR), and, inevitably, different registries have different mechanisms for creating, reading, updating, and deactivating DIDs. While it will be impossible to have a common specification for all potential VDRs (unless you force all methods to use the same VDR mechanism), it is possible to define an interface that all methods could provide, in order to allow client software to resolve a DID and ignore the method-specific details. This is how we get interoperability between DID methods.

This is a stark contrast to the idea that the next step in the work is standardizing specific DID methods. Some have argued that developing a specific DID method would somehow improve interoperability. However, we believe the only interoperability benefit we get from standardizing a specified DID method is either (1) for different implementations of that single method or (2) imposing the mechanisms of that DID method on other methods. Focusing on a single method does not, and cannot, improve interoperability between Methods, especially those based on fundamentally different VDRs.  As a decentralized technology, imposing the mechanisms of any given method on other methods is antithetical to the point of the work. In a truly decentralized system, anyone can define a new DID method and it should “just work”. That means interoperability between DID methods is the fundamental priority. We achieve that by specifically focusing on a shared, standardized mechanism for DID resolution rather than focusing on specific methods.

Summary of Technical Objection

Having the DID WG standardize specific DID methods creates moral hazards that will inevitably reduce the decentralization of DIDs themselves. Whichever methods the group chooses will attain unprecedented acceleration and impact. It will take an increased attention from the WG focused on those methods, taking away from attention that could go to advance all DID methods. That attention will also increase the WGs familiarity with how chosen methods solve certain problems and those approaches will necessarily already have the blessing of the WG, making them preferred favorites over approaches used by other methods. In short, giving the DID WG the permission to focus its attention on selected favorites would directly undermine its ability to advance the work with equal respect for all methods.

Procedural Objection

We also object on procedural grounds to the inclusion of standards-track documents for unstated new specifications in a so-called “maintenance charter”. A working group chartered for maintenance should not be creating new standards-track documents for arbitrary, unspecified DID methods. Maintenance groups should be focused on maintenance, not creating new specifications, especially unnamed specifications. Like the technical argument for decentralization, we do not rely on this procedural flaw in this appeal.

Formal Request to Deny Chair Decision

I am formally appealing to the Director of the W3C to deny the decision by the DID WG Charter chairs to override dissent about the inclusion of DID methods in the scope of the next DID WG Charter, as embodied in part in the decision to merge PR#20 and PR#27 into the DID WG Charter.

The decision is best summarized in the comment merging in PR#27

The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year.

Despite many, many discussions, no other proposal within the group has garnered as much support as this one has for the creation of a new DID Working Group, which will focus on maintaining Decentralized Identifiers (DIDs) v1.0 and publishing errata updates to that specification. The charter also permits the next DID WG to begin work on DID Methods and DID Resolution, but does not require it, e.g., the group that forms may do as much or as little work on these optional topics as desired.

Now, regarding the other open PRs, #29 and #30:

The predominant concern raised has been with the inclusion of DID Methods as optional work in this charter. The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary. So we have concluded that PR Remove mention of DID Methods from the charter #29 is no longer relevant to this discussion. We are leaving it open for comments, but they will not change the decision at this point.

There have been suggestions for an alternative group focused exclusively on DID Resolution. We support the effort to create a DID Resolution Working Group that focuses entirely on DID Resolution, as that will strongly support the work of the DID Working Group, which must focus on the DID Specification. We encourage the proponents to develop their proposal and present it to W3M and the AC Forum as a new Working Group. However, because it would not be a DID Working Group, we have concluded that PR Proposal: Charter for the DID Resolution WG (as a replacement to current proposal) to continue the work of DID 1.0 #30 is no longer relevant to this conversation. We are leaving it open for those who wish to continue designing a separate DID Resolution-focused WG, but we do not expect such work to change the decision at this point.

2023/03/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

I am appealing on five points, all of which highlight the chairs’ failure to with respect to W3C Process.

I discuss each of these below.

The PR lacks consensus

Both staff and chairs have acknowledged that adding DID methods to the spec lacks consensus.

@brentzundel: I am merging this PR over their objections because having the flexibility to go this route could be vital should our efforts to move DID Resolution forward be frustrated.

2022/09/21 https://github.com/w3c/did-wg-charter/pull/20#issuecomment-1253912348

@pchampin: We clearly didn’t manage to reach consensus here

2023/01/11 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1379253408

@brentzundel: There is no consensus at this stage, nor do I believe it is possible to achieve it.

2023/01/23 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1401199754

The lack of consensus does not appear to be in question.

Consensus was not legitimately sought

The W3C 2021 Process document places consensus at the core of the W3C:

Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public).

In the section on managing dissent:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

And, in the section on deciding by vote:

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.

Unfortunately, the chairs did not fulfill these obligations to use all available means of reaching consensus through technical discussion.

They avoided the issue. They denied the issue. Ultimately, they did not lead a technical discussion in an effort to find proposals that create the weakest objections.

• Avoidance
• Denial
• Deference to political priorities over technical discussion

Avoidance

Despite consistent efforts by myself and others who share my concerns, the chairs actions have had the effect of avoiding dissent rather than working with the group to find the proposal with the weakest objections. They ignored Github issues, held no conference calls, created a false impression of engagement, and failed to respond to direct outreach.

Ignoring Github issues

After the initial discussion at TPAC, @brentzundel merged PR#20 on Sep 21, 2022, which put DID methods in scope, with the note that this was against objections voiced at TPAC. I commented in opposition to that merge on October 25, 2022, requesting the PR be reverted. To this date, neither chairs nor staff have even bothered to respond.

No group phone calls nor email discussion after TPAC

After the initial objections were acknowledged at TPAC there were neither group conference calls nor any outreach to the mailing list on this matter. Instead of facilitating a conversation to reach a consensus, the chairs acted as if there were no significant issues for the group to discuss.

False engagement and misdirection

After lengthy discussion on the PR#27 in question (largely by others) @brentzundel created another PR #29 with the stated goal of finding the proposal with the “best consensus” introduced in his comment on #27 on

He did in fact create PR #29, which also led, at the request of @TallTed and @brentzundel to PR#30 to shift the entire focus of the charter to DID Resolution. However, neither of these alternatives were actually given serious consideration by the chairs:

@brentzundel: It was never my understanding that a DID Resolution WG would replace the DID WG. I do not support that course of action. If folks are interested in pursuing a DID Resolution WG Charter separate from the DID WG Charter, the place to do it is not here.

2023/03/22: https://github.com/w3c/did-wg-charter/pull/30#pullrequestreview-1339576495

And again, in the comment announcing the chairs decision

@brentzundel: However, because it would not be a DID Working Group, we have concluded that PR Proposal: Charter for the DID Resolution WG (as a replacement to current proposal) to continue the work of DID 1.0 #30 is no longer relevant to this conversation. We are leaving it open for those who wish to continue designing a separate DID Resolution-focused WG, but we do not expect such work to change the decision at this point.

2023/03/24: https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

Unfortunately, although the chairs’ obligations under the process was to consider all opposing positions and to find the proposal with the weakest objections, @brentzundel made it clear that when counter proposals were offered, they were not welcome. They were not discussed. They were not brought to the attention of the working group. They were summarily dismissed.

Radio Silence via other channels

Despite reaching out to the chairs via email in a personal letter, the chairs never directly responded or engaged in any fruitful dialog on this matter. The email was cited in the same comment as the previous in @brentzundel’s comment on #27 on

@brentzundel I want to especially thank Joe for reaching out directly and engaging in a private conversation where we discussed this PR, the future of the WG, and the reasons we became involved in this work in the first place.

2023/01/24 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1402233965 :

Frankly, @brentzundel’s assertion that “we discussed” anything is a fiction. He did not respond via email nor phone call nor any channels other than communicating his directives through Github comments.

After the recent VCWG face-to-face meeting in Miami, I pulled Brent aside to talk in person for a moment after everything wrapped. In that brief in-person conversation, I affirmed my disagreement with his current position. He restated his belief that this work isn’t “subject to consensus”, which I briefly debated. During this exchange, Brent said “I don’t care. I just don’t care.” He then asked me, as a point of clarification, if I intend to Formally Object if the current PR is merged. I repeated the same position I have made clear since TPAC in September. Yes. I would not only Formally Object, I would use all ethical and lawful means to oppose this decision, including filing an appeal of his decision to override dissent.

Denial

Brent has repeatedly denied that consensus applies to charter development:

@brentzundel : There are no WG consensus requirements in establishing the text of the charter.

2022/12/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1353537492

While Pierre-Antoine has no problem acknowledging that consensus matters:

@pchampin We clearly didn’t manage to reach consensus here.

2023/01/11 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1379253408

Surprisingly, in that same comment from Brent, he confirms my position:

@brentzundel Consensus must be found by the WG for any items developed in the WG, regardless of what the charter allows.

2022/12/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1353537492

Somehow he wants to be able to act as the chair in this matter, using his authority as chair to direct the output of the group towards a particular charter with particular language, but he simultaneously denies that the Charter is an “item” developed by the WG, despite it being done with DID WG resources, by the DID WG participants, under the leadership of the DID WG chairs.

In person, and in various GitHub issues and on Working Group calls, when faced with diverse opinions, unfortunately, it is an all too common response from Brent that “consensus doesn’t apply.”

Deference to political priorities over technical discussion

A significant frustration during this discussion was the repeated deference to non-technical factors rather than focusing on technical distinctions. Rather than debating what would make the most technical sense, the vast majority of arguments for the chairs’ position were political. Not once did the Chairs put forth any arguments other than deference to the perceived requirement from the Director.

Political factors are inevitable, but it is through technical discussion that the work of the W3C moves forward. The nature of standardization is the forging of alignment between competing interests so that the net result satisfies the greatest value. While we may have different tests for what comprises “value”, it is understood that some collective notion of shared benefit, as perceived by the working group, is the driving goal of collaboratively working through our differences. Each participant brings to the table their perspectives and through technical discussion the working group finds consensus around a shared specification that the W3C can formally recommend to the public as a global standard.

From the process document regarding consensus and dissent:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

https://www.w3.org/2021/Process-20211102/#managing-dissent

Takeaway point: the group should favor the proposals with the weakest objections.

And

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.

https://www.w3.org/2021/Process-20211102/#Votes

Takeaway point: resolving dissent should occur through technical discussion.

Later in the document, it discusses how a group formally addresses an issue:

In the context of this document, a group has formally addressed an issue when it has sent a public, substantive response to the reviewer who raised the issue. A substantive response is expected to include rationale for decisions (e.g., a technical explanation, a pointer to charter scope, or a pointer to a requirements document). The adequacy of a response is measured against what a W3C reviewer would generally consider to be technically sound.

https://www.w3.org/2021/Process-20211102/#formal-address

Takeaway point: Adequacy of a response depends on technical soundness.

And the following from Section 5.4 Reopening a Decision When Presented With New Information:

The Chair may reopen a decision when presented with new information, including:

* additional technical information

* comments by email from participants who were unable to attend a scheduled meeting,

* comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).

https://www.w3.org/2021/Process-20211102/#WGChairReopen

Takeaway point: reopening a decision is appropriate for new technical information not new political information (unless by email from participants who didn’t get their input in earlier).

In summary:

1. The group should favor the proposals with the weakest objections.
2. Resolving dissent should occur through technical discussion.
3. Adequacy of a response depends on technical soundness.
4. Reopening a decision is appropriate for new technical information not new political information

I interpret this to mean that resolving consensus per the W3C process SHOULD depend on considering competing proposals based on technical discussions and selecting the proposal that has the weakest technical objections.

That did not happen in this case.

Three alternative PRs were under consideration.

PR#27, the PR that explicitly added DID methods as in scope. https://github.com/w3c/did-wg-charter/pull/27

PR#29, a PR alternative suggested by @brentzundel that removed DID methods from the scope, with minimal other changes. https://github.com/w3c/did-wg-charter/pull/29

PR#30, a PR alternative suggested by @christopherallen that put forth a DID Resolution WG charter to focus the group on the next step in interoperability and to avoid the alleged mandate from the Director that the next DID WG MUST standardize DID methods. https://github.com/w3c/did-wg-charter/pull/30

PR#27 elicited several technical objections, including multiple participants who made it clear that both Formal Objections and an Appeal would be filed if this charter is put forth.

PR#29 triggered several statements of preference, on both sides, but only one technical objection.

PR#30 triggered a few statements of preference, on both sides, but no technical objections.

In the face of this evidence, both #29 or #30 had weaker technical objections than #27.

On Technical Objections

There is a legitimate question about what constitutes a technical objection. I rely on the process statement that responding to a formal objection must be what “a W3C reviewer would generally consider to be technically sound”.

Technical issues raised (all quotes from Github):

1. There is no DID Method ready for standardization. (technology is not ready)
2. Standardizing DID Methods is like standardizing websites. (layer violation)
3. There is a technical route to meet the letter and the spirit of the prior formal objectors’ request for further implementation guidance. It includes showing the transport layer using the DID Resolution specification, including its test cases, educating the formal objectors regarding what was achieved, and moving specification of example DID Methods outside this WG’s work items. (there’s a better route to technical interoperability)
4. We don’t want to give the impression that some DID methods are more “important” or “required” than others. (decentralization means no privileged parties)
5. We are told there is a mandate to include standardization of DID methods into the working group charter, but the parties that mandate this inclusion have not been actively involved in the WG process in the past, and there is no evidence that they plan to be involved in the future. This lack of active participation raises questions about the legitimacy of their mandate and the potential impact that these objections may have on the future of this standardization process. (consensus-driven technical standardization depends on participation)
6. If we work on any DID method/s, will this put it/them in a “blessed” state, against which no other DID method/s can possibly compete? I highly doubt it. Though, if it does, that would tend to indicate that all desirable features are fully optimized in that method; else, another method would be registered eventually if not immediately. (Dispute of technical issue #4)

Political Issues raised (all quotes from Github):

1. A given did method deserves its own working group (a different group would be better able to manage its own work)
2. I believe it is the case is that the WG must put forward a charter that will not be the subject of a Formal Objection again. (Avoiding Formal Objections is a political goal.)
3. It has been made abundantly clear by those who formally objected to the DID Specification v1.0 that in their view, a future charter that doesn’t include possible DID Methods will be rejected. (Avoiding rejection is a political goal.)
4. There is documented evidence that we were requested, or at least strongly encouraged (“should”), to include DID methods in the next charter. (Deferring to that suggestion in the face of dissent is a political choice.)
5. This does NOT say we will specify any DID methods. It does NOT say we will not specify anything to do with DID Resolution. It leaves the door open to either or both, which flexibility I and the (I believe, substantial) majority of the group … have talked about as both desirable and likely to be needed. (“Flexibility is desirable” is about retaining political authority, not a technical argument that such flexibility will improve the technology.)
6. There were formal objections and comments made to DID-CORE 1.0 expressing concerns around DID methods. but those objections were overruled with a comment that those concerns will be addressed in the future work. If recharter happens now, it would be appropriate to respect the above and mention DID methods in the charter. (Deference to prior objections is political, not technical.)

So there were both political and technical issues raised by various individuals. However, the question that the process requires the group consider is which proposal had the weakest technical objections. Let us look at the Github conversation on these three PRs.

The following table lists all of the group participants who commented on PRs #27, #29, and #30 (noting that we aren’t clear if the staff liaison should be counted as a participant with regard to consensus):

Those that commented relative to a particular PR are given

• “+” for a preference for that PR
• “FO” for the intention to file a Formal Objecti+on if that PR is merged
• “-” to indicate opposition to that PR
• “NC” to indicate no comment made on that particular PR

	#27	#29	#30
brentzundel	+	NC	–	“The DID WG chairs have met.” “The technical objection to changing this charter into a charter for DID Resolution was outlined by @pchampin above.”
TallTed	+	–	+	“I have not said I would be lodging [an FO] in any case”
rxgrant	FO	+	+	“If we allow DID Method specifications under this change to the charter, this kind of disagreement is going to consume the WG. That is a technical issue that must be addressed.”
jandrieu	FO	+	+	“My only recourse if this language remains in scope is to file a Formal Objection, which will have its own unfortunate consequences in the ensuing public debate”
kdenhartog	+	–	NC	“While I’m not actively invested in this discussion” “I don’t believe only resolution will go far enough because the content that can be returned by a DID document is arbitrary and loosely defined.”
OR13	–	+	+	“I approve #29 and request changes on #27.” “I don’t think defining methods is required to achieve interoperability.” “I don’t believe the WG should attempt to standardize DID Methods. I believe doing so undermines the principle of decentralization, and although it might seem contradictory, interoperability at the core data model layer.”
Sakurann	–	-/+	NC	“I don’t believe that rechartering should happen now.”, “If … I would be ok [with DID methods] not being in scope.”
peacekeeper	+		NC	“I slightly prefer #27 (see my comment #27 (comment)) but could also live with this here.”
burnburn	+	NC	NC	“Suggest ‘developed’ instead of ‘adopted’.”
christopherA	FO	NC	+	“To be clear, I am considering a formal objection … should there be a chair decision to merge this PR.”
pchampin	+		–	“I personally prefer #27, but I won’t object to [#29] if it helps moving forward.”,  “I don’t think we can get away with [#30]”

Summary

	#27	#29	#30
Formal Objections Signaled	3	0	0
Comments in favor	5+1	3.5	5
Comments opposed	5	2.5	2

From this evaluation of the working group’s Github conversation, we see #30 has the weakest objections, followed by #29, with #27 having the strongest objections of all three proposals. This count includes both political and technical objections to make the strength of dissent even clearer. If we were to count only those objectors who cited technical arguments, the results would be even more favorable to PR#30.

	#27	#29	#30
Formal Objections Signaled	3	0	0
Comments in favor	5+1	3.5	5
Technical Objections Raised	5	1	0

The decision making process led by the chairs did not “favor proposals that create the weakest objections”, a violation of W3C Process, Section 5.2.2 Managing Dissent https://www.w3.org/2021/Process-20211102/#managing-dissent

I want to highlight a particular fact about these numbers. They represent a snapshot of a brief and incomplete conversation by the Working Group. One of the primary tenets of this appeal is that the chairs did not lead a discussion for the consideration and improvement of either of these alternative PRs. Once dissent was voiced, all conversation was effectively shut down. Instead, the working group should have further discussed the options represented by #29 and #30 and iterated on both to find the best single charter for the group to proceed. It is the failing to have this conversation—coupled with the expectation to blindly follow the directive of the chairs—that is the process violation at the heart of this appeal.

It is evident from comments in the discussion and in their final decision that any alternative to the chairs interpretation of the Director’s comments in responding to the DID Core Formal Objections, would be ignored. Quite simply, the chairs treated a suggestion from the Director as a mandate to override dissent instead of working together as a group to discover a better option.

Claims of “W3C Consensus” are erroneous, out of scope, and irrelevant

In announcing their decision to continue to override dissent (in the merging of #27) @brentzundel said:

@brentzundel: The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year.

2023/03/15 https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1470920464

Unfortunately, the chairs do not cite the basis of their assertion that #27 will produce a charter that best represents the consensus of the group. We have shown in this appeal that the discussion on Github does not justify such a conclusion.

Brent continues:

The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary.

Unfortunately, it is not the chairs’ role to determine the consensus of the W3C, nor is it stated anywhere in the Process that chairs MUST defer to suggestions the Director made in response to previous Formal Objections to a different work product. In fact, as clarified by Phillippe Le Hégaret in regard to the Director’s response to those prior objections (in personal email):

The “should” is NOT a “must”, otherwise it would say so explicitly in the Director’s decision. In other words, the Working Group is allowed to disagree with the direction set by the Director.

Phillippe Le Hégaret, personal email, 2023/03/23

The chairs interpretation of the Director’s response as a mandate is contrary to W3C Process. There is no requirement from the Director in this matter. The chairs incorrectly claim that there is, stating that a W3C Consensus exists that somehow overrides the group’s independent authority. They have used this claim as the fundamental justification for overriding dissent.

The claim of a W3C Consensus is erroneous because the W3C as a whole never had an opportunity to voice their position on the claimed consensus. The response from the Director was a statement resolving an immediate set of objections, stating his suggestion for future work. It was not a statement of W3C consensus requiring the DID WG to charter a new DID WG with methods in scope.

The claim of W3C Consensus is out of scope because the Chairs do not have the authority to assess consensus and speak on behalf of the W3C.

The claim of W3C Consensus is irrelevant because the statement by the chairs is justifying an action by the Chairs regarding an output of the WG. It is not about an action of the W3C.

Even if the W3C as a whole did, in fact, have some sort of consensus on this topic, that alone would not restrict the group from having a different consensus. Of course, a working group may reach a different consensus than the W3C as a whole—after all there are two different groups of participants with different opinions, perspectives, and decision making processes. As such, the consensus of the W3C as a whole is necessarily NOT the same as the consensus of the Working Group. Claims of W3C consensus by the chairs is not only outside their remit, such a “W3C Consensus” should not be taken to require that the WG reach the same conclusion.

Claiming anything about a supposed “W3C consensus” that restricts the actions of the WG is erroneous, out of scope, and irrelevant.

This sets a untenable precedent

The W3C is at a crossroads. Built on trust in the benevolence of Sir Tim Berners Lee, the organization is wrestling with adjusting the process and governance bodies away from a strict dependence on the Director to make major decisions. I appreciate the challenge the organization is facing is like changing the engines on an aircraft in flight. It’s hard. We are in uncharted territory as the organization explores improvements to the Process to deal with this inevitable transition. However, confirming deference to staff as justification for the disregard of legitimate dissent is both inconsistent with the tradition and culture of the W3C and incompatible with an organization whose premise relies on technical cooperation and collaboration. From the W3C mission statement https://www.w3.org/Consortium/mission:

Our Identity “We are an open forum where diverse voices from around the world and industries come together, incubate and build consensus for global standards for web technologies.”

Our Strategic Goals

1. Improve efforts on new technology incubation, making it more structured and improving consensus-building among key stake holders.
2. Achieve worldwide participation, diversity and inclusion, establishing W3C as representative of the worldwide community.
3. Further improve the environment for facilitating balance, equity and cooperation among the participants from different industries, user groups and organizational sizes.
4. Increase involvement of under-represented key stakeholders such as end users, content creators, developers etc.

Emphasis mine.

It is our opinion that if the W3C chooses to interpret staff suggestions as mandates that override working group consensus it will fail to achieve the explicit goals of the organization’s mission.

Shutting down conversation and ignoring dissent does not

1. provide an open forum.
2. improve consensus building.
3. achieve participation, diversity and inclusion.
4. facilitate balance, equity and cooperation among participants.
5. increase involvement of under-represented key stakeholders.

From the W3C Process Document

W3C work revolves around the standardization of Web technologies. To accomplish this work, W3C follows processes that promote the development of high-quality standards based on the consensus of the Membership, Team, and public. W3C processes promote fairness, responsiveness, and progress: all facets of the W3C mission.

The W3C Process promotes the goals of quality and fairness in technical decisions by encouraging consensus, soliciting reviews (by both Members and public), incorporating implementation and interoperability experience, and requiring Membership-wide approval as part of the technical report development process.

https://www.w3.org/2021/Process-20211102

The W3C Process Document lays out the principles and the practices that enable the W3C to legitimately develop standards based on the consensus of its contributors.

If the Director confirms the Chair decision to ignore dissent on this matter, it will set the precedent that Working Group chairs are free to ignore the W3C process should their own opinion coincide with a suggestion from staff. This will transform the organization into a politically driven autocracy that lacks the moral authority of legitimate consensus.

Instead of assisting the W3C in its transition away from a top-down autocratic governance based on the moral authority of Sir Tim Berners Lee to something more meritocratic, confirming the Chairs decision would establish that decisions at the W3C flow from staff down and not from the collaborative, technical discourse of its members.

Proposals with the weakest objections should be favored

The process document states:

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

https://www.w3.org/2021/Process-20211102/#managing-dissent

By this metric, PR#29 or #30 should have prevailed. If you exclude the staff liaison from the tally, you have an equal measure of preference and opposition to #27, including 3 intentions to formally object, plus my express intention to fight this decision with every lawful and ethical means at my disposal to oppose the inclusion of DID methods in the DID WG charter.

PR#27 didn’t even get support by a majority of the group and it absolutely caused strong objections from several of us. Even if you include @pchampin’s position, we barely have a majority in support of #27 with strong objections against. A bare majority and several strong objections from a few people does not meet the standard of Process.

Although I read the Chairs statement several times, I do not see how they could legitimately argue that the favored proposal has the weakest objections from participants in the working group.

Summary

I am asking the Director to reconsider and overturn the DID WG chairs decision to ignore dissent and force DID methods to be in scope for the next WG charter proposed by the Working Group.

Since the chairs are claiming a mandate from the Director as the justification for their decision, I am directly asking the Director if what is happening is, in fact, what the Director required.

I have shown that the chairs, in this case, have failed to pursue all available means to find the proposal with the weakest objections. They have instead imposed their own political agenda over considerable technically-grounded dissent.

To recap:

1. The Chair decision in question lacks consensus.
2. Consensus was not legitimately sought, contrary to W3C Process.
3. Chairs claims of an overriding “W3C Consensus” are erroneous, out of scope, and irrelevant.
4. Deferring to staff sets an untenable precedent for a group that prides itself on diversity and consensus-based decision making.
5. The proposal with the weakest objections should be favored.

I hope that the Director will appreciate these arguments and provide guidance that will remove this unfortunate notion that a Working Group’s chairs must defer to mere suggestions by staff. All Working Groups deserve the ability to manage their own work and find their own consensus without imposition from staff.

In particular, I’d like to see the following remedy from the Director:

1. Clarification: does the Director’s response to the Formal Objections to DID Core 1.0 constitute a direct requirement that the Working Group MUST explicitly charter a subsequent DID WG with DID Methods in scope?
2. Clarification: does the Director’s response to the Formal Objections to DID Core 1.0 constitute a direct requirement that the Working Group MUST NOT charter a DID Resolution WG instead of a DID WG?
3. Clarification: What is the role of technical versus political objections when seeking consensus, especially what constitutes a technical objection?
4. Clarification: What are the requirements of the chairs to seek proposals with the weakest objections?
5. Direction for the DID WG chairs to facilitate a conversation to find better alternatives to including DID methods in the next WG charter, specifically to advance either a true maintenance mode DID WG charter (without license for new specifications) or advance a DID Resolution WG charter instead (focusing new specifications on resolution).

When I got involved with this work, I shared many of my colleagues’ concerns about whether or not the W3C has the cultural and institutional wherewithal to stand as a steward for decentralized technologies. Given the organization’s history with many of the largest companies in the world, significant concerns have been voiced about whether or not the keeper of the Web can handle innovations that challenge the corporate dominance of web standards.  

After the Verifiable Credentials specification was approved as a Recommendation, many of us were hopeful. Then, the DID Core specification took an unprecedented fight before it eventually became a W3C Recommendation. The fight was disheartening, but the ultimate approval gave us cautious hope.

Unfortunately, with @BrentZundel’s unwavering demand that the WG advance a charter that overrides consensus to placate a suggestion from staff, I am again given cause to wonder if the W3C is capable of advancing collaborative work based on true consensus rather than political deference. This appeal puts that notion to the test. It is my sincere hope that the W3C will prove true to its mission and its process and recognize the unfortunate error of the chairs, restoring consensus to the heart of our collective work.

Finally, I want to apologize again to the chairs, Brent Zundel and Dan Burnett, as I have already done personally and in our related Github discussion. Both Brent and Dan are great guys, two of the nicest people you’ll meet in standards development. I consider both of them friends and I’m deeply saddened that this matter has become a public conflict with its inevitable consequences for all of us.

Unfortunately, I find myself in an existential disagreement with a decision they have made collectively in their role as chairs of the WG. As outlined above, I believe the path the chairs have chosen fundamentally undermines the work to which I have dedicated my professional life.

It’s not just that this is an unfortunate decision. It is a decision that I am compelled to oppose with all of the lawful and ethical means at my disposal. This opposition is not personal. I know Brent and Dan are doing their best. Unfortunately, in this case, I find their best falls short of the requirements of their role. I sincerely wish the path to resolve this matter didn’t take us to a nasty public fight. I made eighteen separate comments on the PRs in question trying to convince the chairs of the merit of my argument before escalating. I tried. I’m sorry I wasn’t able to resolve this without calling for intervention.

Thank you for your time and attention. I know this is a lot of material to digest and I appreciate the effort that everyone has made to advance this conversation in a civil and professional manner.

Sincerely,

-j

Joe Andrieu
joe@legreq.com
Legendary Requirements

Understanding Identity through Function
This is the second of a regular column on Identity for the People Centered Internet. In the first column, I introduced the idea of Functional Identity as a way for ordinary people to discuss identity, with this definition:

Identity is how we keep track of people and things, and in turn, how they keep track of us.

This article describes how we do that.

An identity system is a collection of tools and techniques used to keep track of people and things.

As individuals, we do this naturally, in our minds. We name things, then use names and distinguishing features to remember what we learn. We treat people differently based on their identity: treating our friends and family differently from strangers and known threats.

Organizations create processes, software, and services to achieve similar ends. These identity systems are best understood in terms of how they function, which is the same way that identity has worked since the dawn of civilization.

The goal of Functional Identity is to bridge the communication gap so business people, community leaders, and parents can talk with engineers and regulators, and together and we can make identity systems that work better for us all.

Definitions

In the diagrams below, the blue boxes are nouns and the red ovals are verbs – the building blocks for describing identity systems.

We start with the simplest identity system, using three nouns and a verb:

• Subjects are entities—people or things—under consideration.
• Identifiers are labels which refer to entities. They are used to keep track of what we know about those entities.
• Attributes are what we know about people and things. They describe the state, appearance, or other qualities of an entity.
• Correlate means to associate attributes with particular entities, to associate what we know about someone with either an identifier in the system or a subject in question.

Identity systems correlate subjects with attributes in two ways. First, attributes are associated with identifiers referring to specific subjects, thus building a body of knowledge. Then, when we recognize a subject, we associate them with one or more identifiers and everything we know about those identifiers.

For example, consider visiting a local restaurant where your brother, Mike, has suggested you ask for his friend, Su, the chef, who went to the same school you did. The name “Su” is the identifier, and the fact that (1) she is a friend of Mike’s, (2) the chef of the restaurant, and (3) a schoolmate, are attributes you associate with “Su”. When you visit the restaurant and ask for “Su”, you mention to the person who comes out that your brother Mike sent you. Su’s reaction confirms that she knows Mike and that she is “Su”. Now you also know that this person, Su is the chef at this restaurant and that she went to your school. By correlating attributes (chef, friend, schoolmate) with the identifier (Su), you were able to establish a relationship with a person you just met (the subject).

This is the essence of how identity systems work.

These terms apply equally to things other than people, such as organizations, pets, or places. We correlate new attributes with identifiers and vice-versa as we learn about subjects. When we recognize a person or thing we can apply everything we learned about them. In digital systems, this set of related attributes is sometimes referred as a digital identity or profile.

Input and Effect

We learn or acquire identity information over time, then apply what we’ve learned to various interactions, usually elsewhere.

• Acquire means to gather identity information for use by the system.
• Apply means to use identity information to affect change outside the identity system, typically to moderate an interaction of the subject with a related system.

Identity information might be acquired by observation or by importing from elsewhere. We may learn about someone by watching them, or we may learn through references, rumors, and reputation. Identity systems acquire new information throughout their operational life, just as we continue to learn about people throughout our lives.

Once acquired, identity information must be applied in a specific situation to have impact. If we know something about someone and no one ever acts on, nor shares, that information, it doesn’t affect the world. The way that identity information is applied tells us how an identity system affects our world.

For example, a website might apply the email associated with my account to allow me to reset my password or it may send me unwanted advertisements. The U.S. Transportation Security Administration (TSA) applies the information on its no-fly list to prevent those identified as potential threats from flying.

Making New Ideas

We gain new insights by considering both existing identity information and previously unrelated observations. Identity is more than just what we know about people and apply to our interactions. It’s also how we make judgments based on what we know, gaining insights into character, capabilities, and proclivities.

• Raw data are data which may or may not contain information relatable to a person or thing.
• Derived attributes are conclusions reached by reasoning over identity information. They are what we learn when we consider what we know about people and things.
• Reason means to evaluate existing identity information to generate new derived attributes.

Derived attributes are created by reasoning using raw data and known attributes. By applying reasoning on existing observations and related knowledge, we can gain insights that neither the subject nor the original author anticipated. Raw data such as search history, web browsing, and the time & location information captured by our phones, may contain identity-related information, even when that was neither the purpose nor the intention at the time of capture.

We reason using known attributes to derive new ones. For example, we calculate a person’s age based on the birthdate on their driver’s license to determine if they are old enough to drink legally. Credit companies evaluate recent income, past transactions, and projections of future income to set interest rates and make loan approvals. We remember how people treated us and alter our behavior in future interactions. If someone repeatedly breaks their word, we may stop depending on them.

Securing Identity Information
We go to great lengths to keep identity information secure.

• Secure means to restrict the creation and flow of identity information to the right people at the right time.

Sometimes we keep secrets to prevent information from reaching certain people. We do this with tools like encryption, access control, and minimal disclosure. Legal agreements between people, businesses, institutions, and governments specify appropriate use of certain information while laws, regulations, and the courts allow governments and institutions to oversee, monitor, and intervene in the capture and use of identity information. How identity systems secure certain information, and not others, defines how they preserve and respect privacy.

The right to keep private information private is often referred to as the right of privacy. Many people feel their privacy is threatened because so much information is shared over the Internet, in our workplaces, and through our devices. Information we share in different contexts (business, family, community, etc.) can leak unexpectedly and undesirably into other contexts. For example, the sick day we took for a medical procedure might lead to the human resources department learning about a life-threatening medical condition, resulting in reduced consideration for promotions and new opportunities. Preventing human resources from learning the nature of the procedure (a private matter) is one form of securing identity information to protect our future at the company.

It is very difficult as individuals to track of all the ways we are publicly or privately tracked. Information is shared on social media, tracked in Internet searches, monitored when using navigation software, and captured as we use our phones. The sheer magnitude and complexity of the information tracked and used means the average person is essentially incapable of making informed decisions to consent to appropriate use. Some people give up, divulging personal information without regard to consequences. Others opt-out, participating as little as possible in our digitally connected world.

We can learn—and teach others—how the concept of identity matters in our lives and the options we have for protecting ourselves, our families, and our businesses. For example, parents can learn how publicly shared photos of their children—and their friends’ children—can unwittingly expose them to pedophiles and human traffickers. Teachers and coaches can learn techniques for limiting the exposure of students’ and players’ information to inappropriate eyes. Small and large businesses can learn how indiscrete requests for simple information like phone numbers or addresses can lead to social engineering attacks and identity theft. A better understanding of identity can help all of us protect ourselves through better identity hygiene.

Bridging the Gap

The nouns and verbs above are grounded in the world of technology and may be unfamiliar for the average individual. More conversational synonyms are presented in the table below. Feel free to use either, depending on the audience.

People, places and things
This is the point of identity: those people, places, and things we recognize.

Technologists	Laypeople	Common meaning
Subject	Person	Someone under consideration. The subject of inquiry.

Identity Information

These are the nouns of identity.

Technologists	Laypeople	Common meaning
Identifiers	Names	Refer to entities. Used to keep track of people and things.
Attributes	Statements	What we know about people and things. They describe the state, appearance, or other qualities of an entity.
Raw data	Observations	Data which may or may not contain correlatable information.
Derived attributes	Beliefs	Conclusions reached by reasoning over identity information. These are what we learn when we consider what we know about people and things.

Identity Actions

These are the verbs of identity.

Technologists	Laypeople	Common meaning
Acquire	Collect	Intake or generate identity information for use by the system.
Correlate	Relate	Associate attributes or observations with particular entities. We associate what we know about someone with either an identifier in the system or with a subject in question.
Reason	Reason	Evaluate existing identity information to generate new beliefs, expressed in attributes, captured in statements.
Apply	Apply	Use identity information in a system, typically to moderate interactions with known entities.
Secure	Protect	Restrict the creation and flow of identity information to the right people at the right time.

For technologists:

We assign identifiers to subjects. We collect raw data and correlate attributes to the subjects we track. We reason over raw data and attributes, to derive new attributes. We then apply this information to current and future interactions with subjects. We secure identity information to preserve privacy.

In more ordinary language:

We give names to people. We collect observations and record statements relating those observations to people we know. We reason over these observations, statements, and beliefs to generate new beliefs. We then apply what we know and believe when dealing with those we recognize. We protect identity information to preserve privacy.

This is the vocabulary of Functional Identity, a way to discuss identity in terms of functionality: how it works and what it does for us.

Summary

Functional Identity focuses on how identity works. We avoid the psychological, cultural, political, and philosophical notions of identity. These notions are important, but they can also distract us from understanding the technical choices involved in building and using identity in today’s Internet-enabled world.

This focus on functionality may help clarify and improve your own conversations about identity.

How we keep track of people and things is not just a technical matter, it affects our lives. For many, identity is not a conceptual issue, it can literally be a matter of life and death.

In future articles, we’ll use this language of Functional Identity to describe how real-world identity systems are being built and how they enable a people-centered Internet.

Please take a moment and share this with your colleagues and friends, and let us know what you think. Comment below, or email me at mailto:joe@legreq.com.

This article also appears at https://peoplecentered.net/2017/07/26/how-identity-can-enable-a-people-centered-internet/