Find a better name for the specification

[jandrieu]

The "controller" document is a bit of a challenge to understand.

We should consider other names that better describe what it actually does.

[selfissued]

Yes, it's an opaque name but it's a name that's been in use. Unless a clearly better name is found, I think we are where we are.

[iherman]

The issue was discussed in a meeting on 2024-09-27

• no resolutions were taken

View the transcript

3.9. Find another name (issue controller-document#100)

See github issue controller-document#100.

Brent Zundel: I will queue up the conversation, we are stopping at 12:30, folks can continue to talk about it over lunch.
… this conversation is strictly time boxed to 6 minutes.

Joe Andrieu: just want to say that a lot of my confusions around what a DID document has or should have was clarified when I understood how verification methods and relationships worked, so why not verification document.

Manu Sporny: that's a good candidate. We are potentially going to add services into this, modulo concerns, if we do that it is about engaging with an entity, so an option is an "engagement document", verification methods and services. I am not saying we do this, but someone could use this for expressing their social media accounts, things like that. "How to get in touch with and authenticate an entity".

Gabe Cohen: would make sense to call it an "identifier document". All these docs have identifiers, seems like an obvious name.

Brent Zundel: I added myself to talk a bit about the services thing. Controller document as we conceived of it came from ??? specs which were taken from the DID specs, there was a question around "where are our services", the assumption during the DID call was that there was a common document, after thinking about it I think that services should not be pulled up into controller document.

Ivan Herman: two things, what you just said, from a general POV, is the same as what I was saying in my comment on a technical POV, and I don't want to go into the details now but would also favor not to have the services. The other point is that, for you guys certain crypto things are natural, that is not true for outsiders. For me, the fact that you have a document that can combine crypto information with identifiers is a central element that an outsider understands. The crypto element is central to the whole thing, and I would like that to be reflected in the title.

Pierre-Antoine Champin: I don't like "engagement document", maybe "entity document"?

Wesley Smith: [general laughing].

Ted Thibodeau Jr.: "cryptomogriphication document".

Brian McManus: With that we're done (Joe gets the last word) =).

[msporny]

What about "interaction documents" -- they contain ways in which one can interact with an entity that is identified by the identifier in the id field?

Here's how we'd change the abstract with the new name:

An interaction document provides information that enables a software system to engage with an entity identified in the document. An interaction document contains data to aid in the interaction such as public cryptographic keys that can be used for secured communication and services that can be used to interact with software acting on behalf of the entity identified in the interaction document.

It's not perfect, but is it better than "controller document"?

[iherman]

It's not perfect, but is it better than "controller document"?

I agree with both statements :-)

But... what is the usage of that document without public crypto keys? I have the impression that most of the properties are related to "verification", the data types that we define are related to keys, etc. So the "such as" in the description seems to underplay the role of crypto for my taste.

I believe the presence of crypto keys are an essential feature of the document, and this should be reflected in the name...

[msporny]

I believe the presence of crypto keys are an essential feature of the document, and this should be reflected in the name.

It's an essential feature today, but it's not absolutely necessary for some use cases. I know this is going a bit far afield into the Social Web space, but that is one of the driving "next generation" use cases for DID Documents.

But... what is the usage of that document without public crypto keys?

You can list services, such as ActivityPub inbox, pseudonymous email address, DID Comm endpoint, or other URLs that the entity identified by the id property has listed as ways of interacting with them. For example, if I just want to drop a message to you, I could HTTP POST to one of those endpoints, authenticating myself in the process (if necessary).

[TallTed]

But... what is the usage of that document without public crypto keys?

A direct-dial phone number might be another useful and reasonable inclusion. Possibly through a location-blurring reflector like Google Voice. No crypto keys required, unless you're on some kind of secure line, which case you're probably not using GV but you might be using a No Such Agency reflector.

[decentralgabe]

I continue to like Identifier Document.

Since the main impetus (I think) was to move from just a DID Document to other types of identifier-based documents, cutting off decentralized is a simple and consistent change.

[filip26]

I'm sorry, I could not resist adding another proposal identity manifest even though I'm quite cool with controller documents :)

[iherman]

The issue was discussed in a meeting on 2024-10-09

• no resolutions were taken

View the transcript

3.4. Find a better name for the specification (issue controller-document#100)

See github issue controller-document#100.

Manu Sporny: lastly, we need to be more specific about throwing an error if people try to claim keys that are not theirs. We will raise PRs over the next week or two to get that done. That's it for the TAG review. During W3C we raised an issue to rename the specification, so that is issue 100, this is very much a bikeshedding discussion, everyone has an opinion. One thing that kind of at least came to me and I suggested it in the issue is, we have been using controller document historically because the controller field can point to the document. It's about control over public keys and control over services, but one other name we could consider is that this is also about "interacting" with an identifier or an entity identified by an identifier. There is still disagreement about which we are doing, but it's about understanding how to interact with those things, whether in a decentralized way through crypto or through services like engaging with an email address.
… One suggestion is to use the word "interaction document", it is definitely not perfect, but the question is whether it is better than "controller document".

Brent Zundel: My intended procedure for this issue is, unless a proposal is made for a new name that everyone really likes, then we are not going to change it. If we cannot find something that is a clear winner among participants, we are going to stick with what we have.

Dave Longley: +1 to brent, not worth changing without a "big winner".

Brent Zundel: It's unlikely that we will spend much group time on what a new name ought to be, if you have preferences and would like to make them known please engage on the issue. We can take a few minutes now if folks really want to voice their opinions, but without a clear winner we will make no change.

Manu Sporny: can we take a quiet poll on what people would prefer between "controller document" and "interaction document"?

Michael Jones: Controller Document.

Manu Sporny: Interaction Document.

Kevin Dean: interaction document.

Joe Andrieu: verification document.

Gabe Cohen: identifier document.

Phillip Long: identifier document.

Dave Longley: controller document (despite its imperfections... because the others don't sway me enough to change it).

Brent Zundel: not seeing clear consensus on this issue, the conversation is welcome to continue in the issue, however when everything else has been addressed to move to CR we will proceed forward with "controller document" if consensus not reached.

[jandrieu]

Seems like "identifier document" was the only new name to get more than one vote in the call.

After sitting on it, I would support that.

'Identifier Manifest' is also not bad, although I'm not a fan of 'identity manifest' given the challenges defining 'identity'.

[iherman]

I look at Example 2 in the DI document for the value of proof, and it is not clear how the term identifier document (or controller document for that matter) would characterize what is there. The properties used in proof constitute a set of data on the proof, which "identified" by a… blank node. Is that ok for an 'identifier document'? Not sure.

I am the culprit in this issue insofar as I raised the question at the F2F meeting in Anaheim. And I have to acknowledge that there is no name coming to the fore that would reflect a consensus of everyone around; so we may want to accept failure. 😞

[iherman]

As for 'document' vs. 'manifest': I would be fine with 'manifest' but, alas!, that term is tainted by the introduction of the Web Manifest Standard at W3C. If we used that term, we would be flooded by questions like "What is the difference with Web manifest?", "Can't you reuse the Web manifest", etc. (Saying this as a co-editor of a standard entitled "Publication Manifest".) I do not think we want to go there.

[filip26]

@iherman Do you mean W3C Web Application Manifest ? If yes, actually, thinking about it more, a clash leading to a discussion on how a Web Application Manifest is related to what is now called Controller Documents could be quite interesting and useful to clarify things. However, this is not the goal of this spec. 

Web Application Manifest Abstract

This specification defines a JSON-based file format that provides developers with a centralized place to put metadata associated with a web application. ...

Controller Documents Abstract

A controller document is a set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.

How would the abstract look like for a new name? Would it change, become more concrete, vague, etc?

--
A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" 🙂   ... 

[msporny]

@decentralgabe wrote:

I continue to like Identifier Document.

I'm starting to come around to this as well, I don't love it, but it feels more descriptive than Controller Document. The part of it that I don't like is "Document" and wonder if "Description" might be better?

"Identifier Descriptions v1.0" or "Identifier Description Documents v1.0"?

The document certainly contains a description of an identifier. I do get the parallel to "Decentralized Identifier Document", and for that reason wouldn't -1 "Identifier Documents v1.0"

Another possibility is "Cryptographic Identifiers v1.0"? Decentralized Identifiers are a type of Cryptographic Identifier?

[iherman]

@iherman Do you mean W3C Web Application Manifest ?

My apologies, I was not precise. Yes, that is the one I referred to.

If yes, actually, thinking about it more, a clash leading to a discussion on how a Web Application Manifest is related to what is now called Controller Documents could be quite interesting and useful to clarify things.

That discussion would easily become a time and energy sink. Issues that would become the subject of discussions are JSON-LD vs. "basic" JSON (knowing that there are experts in the WAM area that are fiercely opposed to -LD); is this document for Web Applications?; Is a VC part of a Web Application? etc.

I personally would like to avoid going there. It would derail the timeline along this document, which would drag down all VC specs.

-- A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" 🙂   ...

+1

[iherman]

Another possibility is "Cryptographic Identifiers v1.0"? Decentralized Identifiers are a type of Cryptographic Identifier?

I always emphasized my feeling that a reference to crypto should be part of the name, so that sounds better to my ears.

That being said, my comments on the example in #100 (comment) still holds. However, my comment may fall under the remark of @filip26:

A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" 🙂 ...

as an issue of "correctness"…

[dlongley]

The new (and significantly improved) introduction to the spec offered in PR #102 adds support that "controller document" isn't necessarily that bad of a name:

A [=controller document=] contains cryptographic material and service
endpoints for the purposes of verifying proofs from, and interacting
with, the [=controller=] of an identifier.

Each of the other names offered thus far have pros and cons -- and given that none of them, IMO, is overwhelmingly "better", I think we should stay the course with "controller document" and save the effort involved in changing the name and then defending it again from future changes.

EDIT: If we really are hard set on changing the name, I think this is a good combination of what I've heard here:

"Identifier Controller Document"

[iherman]

For the records, see also @David-Chadwick 's comment #102 (comment)

[filip26]

For the records, see also @David-Chadwick 's comment #102 (comment)

I like having crypto in the name, unfortunately CID collides with Content IDentifiers - e.g. Bluesky uses CIDs in production alongside with DID documents.

https://github.com/multiformats/cid

[decentralgabe]

+1 to Cryptographic Identifiers

[David-Chadwick]

Cryptographic Identifiers would also work in the opening sentence, viz:

A Cryptographic Identifiers (CI) document contains cryptographic material and service endpoints for the purposes of verifying proofs from, and interacting with, the controller of an identifier."

Is the abbreviation CI acceptable?

[dlongley]

The name "Cryptographic Identifiers" still seems suboptimal to me -- as the identifiers aren't cryptographic and one of these documents may even contain no cryptographic material (e.g., services only).

[decentralgabe]

@dlongley you're correct, but why should that be allowed (I know why historically)? I can put a service in a document today, I don't need a spec for it. The introduction of cryptographic material is what makes these documents meaningful.

[dlongley]

@decentralgabe,

Another case is a document with a verification method that doesn't use cryptography (or may not express it publicly).

I disagree that the only value (or primary value) is in expressing cryptographic material. From my perspective, the value is in having a standard way to express information for verifying proofs created by the controller of an identifier and in finding ways to interact with the controller of an identifier. This, to me, puts an emphasis on the identifier and its controller, not elsewhere.

[filip26]

What about Controllable Identifiers ? i.e. identifiers that are under control via crypto, services, etc.

[decentralgabe]

I disagree that the only value (or primary value) is in expressing cryptographic material. From my perspective, the value is in having a standard way to express information for verifying proofs created by the controller of an identifier and in finding ways to interact with the controller of an identifier. This, to me, puts an emphasis on the identifier and its controller, not elsewhere.

We agree here—I missed some nuance. Verifying proofs requires cryptographic material. No matter what, interacting with a controller document requires some cryptographic material (I believe it should, anyway). Identification, control, and verifiability is the crux of the issue.

[iherman]

The issue was discussed in a meeting on 2024-10-16

• no resolutions were taken

View the transcript

4.4. Find a better name for the specification (issue controller-document#100)

See github issue controller-document#100.

Manu Sporny: need to find a better name for the specification. We could run a rank poll on various naming options.
… this usually provides good results.

David Chadwick: +1 to a poll for a better name.

Ivan Herman: group can decide what sort of poll to use.

Manu Sporny: there is a web site that does poll rankings for you.
… this shows what the ranking is, and the group can then decide to accept this or not.

Gabe Cohen: I will follow up with Brent after this call to create the poll.

Manu Sporny: please make sure you have included all the name choices.

[steatcal]

I see it's too late, but wanted to add a viewpoint form a less involved person's perspective and submit:

Identifier's Authentic Metadata Graph.

To shift the focus to the purpose of the Controller Document. In my view, I most value the properties that allow an RP/verifier to establish confidence about the authenticity of a claim to the identifier --over time-- and an asserted way to initiate communication with the claimant. It forms the basis by which an RP/verifier can establish confidence about the authenticity of the claimant in online interactions or authenticity and temper-evidence in data the claimant choses to originate (VC and beyond).

[msporny]

@steatcal wrote:

I see it's too late

It's not too late, we can always provide this other choice as a: "Here's all the data we have, and X seems to be in the lead... Stephan provided another option after the poll started, is there stronger support for that choice vs. the ones we have data for?" <-- that's typically what we do when we make the final decision (2 weeks from now).

[TallTed]

open until our next WG call

@msporny — Could you put an actual closing date on this, optimally also on the poll page? (and change the text quoted above to reference the VCWG, which I think is the WG controlling (cough) this document, maybe with a link to the WG calendar or even the specific meeting event?

[msporny]

Closing date is next Wednesday after the VCWG call.

I can't put it on the polling page w/o closing the poll (they don't want you to change instructions/dates/etc. mid-way through the poll, IIRC).

[TallTed]

So, 2024-11-13T12:00:00-0500

[iherman]

The issue was discussed in a meeting on 2024-11-13

• no resolutions were taken

View the transcript

4.2. Find a better name for the specification (issue controller-document#100)

See github issue controller-document#100.

Manu Sporny: we ran a poll to rename the controller document.
… we got good turn out.
… I wish I could share my screen...
… what we got as a result was fairly clear preference.
… 129 for Identifier Document.
… 113 for Controller Document.
… 96 for Cryptographic Identifier Document.
… and more beyond.
… I'll collect the results and announce them later.
… this was ranked choice voting.
… mainly to show a preference in the group.
… so, that's the data.
… we said we'd run the poll and use that as input to a proposal.
… brent it's up to you if you want to make the proposal now or later.

Brent Zundel: with chair hat on, I don't think 129 vs. 113 is a strong preference...seems like a slight preference.
… we can make a proposal, but if we were to do a poll on those two options what would emerge.

David Chadwick: looking at those numbers and you take 129 and 96 together, there may be evidence of a preference for Identifier being in the name.

Manu Sporny: We also had someone suggest Identifier's Authentic Metadata Graph.

Brent Zundel: not sure that's the right interpretation.

Ivan Herman: I agree with brent...as the one who brought this up to begin with...
… let's close this without any action.
… because we didn't find a clear preference.

Joe Andrieu: I sadly need to disagree.
… we're not going to get more information by running another poll.
… this is the conversation where we'll have the opportunity to discuss this.
… and I think given we didn't get to discuss the name last time, we should follow the poll.

Brent Zundel: there was a good deal of conversation around the name "Controller Document".
… mostly on an issue, but also on call.

Joe Andrieu: when we first came up with the name, it was a "let's use this for now".
… I don't think it has merit to dismiss the poll.

David Chadwick: +1 JoeAndrieu.

Brent Zundel: I don't think that's what's happening.

Manu Sporny: I agree with JoeAndrieu as one of the people who named it initially, we did select it out of thin air...mostly.
… I'm not a fan of "Controller Document".
… the way ranked choice works isn't about the margin.
… anything that comes out on top, is the clear preference, even if the margin is slim.
… we sadly don't know who all voted.
… I'm willing to make the change across the documents.
… I think it was Gabe who made the "Identifier Document" which shows some of it's lineage to "Decentralized Identifier Document".
… the poll does show a preference...however small.
… could we run a poll for the top two?
… and if there's still no consensus, we stay the course?

Brent Zundel: before going to the queue, let me attempt to express my deeply felt apathy about this change.
… I don't care.
… we could call it the Poopy Pants Thingy Document.

Gabe Cohen: I also do not care. Even as the person who proposed "Identifier Document".

Proposed resolution: Rename Controller Document to Identifier Document. (Brent Zundel)

Manu Sporny: +1.

Gabe Cohen: I think there are better things to discuss.

Joe Andrieu: +1.

Brent Zundel: +0.

Gabe Cohen: +1.

Benjamin Young: +0.

David Chadwick: +1.

Dave Longley: -1 but would support Controllable Identifier Document.

Ivan Herman: +1.

Jennie Meier: +1.

Ted Thibodeau Jr.: -0.7.

Ted Thibodeau Jr.: the problem with "identifier document" is that it holds both identifier and crypto material.
… the crypto is not identifiers as currently defined.
… if we want the name of this thing to communicate to people who find these, I think "identifier document" is the wrong name for it.

Dave Longley: similar concerns from me.
… there are many documents you could describe as "identifier documents".
… these documents, however, are about controlling identifiers.
… so we'd sadly be missing that key thing.
… we'd be missing something if that's the only words in the name.

David Chadwick: I wanted to propose something different.
… is there anyone strongly against "Identifier Document"...that's how the poll went anyway.

Brent Zundel: we sadly do not have consensus to change it.

Joe Andrieu: I want to make the case that this document is about one identifier.
… it then provides things related to that identifier.

Dave Longley: i don't care enough to block it.

David Chadwick: The voting shows a strong consensus to change the name. 5 for, 2 dont care, 1.7 against.

Dave Longley: -0.

Ted Thibodeau Jr.: "Identifier Interaction Methods [Document]"?

Dave Longley: would we get fully support for "Controllable Identifier Document"?

Dave Longley: full*.

Brent Zundel: bigbluehat: I also don't care. It may be about one identifier, but the document has more than than. I think Identifier Document is painfully broad. Controllable Identifier Document if kind of okay.

Manu Sporny: Controllable Identifier Document polled at 79, FWIW.

Proposed resolution: Rename Controller Document to Controllable Identifier Document. (Brent Zundel)

Manu Sporny: -1.

Dave Longley: +1.

Gabe Cohen: +0.

Benjamin Young: +0.

Joe Andrieu: +1.

Ivan Herman: 0.

Ted Thibodeau Jr.: -0.9.

David Chadwick: With dlongley's change of vote we have 5 for, 3 dont care, 0.7 against.

Brent Zundel: the W3C process works on hard consensus.
… so people not liking something, means we keep working on finding what works for everyone.

Manu Sporny: k. everyone's sad.
… let's move on.
… it would've been easier if there was strong support for something.
… I would have loved to change the name.
… but it's not worth fighting for.
… let this be a lesson to everyone to not arbitrarily name specs in the future.

Brent Zundel: shoulda named it poopy pants.

Joe Andrieu: clearly you do care brent.

Ivan Herman: so we should close this issue.

Brent Zundel: thanks everyone, that was the meeting.
… let's talk again next week.

---

[iherman]

Closing per discussion on the last WG call.

[msporny]

Here are the results from the poll (for posterity):

... and the text-based breakdown:

OpaVote Election Results (https://opavote.com/)

A Poll to Rename the Controller Documents Specification

There are 12 candidates competing for 1 seats. The number of voters is 21 and
there were 21 valid votes and 0 empty votes.

Method Options:
    Ballot Completion -- Off

Counting votes using Borda Count.

                          Candidate | Count
===========================================
               Controller Documents |   113
               Identifier Documents |   129
    Identifier Controller Documents |    72
          Cryptographic Identifiers |    57
 Cryptographic Identifier Documents |    96
           Controllable Identifiers |    59
  Controllable Identifier Documents |    79
                 Identity Manifests |    41
               Identifier Manifests |    67
              Interaction Documents |    64
             Verification Documents |    52
Cryptographic Information Documents |    51
                          Exhausted |   506

Borda count totals.

Winner is Identifier Documents.

[sloops77]

@msporny can you easily run a rank choice vote so we only have two options left?

[msporny]

@msporny can you easily run a rank choice vote so we only have two options left?

I could re-tally as a variation of RCV, though Borda count was the more appropriate voting scheme for this particular choice:

https://opavote.com/methods/ranked-choice-voting

If we did many of the variations of RCV, the remaining two would be Identifier Documents and Controller Documents, w/ Identifier Documents winning in most (but not all) cases.

That said, there was weak support to change the name during the telecon with multiple parties claiming that they didn't care about the outcome. It became obvious that we couldn't get to strong consensus on the name change, so we closed the issue and moved on.

[David-Chadwick]

I dispute the fact that there was weak support to change the name. If you read the minutes there was overwhelming support for a name change, with only 0.7 against. With @dlongley's change to 0, we have 5 for, 3 dont care, 0.7 against

[brentzundel]

I dispute the fact that there was weak support to change the name. If you read the minutes there was overwhelming support for a name change, with only 0.7 against. With @dlongley's change to 0, we have 5 for, 3 dont care, 0.7 against

There was never a claim of weak support to change the name. There is very clearly strong support to change the name. Unfortunately, W3C process calls for more than strong support. It calls for unanimity where possible (everyone in favor), where that is not possible a chair can declare consensus as long as there aren't too many abstentions and there aren't any objectors. -0.7 isn't much, but it is still an objection and therefore we did not have consensus.

However, in light of the strong desire of some members of the group to continue working toward consensus on this issue, I will re-open it.

[selfissued]

I believe that changing the name would cause more confusion than benefit. I believe that @brentzundel already made the best call available to us.

[David-Chadwick]

@msporny "That said, there was weak support to change the name during the telecon"
@brentzundel "There was never a claim of weak support to change the name. "
Perhaps you guys could reconcile your opposing views?

[msporny]

@David-Chadwick

Perhaps you guys could reconcile your opposing views?

I'm conflicted about the resolution, and my view isn't necessarily in opposition to @brentzundel's call -- I think there was a judgement call that had to be made and the Chair made it. I accepted it and moved on; other's didn't. :)

I can see both sides of the argument. It is true that there wasn't strong consensus. It is also true that there weren't sustained objections that would lead to a formal objection. I both agree and disagree with both @brentzundel and @jandrieu :) -- it was a tough call. The resolution would have passed at IETF, it was not strong enough to pass at W3C.

But that's neither here nor there, the topic has been re-opened and will be discussed until we can move forward without a formal objection, or until it's clear that we can't do that.

When we open up the discussion again, it would be good to understand what we'd need to see in the data / proposal to know if the proposal passed or not (as horribly meta as that is).

There is one item that Dave Longley mentioned around "identifier document" being a mistake that we didn't have the time to discuss (could be considered "new information"). At the time, I didn't understand his point and that might help push other people one way or the other on their decision.

My biggest concern at this point is the extra time this is going to add to get to CR and beyond, as I'm sure that concern is shared by a fair number of people in the WG.

[jandrieu]

A few points of correction.

First, the "Controller Document" as a name never had WG consensus. The prior consensus was to change the name if we found a better one. In particular, rather than bikeshed the name at the time we decided to create a separate spec from DID Documents, we deferred naming it until something better emerged.

When that time came around, we held a poll that showed a clear preference for "Identifier Document". IMO, that on its own should have been enough to say "Hey, we found a name that, incorporating all the preferences from everyone who voted, is mathematically preferred to Controller Document. Let's use that."

That should have been the chair's interpretation. For whatever reason, Brent did not interpret that poll that way and he ignored the corrections made on the call by multiple parties about the meaning of the results.

Second, the polls as constituted were improperly formed. See the process document for the requirements for using a poll to find consensus. One practical effect is that Manu and Dave only get to vote as a single member of the W3C. This likely matters more for the polls done on the call, but only because I have no visibility into how Manu & Dave voted on the ranked-choice poll.

Third, the questions put before the group were never designed to find the option with the weakest objections, as required by process. IMO, the questions were designed to shut down conversation and retain the preference by Brent to simply keep the Controller Document name.

Fourth, when the polls in fact showed consensus, Brent simply proclaimed they didn't.

Fifth, it is incorrect that "W3C process calls for more than strong support. It calls for unanimity where possible (everyone in favor), where that is not possible a chair can declare consensus as long as there aren't too many abstentions".

I don't know where this notion comes from but it is not consistent with the Process as written nor with community practice.

First, the facts of the initial poll in the meeting asking if people liked "Identifier Document": there were 6 +1s, 2 abstentions, and one partial objection of -.7.

Here's what the Process says:

Consensus:
A substantial number of individuals in the set support the decision and there is no sustained objection from anybody in the set. Individuals in the set may abstain. Abstention is either an explicit expression of no opinion or silence by an individual in the set.

The poll votes seem to demonstrated meeting that standard:

• A substantial number of individuals in the set support the decision
• There is no sustained objections from anybody in the set. .7 is not a sustained objection, it is in fact, an attenuated objection saying that they aren't a FULL -1 but rather have some concerns they'd like addressed.

From the process:

Disagreement with a proposed decision, however, does not always rise to the level of sustained objection, as individuals could be willing to accept a decision while expressing disagreement.

@TallTed did exactly this by expressing -.7, which has long been accepted in our conversations as indicating disagreement but a willingness to accept.

Also from the Process

Where unanimity is not possible, a group should strive to make consensus decisions where there is significant support and few abstentions.
The poll also met this standard.

• Significant support (+6)
• Few abstentions (2)

Given the facts and these two quotes from the Process, it is incredible to me that anyone can look at those poll results and conclude that consensus was not achieved. It beggars the imagination that we would have such a blatant misrepresentation of the evident conclusion.

Further, it has been the practice within our community, meaning both the VCWG and the DIDWG, to treat a single objector as insufficient to hold up a group decision. As recently as TPAC that rule was applied to objections from Mike Jones and I have faced that dismissal of my objections many times using that same rationale.

Most typically, in these kinds of situations, the Chairs have historically asked those who vote in any negative to express their concern and, often, to clarify if their concern is likely to result in a formal objection. Usually, despite the risk of a formal objection a single voice has consistently been deemed insufficient to declare failed consensus. Brent did not do that in this case. Instead of judging this situation in a manner consistent with past practices, Brent made up his own rule, asserting it as fact.

If the rule is that "Joe (and Mike) can't stop consensus when they are the only objector but TallTed can, even when he actively expresses a willingness to accept the decision", then we are dealing in a world of caprice, favoritism, and autocracy instead of the world of collaboration and consensus that the process demands.

I don't see how any reading of the facts and the associated sections of the process can credibly lead to a conclusion that there was not consensus to set the new name of the former DID Document to "Identifier Document".

For the record, I also find Brent's response to @David-Chadwick and myself on the call this week to be a violation of the CEPC. I have shared my concerns with @iherman as staff contact. Although I don't expect there to be any formal action, I want to go on record saying that interrupting and raising the voice to shut down members who are expressing their legitimate concerns is both unprofessional, disrespectful, and dismissive.

Both David and I calmly raised our objections in the first meeting after the meeting in which Brent misinterpreted consensus. We did so without interrupting the existing flow of the meeting waiting until the agenda was nearly finished to introduce our concerns. What happened in response was not congruent with the values and commitments of the W3C.

My own response to Brent's action wasn't the best either. I apologize for responding in kind. It's easy to respond with a raised voice when someone is yelling at you to "Tell me what you want me to do".

I appreciate that Brent has now agreed to re-open the issue. He should have graciously done so as soon as David expressed his sustained objection, instead of raising his voice and telling David we aren't going to discuss it.

[dlongley]

I think it's worth mentioning that when the ranked choice poll was run it was made clear that it would be "just an input" to the decision process. I thought at the time that even though this was said several times that it may have been better to more strongly highlight that whatever comes out of that poll would not be the only signal or the fundamental basis for whatever decision was made about the name. That people seem to be so strongly relying on that data point demonstrates that I erred in not asking this to be even better highlighted.

Fourth, when the polls in fact showed consensus, Brent simply proclaimed they didn't.

If we're referring to the ranked choice poll, I did not even select "Identifier Document" as an option, because I did not want it at all and I would prefer to keep the name "Controller Document" over "Identifier Document". I intentionally wanted it to receive no points from me whatsoever. Perhaps there should have been an option to give options negative points. If there had been, perhaps the result would not have shown any preference for it.

So that poll in particular did not indicate that there was W3C-style-consensus to change the name to "Identifier Document", rather, it showed that in aggregate, the electorate preferred that name over any others. But this isn't W3C-style-consensus.

If you're referring to the polls taken over IRC during the WG calls, my original position was to be against "Identifier Document", but like I said, if there's no other resistance to the name in the group, I would not block changing it -- but I maintain it's not a good new name (and I believe it to be "worse"). I understood this to have been sensibly read by the chair that at least one person would be fairly unhappy with changing the name. There were one or two others who expressed similar misgivings, which is, to me, not a clear W3C-style-consensus to take an action. However, this implies a default preference for "staying the course", which can also be argued for/against.

Therefore, I do get the argument that "Controller Document should not be taken as the default name" so "changing it should not require anything more than no one seeking to block it". I don't know that that is how everyone else feels about the situation -- even if "controller document" was originally seen as a temporary name. It's true that names get sticky over time and so people may also have evolved thoughts on it over time.

Anyway -- I think there were and are a number of competing thoughts and feelings on the issue as opposed to it being a more obvious case of what should be done going forward. And, again, I'm happy to go along with the group, but do want people to know that I think the name would be worse off without the title indicating somewhere that this spec is about "Controllable" or "Controlled" identifiers. To me, that's what's key, not that there's some document on the Web with an identifier in it. I consider that to be true of oodles of documents on the Web and so the name "Identifier Document" is hardly a meaningful differentiator.

[iherman]

Trying to move forward. I would propose to

• Stop the discussion on what happened, who was right or wrong, and what are the possible or, rather, supposed motivations.
• In the future, we should all avoid giving a "fraction vote" when it comes to formal proposals and corresponding votes (straw votes are different). This discussion shows that this may lead to different interpretations and result in further discussions. The answer to a proposal should be +1, 0, or -1. Nothing else.
• May be unnecessary to say, but it is worth emphasizing: if we decide on a renaming, it must be done before or during the CR submission of the specification. At this point, operationally, the simplest is probably to do it with the CR submission, it may simplify the administration.

[iherman]

I think the name would be worse off without the title indicating somewhere that this spec is about "Controllable" or "Controlled" identifiers. To me, that's what's key, not that there's some document on the Web with an identifier in it.

Does this corresponds to the "Controllable Identifier Document" alternative on the list? Looking at your arguments, this may be an acceptable compromise...

[msporny]

the poll was input, not a final vote

Yes, agreed, that is definitely what we said it would be. Some of the reasons we don't let Opavote polls be the same as the call for consensus is that 1) Opavote polls don't measure how much people do not like a proposal (they don't measure -1s), and 2) we don't know if people packed the votes (since voting is done anonymously). IOW, we presume good faith in the poll but don't entirely trust it and leave the data gathering on -1s (and alternatives) until we're discussing in the WG. Therefore, the Opavote poll is never an equivalent to a W3C call for consensus.

That said, we didn't do all the things we usually do w/ -1s, which is to ask if Ted's was a standing objection that would result in a formal objection... or try to figure out why more than half of the WG in attendance didn't participate in the vote (ambivalence, confusion, or something else?).

I was also confused by the following:

• The way @dlongley voted -- I knew he didn't like it, but didn't think he didn't like it that deeply (and that was concerning).
• The way @BigBlueHat voted -- didn't know he was that ambivalent about it.
• Ted's vote, but I couldn't see that he had a workable alternative and didn't read his -0.7 as a standing objection -- and don't agree with @iherman that fractional votes aren't useful -- they are, even if they can be misinterpreted (which is why we usually ask people to explain them) :)

... and yes, DB having 3 completely different votes on the matter didn't help either for at least two reasons: 1) the average of our vote collapsed to 0, and 2) one W3C Member/Expert === 1 vote (we shouldn't have our multiple poll votes counted in something that contentious)... which is why I read the first poll as @brentzundel's 4/5 for, 2/1 against, and a whopping 9 participants not even bothering to vote... that, to me, was a clear signal of no strong consensus (which is why I agreed with the judgement call that @brentzundel made given the limited time we had left in the call).

Does this corresponds to the "Controllable Identifier Document" alternative on the list

FWIW, I was a -1 on that, but mostly because it didn't poll highly and I was concerned that we were going with something that polled fairly middle-of-the-field among "the electorate", some of whom (I imagine, I have no idea who voted) were not there to express their opinion on that day.

All that said, I'd be a +1 for "Controllable Identifier Document" if we were to poll again. I do also think we should poll for keeping the "Controller Document" name as we never actually did a CfC on that name and I've seen a number of times where something in the specification, which was not discussed, is asserted as "well, it's in the spec, we shouldn't change it." (which is a bad precedent to set if there was never a resolution and the decision is clearly contentious).

[msporny]

As Ivan said, let's try to focus on the future here (though, it is important to understand why we ended up here... which we can do in this thread). I suggest the next call should explore these proposals:

PROPOSAL: Keep the "Controller Documents" title, as it is the option with the strongest consensus.

PROPOSAL: Change the title of the "Controller Documents" to "Identifier Documents"

PROPOSAL: Change the title of the "Controller Documents" to "Controllable Identifier Documents"

Folks should feel free to float other proposals in this thread.

[selfissued]

PROPOSAL: Close this issue with no further action on the renaming topic.

[msporny]

For the sake of poll complete-ness (why some were arguing that the poll clearly showed a winner), I went ahead and did a re-count using Instant Run Off voting instead of Borda count. Here are the results.

[msporny]

Another re-count using Single Transferrable Vote (Scottish rules, which tend to be the simplest ones -- I ran all the others and the outcome is more or less the same, except for Massachusetts STV, which resulted in no winners):

[selfissued]

These polls show that no option had over 20-some percent support. Which is an argument to leave things as they are.

[msporny]

These polls show that no option had over 20-some percent support. Which is an argument to leave things as they are.

No, that's definitely not an argument to leave things as they are. Per that logic, we'd never elect new leaders in government since, among the populace, no candidate would ever get above more than a fraction of the vote of all running candidates -- we'd just keep the status quo (which was never agreed to in the first place by the populace -- that model is closer to a monarchy or an autocracy). That is the wrong way to interpret the results of these polls.

The polls also don't measure negative sentiment (missing data... they don't count -1s), only ranked approval. These are broad preference polls with Borda, IRV, and STV tallys that are designed, specifically, to make a choice based on the most approvals across all of the choices.

[msporny]

There is also a mistake that was made in the poll design that caused a statistically significant tally issue between "Cryptographic Identifiers", "Cryptographic Identifier Documents", "Controllable Identifiers" and "Controllable Identifier Documents" -- we shouldn't have split the choices in that way as we didn't split the choices in the same way for the other selections. What we were trying to decide was: "X Documents", where the decision should've been on X. That said, I don't think we need to re-poll... we got data, and the final decision rests with the WG and a resolution that ideally is consensus with unamity, or at least a resolution that draws the least number of objections (with no formal objections, not that I think you can formally object on the title of a document unless there was a process violation that occurred to get there -- the formal objection would be on the process violation).

[David-Chadwick]

@msporny A big thankyou for all your efforts in this.