Fighting for Consensus, Take 2

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.

Posted in Uncategorized | Comments Off on Fighting for Consensus, Take 2

Fighting for Consensus at the W3C

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

5.5. Chair Decision and Group Decision Appeals

When group participants believe that their concerns are not being duly considered by the group or the Chair, they may ask the Director (for representatives of a Member organization, via their Advisory Committee representative) to confirm or deny the decision. This is a Group Decision Appeal or a Chair Decision Appeal. The participants should also make their requests known to the Team Contact. The Team Contact must inform the Director when a group participant has raised concerns about due process.

Any requests to the Director to confirm a decision must include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions must be recorded.

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.

Figure 1. DID Architecture

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.

Figure 2. Web Architecture

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.

  1. The PRs lacked consensus
  2. Consensus was not legitimately sought
  3. Claims of “W3C Consensus” are erroneous, out of scope, and irrelevant
  4. This sets a untenable precedent
  5. Proposals with the weakest objection should be favored

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

@brentzundel: Out of respect for the opposing positions stated here, I have opened a separate PR that removes all mention of DID Method Specifications #29.

Whichever PR achieves greater consensus, as determined by the chairs of the current DID WG, will be merged.

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

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”
rxgrantFO++“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.”
jandrieuFO++“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+NCNC“Suggest ‘developed’ instead of ‘adopted’.”
christopherAFONC+“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 Signaled300
Comments in favor5+13.55
Comments opposed52.52

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 Signaled300
Comments in favor5+13.55
Technical Objections Raised510

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

Posted in Uncategorized | Comments Off on Fighting for Consensus at the W3C

A great conversation about #GoodID

Ancient barbarian warrior or Gladiator ready to fight

Identity can be a real pain to discuss. I’ve been to dozens of workshops and conferences over the last decade plus and the quality of engagement varies from exciting, enthusiastic progress to frustrating, disheartening dysfunction—even within the same event. So many of us bring our own ax to grind that even when we think we are in agreement, we can spend ridiculous amounts of time in rat holes and rabbit holes that just don’t go anywhere productive. Yet, identity matters. So we push on through, hoping to forge common ground and make headway against the seemingly intractable task of figuring out how identity should work in the digital age.

So it is rare that I get to enjoy as productive a conversation about identity as I did earlier this month at Good ID: What’s policy got to do with it?, organized by the Omidyar Network, run by Caribou Digital, and held at the Shorenstein Center of the Harvard Kennedy School. It wasn’t a collaborative writing exercise like we host at Rebooting the Web of Trust. It wasn’t an unconference open space like we gather for at the Internet Identity Workshop. It wasn’t a trade conference with presentations and panels like we get at Know Identity. Nor was it a large scale summit bringing together the international community with technologists like ID2020. On the contrary, it was an intimate gathering of passionate and experienced individuals from diverse fields, first discussing what “Good ID” might mean and how policy can help us get there, then committing to concrete actions to collectively advance the cause.

Not only did we avoid the all too common pitfalls I’ve seen again and again at other gatherings, under the calm, competent hand of facilitator Tessa Finlev of the Institute for the Future, we rappelled from a stratospheric, high-concept, open discussion about what Good ID means, down to specific, detailed, self-assigned marching orders.

Fan boy photo
[Not actually me]

I apologize for the apparent fan-boy nature of what I’ve written so far, but creating a productive dialog on identity is hard. Omidyar and Caribou Digital deserve credit for deftly bringing a challenging topic to such a productive engagement. The meeting brought together great people and guided us through a focused conversation leading to actionable tasks.

What was particularly exciting about the Good ID workshop is that it is focused on how we transform policy to realize the ambitions of well-meaning identity advocates everywhere. At the end of the day, it doesn’t matter what the “Identerati” talk about if policy makers ignore the lessons learned from literally decades of experiments in digital identity. Billions of dollars have been invested in bringing digital identity systems to bear on the world’s problems. From consumer-based identity services from Microsoft and Facebook, to sovereign identity systems like Aadhaar in India or RealID in the United States, to the most recent open standard advances of OpenID Connect and immanent decentralized identifier standard at the W3C. The key failure point in extant systems—and the greatest risk in those still under development—is failure of decision makers to make the right decisions.

These were failures in policy, not technology. With Facebook, the system worked. We just didn’t understand how it could be manipulated and abused until Cambridge Analytica showed us. With Aadhaar, the biometrics and authentication technologies work as intended—it just overcentralizes too much personal data in a brittle state mandated, privately run system, effectively creating a vast digital surveillance system. With OpenID, large companies like Facebook and Google were happy to issue “identities” but refused to accept them from others, resulting in an extension of their monopoly power rather than the liberating user-centric vision its inventors intended.

With decentralized identifiers, I have no doubt that the underlying technology will deliver the basic nuts and bolts of an identity layer, but will credential issuers and relying parties adopt the technology as we intend? Or will they co-opt the basic function to re-intermediate themselves into our digital lives? The challenge isn’t in the technology, it is in shifting the mindset, perspective, and will of decision makers. The hard part is shifting the policy of the powers in charge, toward creating and maintaining identity systems that respect and ensure human dignity rather than trapping people in technology distopias governed by the tyranny of data, where what’s in the database matters more than the humanity of the person in front of you.

And that is precisely what Good ID is all about.

Two businesspersons shaking hands in agreement in casual business setting at office

It’s a conversation about shifting policy at every level to better support humanity in the digital age. It’s about taking all stakeholders’ needs into account, from law enforcement to tax authorities, from illegal immigrants to victims of domestic violence, from mega corporations with a billion users to local community organizations like churches and schools. Each and every one of these constituencies bring unique perspectives and needs to the conversation about digital identity. Some need rigorous accountability, others need the freedom to engage society on their own terms. Some need to set and enforce regulatory frameworks that cross international boundaries, others just want to be able to communicate with people they trust. Some thrive in Western notions of individuality and freedom, others feel more at home with notions of harmony and placing society before self. If we are going to build a global system of identity on top of our global system of digital telecommunications—both the Internet and mobile interconnectivity—then we must do so with bright eyes and open hearts to the real, concrete needs of every player in the mix. The different needs and requirements and the resulting disagreements over what determines good policy will never fully disappear, but by understanding both the differences and the commonalities, we have the best chance to find policy that best suits the most needs of all parties.

It was a GREAT conversation in Boston. I look forward to continuing it at http://good-id.org as we work together to shape digital identity in the 21st century.

Posted in Identity, privacy, regulatory, Technology, Uncategorized | Tagged , , , , , | Comments Off on A great conversation about #GoodID

Aadhaar: digital identity writ large in India

India has forged new ground in digital infrastructure with its IndiaStack [1] initiative and Aadhaar, the biometric identity system at its core. Aadhaar is the largest state-sponsored digital identity system in the world. With over 1.1 billion Indian residents enrolled, it is transforming the world’s second most populous nation from an underdeveloped state into an advanced digital society. It isn’t perfect, but its successes and failures offer important lessons in the opportunities and the pitfalls of national identity systems.

Architecturally, Aadhaar is a voluntary, biometric-based identity proofing layer upon which additional services can be built. By design, it is as minimal as possible, enabling a single function: state-endorsed biometric authentication of individual Indian residents. It is one of five core IndiaStack applications, which together provide foundational digital services throughout India. The other four are

eKYC – Digitize your KYC (Know Your Customer for bank account creation).

UPI – Transfer money between bank accounts in India.

Digilocker – Retrieve, Store & Share verified digital documents.

eSign – Sign any document electronically.

In addition to these government provided applications, registered companies can build apps on top of IndiaStack. In the words of its chief architect:

Large scale social problems require “unbundling of the problem”
and creation of “shared digital infra” as “public good” on top of which
“innovative solutions” can be “assembled” to meet diverse contextual needs.

–Pramod Varma, Chief Architect, Aadhaar

At the 2017 ID2020 [2] summit, Pramod Varma put it this way: Aadhaar provides robust de-duplication so services can know definitively that people aren’t lying about their identity, such as filing double claims for benefits or other advantages. A set of open APIs, IndiaStack provides “digital infrastructure platforms as public good to allow solutions to be assembled by the ecosystem.” In other words, the five IndiaStack services are a public good that enables applications that better serve the people of India.

Aadhaar’s separation of identity from the services which depend on it is a profound shift towards a human-centered Internet. No longer is an individual’s identity tracked on an ad-hoc basis by private, corporate interests like Google and Facebook. Instead, identity proofing is provided as a fundamental utility of the state, just like roads, water, and the courts. Or a passport.

Many contend the opposite: that the functional result of a system like Aadhaar is the subjugation of the individual to the state. That by creating a national system to track everyone’s digital actions, India has, in fact, reduced the humanity of its residents to mere digital ones and zeros. While traveling abroad may deserve additional credentialing, like passports, makes sense, within one’s own country, a free state has no legitimate cause for persistent tracking of individuals’ digital transactions.

In short, Aadhaar is at least as controversial as it is enabling. To understand the conversation about Aadhaar, let’s examine it through the lens of Functional Identity, introduced in my two previous articles. Speaking of Identity [3] and How Identity Can Enable A People-Centered Internet [4].

The experience

It starts with enrollment.

Individuals in India establish an Aadhaar number by visiting a registrar or enrolling agency. Enrollees provide proof of identity and address through documentation, assertion by a head of family, or specially authorized “Introducers”. Biometrics are captured by certified devices: retina scan and fingerprints. Individual’s demographics are also recorded: name, birthdate, physical address, and an optional mobile number or email address. These are associated in a central government database with a unique identifier, the enrollee’s new 12 digit Aadhaar number.

When individuals use Aadhaar for authentication to various services, they provide their Aadhaar number and at least two of three authentication mechanisms (biometrics, demographics, and a One Time PIN sent by email or mobile). This request is encrypted and sent to a central verification service, which returns a simple Yes or No, indicating successful authentication or not. Services are then provided or denied.

Let’s put this in terms of Functional Identity. Here are the nouns and verbs of Functional Identity in Aadhaar.

The nouns

subjects

Individuals in India, both citizens and otherwise.

subjects

Unique, 12 digit Aadhaar numbers are created in the centralized Aadhaar database for each enrolled individual.

subjects

Biometric templates (retina, fingerprint), demographic data (name, date of birth, address, gender), and optional contact info (email or mobile). Plus, any attributes stored by service providers and associated with an individual’s Aadhaar number. While these are not within the Aadhaar system, they are a functional part of the identity enabled by Aadhaar.

subjects

Sensor readings from authentication devices. Meta-data associated with each authentication request: timestamp, source of authentication request, etc.

subjects

The only derived attributes I discovered are One Time PINs which can be sent to the registered email or mobile number for immediate use at the point of authentication. Please email me if you know of any Aadhaar analytics creating new attributes based on raw data and attributes.

The verbs

subjects

Attributes are acquired at enrollment, which takes place at authorized enrollment centers, some of which are privately owned and operated. Biometric scans and demographics are acquired at the point of authentication throughout active use of the system.

subjects

Biometric and demographic attributes are correlated with the Aadhaar number during enrollment.
At the point of authentication, at least two of the following three are submitted to a centralized registry for verification:

  • biometric scans from sensor readings,
  • demographic data matching registered attributes, and/or a
  • One Time PiIN (OTP) sent via mobile text or email

On a successful match, the individual is correlated with their Aadhaar number.
Services relying on Aadhaar correlate the physical person and their own records with that identifier.

subjects

Based on the internal records associated with a given Aadhaar number, various services may be provided or denied. For example, the national welfare system uses Aadhaar to ensure no one is paid twice for the same welfare benefit. Services may also accumulate records that can be securely and reliably associated with the authenticated individual, restricting future access to that individual or someone with their explicit consent.

subjects

At the point of authentication, the central verification service analyzes the sensor data, demographics, and One Time PIN to find a matching profile.
Presumably anomaly detection monitors authentication requests to help detect possible cyberattacks. Other data mining may occur, but legally it needs to face the test of national security. Details of any such mining are not public at this time.

subjects

Data is secured by cryptography, process, and regulation. Resident data and raw biometrics are always kept encrypted, even within registry data centers. Individuals can freeze their Aadhaar number so nobody can use it, even them. By law the biometric and demographic data used for authentication cannot be stored. In practice, not all systems adhere to the requirements.

The controversy

Aadhaar is a transformative experiment, designed to leapfrog India’s infrastructure from an underfunded, underdeveloped bureaucracy struggling to reach all of its citizens to an efficient digital society where cost-effective electronic services can be reliably provided more quickly, more broadly, and with greater impact at lower cost and waste.

At the same time, the open approach raises fundamental questions about privacy in a digital world. As “voluntary” use of Aadhaar for services effectively becomes mandatory due to the hassle of alternatives, IndiaStack becomes a compulsory architecture of surveillance covering nearly all digital life, requiring neither probable cause nor search warrants. As IndiaStack enables even more services and touches on even more aspects of individuals’ lives, the surveillance coverage and privacy risks only increase. Shouldn’t it be possible for a person to buy a cup of coffee without the government knowing about it? Is it really appropriate to embed government tracking into the majority of transactions in an Indian person’s life?

Several court cases have charged Aadhaar, IndiaStack, and related services with violating the rights of Indians to “life and liberty” as protected under Article 21 of the Indian constitution. In August of this year (2017), the Indian Supreme Court ruled that privacy is more than just a common law right, subject to legislative override. Rather, it is a fundamental right that cannot be denied without appropriate cause and due process.

“The State must ensure that information is not used without the consent of users and that it is used for the purpose and to the extent it was disclosed,” said Justice S K Kaul. He added that … “automated processing of personal data… to analyse or predict… performance at work, economic situation, health, personal preferences… can result in discrimination based on religion, ethnicity and caste.”

Justice Chandrachud ruled that creating regimes for data protection “requires a careful and sensitive balance between individual interests and legitimate concerns of the state”. [5]

The court’s ruling sends several cases back to lower courts for judgment in light of a more stringent constitutional, rather than common law, test of legality.

The controversy is far from settled. As the details are considered, the benefits must be weighed against the harms. Ultimately, India must decide whether the good outweighs the bad as well as what can and should be done to reduce those harms without losing this promising new digital infrastructure.

In my next column, I’ll dive into that debate: The benefits and the harms, the options for improvement and lessons learned.

It’s clear that Aadhaar is an unprecedented success by many measures. The rest of the world has much to learn from both its victories and its failures. Perhaps, through Aadhaar, we can better understand the true opportunity for a people-centered Internet.

This article also appears at https://peoplecentered.net/2017/11/16/aadhaar-digital-identity-writ-large-in-india/

[1] The IndiaStack website. http://indiastack.org

[2] ID2020 http://id2020summit.org

[3] https://peoplecentered.net/2017/06/11/speaking-of-identity/

[4] https://peoplecentered.net/2017/07/26/how-identity-can-enable-a-people-centered-internet/

[5] Kaushik, Krishin, “Right to Privacy: After Supreme Court judgment, all eyes now on Aadhaar case” The Indian Express. August 25, 2017. Accessed online October 17, 2017, http://indianexpress.com/article/india/right-to-privacy-verdict-what-next-all-eyes-now-on-aadhaar-case-4812352/

Posted in Functional Identity, Identity | Tagged , , , | Comments Off on Aadhaar: digital identity writ large in India

How Identity Can Enable A People-Centered Internet

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.
Subjects, Identifiers, Attributes, Correlate

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 & Apply
  • 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, Derived attributes, and Reason
  • 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
  • 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:
technologist
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:
layperson

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/

Posted in Uncategorized | Comments Off on How Identity Can Enable A People-Centered Internet

Ten Years Later

Ten years ago I wrote a blog post that captured a key architectural insight at the core of VRM: putting the user at the center of integration not only improves the quality of services, it simplifies our systems.

When we put the user at the center, and make them the point of integration, the entire system becomes simpler, more robust, more scalable, and more useful.

The article captured the gestalt of VRM and helped catalyze a range of conversations that still shape the VRM approach.

Since then, we have seen a lot of progress. Sometimes we proceeded in fits and starts and there were certainly failures along the way, including my own venture, SwitchBook. When I started pulling together my notes for this anniversary post, I was mildly surprised and delighted at how much real work got done and the real-world impact we’ve had. Here are a few VRMy developments in the last decade worth noting.

Please chime in with a comment if you know of a good one to add to the list.

Coming in December of that same year, OAuth kicked off a series of standard protocols for identity, attribute sharing, and permissions, including OAuth 2.0, OpenID Connect, and User Managed Access (now at 2.0). These efforts brought together the leading technology companies to collaboratively develop new standards that give individuals greater flexibility and control over data exchange between online services.

Companies like Personal.com. (now TeamData), Digi.me, and Cozy Cloud shipped user-driven personal data stores. Software project HIE of One offers a personal data store that lets individuals manage our own healthcare data.

In Europe, GDPR has ushered in a new wave of regulatory requirements and penalties driving companies and organizations to give individuals easier access to, greater control of, and more security in our personal data. JLINC Labs offers a provenance service layer that allows companies to quickly attain GDPR compliance for the right to erasure and data provenance by giving individuals direct control over which data is used for what purposes.

Kantara Initiatives’ Consent & Information Sharing Work Group (CISWG) has published its Consent Receipt Specification to help both individuals and organization keep track of data provenance and terms of use.

Working with the CISWG, Customer Commons has picked up the challenge of developing customer-driven terms of use called “first party terms”. Asserted by individuals when interacting with websites, they are designed to provide a balance to the ubiquitous company-asserted terms of use we all are forced to accept when we interact online.

Perhaps the biggest recent splash has been made by self-sovereign technology, which provides distributed identity services completely independent of any centralized authority. Using distributed ledger technology, firms like Evernym, Blockstream, Digital Bazaar, Microsoft, and IBM are enabling a wide range of robust identity services that put individual users in the driver’s seat.

Collaborative initiatives like Sovrin, Hyperledger, the Decentralized Identity Foundation (DIF), Rebooting Web of Trust, W3C Verifiable Claims Working Group, and ID2020 bring technologists together to develop open source and open standards solutions that realize secure, privacy enhancing, self-sovereign architectures.

ID2020 brought the self-sovereign technology conversation to the UN, convening technologists, UN staff, representatives from sovereign states, and NGOs to explore how block-chain based approaches might enable cost-effective, scalable solutions for U.N. Sustainable Development Goal 16.9 https://sustainabledevelopment.un.org/sdg16: to give everyone on the planet a legal identity by 2030, including birth registration.

International non-profit technology solutions organization iRespond has agreements in place and is seeking funding for a self-sovereign identity layer to bootstrap identification credentials for tribal people in the border region of Myanmar and Thailand. These self-sovereign credentials will the recognized and used by local governments to provide work permits, health care, and other services.

There is still a long way to go, and there probably always will be room to improve whatever systems we build. The conversations continue at the Internet Identity Workshop (IIW), the People Centered Internet, and of course, on the Project VRM mailing list as well as the collaborative initiatives mentioned above.

Do you know a VRMy project that’s made a difference? Share with us in the comments.

Posted in Identity, ProjectVRM, Vendor Relationship Management | Tagged , , , , , , | Comments Off on Ten Years Later

Speaking of Identity

Identity is one of the most important constructs of society. It’s also one of the hardest to discuss.

I’ve been in perhaps hundreds of conversations in over a dozen years about user-centric and digital identity. I’ve realized that many of our challenges in digital identity stem from two problems in these conversations. First, miscommunication; we often use the same words with different meanings. Second, we get distracted by compelling but unproductive discussions about different aspects of identity. In response, I’ve begun a conversation about how to talk about identity in a way that is both accessible and rigorous.

I want to find a way to discuss identity that laypeople understand, without alienating technologists. Digital identity—like the rest of our Internet-enabled world—is scaling faster than society knows how to handle. If we don’t develop a simple way for experts to talk with regular people about both identity and its realization in digital identity, it will be nearly impossible to build an Internet identity layer that fully addresses the needs of a modern global society. One way or another, that identity layer is being built. I believe a better conversation will make a difference.

Consider for a moment a slightly different way to think about identity: Functional Identity. If the approach feels off or triggers a reaction, please drop me a line at joe@legreq.com. If we are to discover how to talk about this simply and effectively, your response is a valuable part of the discourse.

Reframing Identity

Our framing of identity determines how we talk about it. The facets of identity are so rich that we each bring our own hot buttons and agendas to any discussion. Some engage from a philosophical perspective, others cultural. Some dive into political issues and others get meta-physical and spiritual. These different frames are valid aspects identity’s impact on our lives. Not just valid. Vital. They help answer the question of “Why?” Why it matters, why we should care. Unfortunately, they also inflame passions. We often talk past each other to make points that have minimal relevance in other frames, leaving everyone frustrated and unheard.

As an engineer, I’m concerned with how things work. I want to learn how to fix what’s broken and how to build new things. In short, I want to know how things function. With identity, this functional perspective sidesteps the inflammatory rabbit holes, without dismissing them. Once we understand how Identity works and how we use it, we can explore how different identity choices affect individuals and society. Functional Identity lets us investigate the HOW without prejudice to WHY, viewing identity systems based on how they work and then, in turn, how they affect individuals and society.

A Functional Definition

Identity is how we keep track of people and things and, in turn, how they keep track of us.
That’s it. We learn people’s names, we observe them and hear gossip and consume media. We then apply that sense of who they are to our dealings with them. Others do the same in return.

In computational systems, we assign identifiers, we accumulate observations, we correlate those observations with entities, we make conclusions based on those observations and we apply those conclusions in interactions with those same entities.
In other contexts, we give people name tags, we share business cards, and we wear bracelets. All to facilitate keeping track of each other.

This simple definition is provocative. It triggers associations with Big Brother and the surveillance state. It brings up ideas about embedded chips and tattooed serial numbers. It conjures fears of government or corporations constantly tracking what we do.
Which is ok, because, in fact, those are the most feared abuses of identity. It’s important to realize when we talk about identity that we are always talking about how we keep track of people.

There are also a number of wonderful uses of identity that are worth remembering. The joy of a child saying “Momma” or a lover calling out your name. The pride in your name on a diploma. The simple benefit of seeing another’s name tag at a workshop and better remembering that fascinating conversation. Identity enables so much good stuff *because* it helps us keep track of people and things.

Like white space in visual design or writing, identity systems are also defined by how they prevent or minimize tracking. While identity is useful, too much tracking is untenable. Every identity system makes choices about efficiency and privacy, enabling specific means of tracking while limiting others. Realizing that the good consequences of identity inevitably enable the bad is fundamental to understanding how to build systems that appropriately balance the two.

The functional approach reaches beyond digital systems to understand how identity works throughout society. By better understanding how identity functions, we will be able to build systems that enhance privacy and human dignity, while improving identity assurance and security.

Why?

Engineers, entrepreneurs, and financiers sometimes ask “Why?” Why are we spending so much time with navel-gazing conversations about identity? Why not just build something and fix it if it is broken? To be fair, I get why “Identity” with a capital “I” is banned in certain working groups. Those distracting conversations can derail productive efforts to build good systems and ship working code. And yet, there is a vitally important and simple reason to better understand identity: human dignity.

When we build identity systems without a core understanding of identity, we risk inadvertently compromising human dignity.

There are times when security concerns demand compromise. Fine. It’s the job of our political systems—local, national, and international—to moderate the worst abuses and to establish boundaries and practices that serve basic human rights.

But when engineers unwittingly compromise the ability of individuals to self-express their identity, when our systems subject individuals to unreasonable restrictions and deny basic services because of a flawed understanding of identity, that’s an avoidable tragedy. What might seem minor today could lead to the loss of privacy, liberty, or even life for an individual whose identity is unintentionally compromised. That’s why it pays to understand identity, so the systems we build intentionally enable human dignity instead of accidentally destroy it.

In a future column, we’ll discuss the elements of Functional Identity, with the eventual goal of defining the fundamental objects and methods that comprise any identity system, digital or otherwise. From there we can start to explore the impact on privacy and freedom and human dignity that different identity systems afford.

In the meantime, I’m off to ID2020, a UN Summit about the potential for blockchain technology to help with UN Sustainable Development Goal (SDG) 16.9. We’ll be exploring how self-sovereign identity might enable us to create a legal identity for everyone on the planet by 2030, including birth registration. Not a small task.

I hope you’ll join me as we continue the conversation.

This article also appears at https://peoplecentered.net/2017/06/11/speaking-of-identity/

Posted in Identity, Technology | Tagged , | 1 Comment

Detail is the enemy

Rigor is your friend.

When defining the requirements for a system, its best to avoid detail and focus on rigor instead.

Endless prescriptive details are the bane of good requirements. What to do or not do. Features. Capabilities. Constraints. So many things you can say that its hard to tell what to focus on. Too much detail prevents understanding rather than enabling it.

I had a client once who believe their 250+ “user stories”, diligently and exhaustively captured in Jira, perfectly described the system we were to build. Unfortunately, no one else could see through the muddle to understand what we were supposed to do. Not her boss. Not the engineers. Not her peers in the organization.

Understandably, she was frustrated when others said they don’t understand our priorities or even what the MVP (minimal viable product) actually is supposed to be. She had doubtless put hundreds, perhaps thousands of hours into capturing every detail that should be addressed as we built out the product. Her intention, diligence, and technical skill were all exemplary, and yet, the extensive Jira entries failed to do what she most needed them to do: help her collaborators understand the requirements of the product we were going to build together.

In my experience, this is a common pattern, a perfectly natural result of product managers and engineers focusing on quantity and detail rather than rigor, clarity, and focus.

Working together, we were able to build a consensus with the founder of the company (and our boss) about the #1 focal use case. That use case not only provided clarity about how engineers might choose between tradeoff in early development, it cemented understanding between the technical team and the founder about what capabilities and what work are most important to the near term success of the company.

When we were able to focus on a single use case, we were able to answer–even as a temporary conclusion–questions that were preventing software development from moving ahead. The rigor needed to understand, gain consensus, then implement that single use case proved to be far more practical, actionable, and valuable than the year’s worth of accumulated “user stories” in Jira.

Don’t get me wrong, the background work in fleshing out the full range of requirements was useful. It provided the foundation for distilling that single focus use case and served as an indelible record of the research and experimentation performed in the early days of the company. It was, on its own merits, solid work.

Yet it wasn’t until we stepped back from the cacophony of requirements in that seemingly endless Jira database of “user stories” that we were able to execute on the vision. When we rigorously worked through how just one single use case would work it required a system architecture–even as a strawman for discussion. It also required acknowledging and sandboxing additional capabilities that while important and interesting long term, simply didn’t apply to the one single use case. When we let the focal use case filter the endless possibility of the product into a single interaction, the system requirements solidified into a proposed design and working code in short order.

Yes, the code was incomplete. No, it didn’t do everything the ultimate product would. But it ran. It was demonstratable. It created the ground for the next phase of the conversation between product management and the company’s executive team.

In short, the rigor of understanding a single, limited, focal use case proved to be immeasurably move valuable than the exhaustive detail of hundreds of user stories.

So the next time you’re collaborating on a new system, right the urge to specify every last detail, to exhaustively list all the things it could do, and instead rigorously figure out how the product will do the one most important thing it needs to.

Do that and you’ll create a real product, capable of becoming that amazing vision rather than creating an unattainable vision that no product could encompass.

Posted in Development, Requirements Modeling | Tagged , , , , , | Comments Off on Detail is the enemy

The Moral Burden of the State

There are times when it is appropriate for the state to restrict our liberties. To detain us. To imprison us. Even to take human life.

The constitution and the institutions of our republic imbue the state with the moral authority to restrict our liberties, subject to checks and balances that work to keep inevitable errors and excesses to a minimum.

There is no time when it is appropriate to abrogate the moral obligation of the state and give corporations the role of restricting our liberties. Not because it is convenient. Not because it is cheaper.

Corporations are not only free from the constitutional framework of the state, they are legally required to maximize shareholder value. They are structurally unable to place the moral needs of the state–or the individual or society–ahead of corporate interests.

Institutions designed for profit cannot credibly wield the moral authority of the state.

The moral burden of the state cannot be separated from it.

Please consider signing Bernie Sander’s petition to end corporate prisons. It’s time to stop profiting from incarceration.

https://go.berniesanders.com/page/s/private_prisons

Posted in regulatory | Tagged , , | Comments Off on The Moral Burden of the State

Open all files in separate emacs windows

How to open everything in a directory with emacs, each in their own window:

find . -type f -exec $SHELL -c '"$0" "$@" &' emacs {} \;

Many thanks to ephemient at StackOverflow for the inspiration: http://stackoverflow.com/questions/853451/can-the-find-commands-exec-feature-start-a-program-in-the-background

Posted in coding | Tagged , , , | Comments Off on Open all files in separate emacs windows