Summary

  • ICANN said on 14 September that ICANN87 registration does not automatically create a Sched account. The meeting will run in Bali and online from 17 to 22 October 2026.
  • Registration, a Sched login, virtual-room entry, actual presence, a delivered intervention and a published formal record answer different questions. No one count proves the other five, much less a mandate.
  • A privacy-preserving participation receipt should publish state definitions, denominators and aggregate transitions while keeping cross-session personal tracking off by default.

One meeting begins with two accounts

The most consequential sentence in ICANN's schedule announcement is not a session title. It is an account warning. Registration for ICANN87, ICANN says, does not automatically create a user account on Sched. A returning participant must use an existing Sched account; a newcomer must sign up for one.

This is ordinary event administration, not evidence of a defect. It is also a clean demonstration of how easily hybrid participation is compressed into the wrong noun. A person can register for the meeting without opening Sched. A Sched user can save a session without joining it. A Zoom client can enter a room without remaining for the discussion. Someone present can listen without speaking. A speaker can enter a transcript without possessing authority to bind the organisation named in an affiliation field.

ICANN87 is scheduled for 17–22 October at the Bali International Convention Centre, with virtual participation in WITA, UTC+8. Advance in-person registration closes on 14 October, and there will be no on-site registration. The meeting page adds another distinct checkpoint: collecting an in-person badge requires a registration-confirmation QR code and government-issued photo ID. That proves the person crossed an access boundary. It does not prove what happened in any session.

Six states, six receipts

The first state is meeting registration. It records a declared intention and acceptance of the relevant terms. It may unlock the schedule or badge process. It cannot show that the registrant attended.

The second is Sched activity. A login proves access to the programme under a separate account; a personal schedule records a planning choice. Neither is a turnstile. Saving three sessions is not attending three sessions.

The third is remote-room entry. ICANN says public sessions use Zoom links published on the schedule, generally 24 hours before the session. A connection event can establish that a client joined at a time. It cannot establish that a person was continuously present, attentive or authorized to speak for anyone else.

The fourth is actual presence. Online, this needs a defined duration window and a disclosed treatment of reconnects. In a physical room, it needs a stated counting method. A mid-session headcount is a snapshot, not a day pass. Presence remains useful evidence; it is not agreement.

The fifth is a delivered intervention. Clicking “raise hand” enters a queue. It does not prove the floor was granted. ICANN's participation guidance asks a remote questioner to state a name and affiliation for the record. That makes the contribution traceable, but affiliation supplies context, not a power of attorney.

The sixth is the formal record. A session recording, a published transcript or another designated record can show what was said. ICANN warns that live transcription may contain inaccuracies and is not an official record; formal transcripts follow later. Even the final transcript proves speech, not consensus, representation or a decision.

ICANN86 already shows why the denominator matters

ICANN's own ICANN86 report provides a useful comparator. It listed 1,939 attendees: 1,374 in person and 565 “registered to join us virtually.” In a separate section, it reported 1,307 attendees logged into Sched and 1,025 personal schedules created. Its in-person session tables were based on manual mid-session headcounts of people physically in the room.

These figures do not contradict one another. They measure different objects. The virtual number begins at registration; the Sched numbers concern programme activity; the session count is a physical snapshot. Each can help run a meeting. Trouble begins only when the label or later argument loses the denominator and turns all four into interchangeable proof of “participation.”

A large top-of-funnel number is not fraudulent because it is broad. It becomes misleading when readers cannot tell whether it means a form submitted, an account opened, a room entered or a human contribution made. The remedy is not one supposedly perfect number. It is a visible chain of narrower ones.

A receipt without a surveillance dossier

A staged participation receipt should start with public metadata: stable meeting and session identifiers, the time zone, the observation window and the definition of each event. It should then publish aggregate transitions—registered to schedule-active, schedule-active to room-entry, room-entry to presence—together with denominators, exclusions, no-show treatment and known collection gaps.

Personal linkage should be the exception. Systems can use rotating, salted opaque tokens so an event can be counted without constructing a permanent cross-session profile. Small groups should be protected by disclosure thresholds. If a participant needs proof of attendance, a user-held or privately retrievable receipt is safer than a public named ledger.

Speech requires its own public trail because the contribution itself is public. The record can distinguish queue entry from actual delivery, retain the name and stated affiliation where ICANN's process calls for them, and link the later recording and formal transcript. A correction time and version should remain visible. None of these fields should be interpreted as evidence that the speaker was authorized to bind the named employer, constituency, government or community.

The principle is simple: collect enough to audit the claim being made, but not enough to invent a larger claim about the person.

Sources