Concept, help wanted — a live meeting check needs a challenge protocol and meeting integration.
The intended experience is a participant badge answering “Is this participant connected to me?” TrustGraph already provides signed content, membership status and own-node trust queries. Those primitives alone do not establish a live participant's identity.
What you can use today
- Signed content binds text to a certified device key.
- A fresh certificate status check reports the device's current lifecycle status.
- A locally verified path checks the recipient's connection policy against a persona.
What the integration still needs
A proposed flow would have the verifier issue a fresh challenge, the participant sign a response, and the verifier check the response before checking membership and reachability. This is a design sketch, not an existing TrustGraph wire protocol.
The missing specification must define canonical challenge bytes, verifier-generated nonces, expiry, replay handling, the intended verifier and the meeting session. A Meet or Zoom integration also needs to bind that exchange to the participant displayed in its interface. Relaying a response between participants or sessions must be considered when defining what the badge means.
Does not establish
Signed text alone does not establish signing time, current key possession by the displayed participant, the origin of speech or a connection between a face and a persona. Even fresh key-possession evidence does not automatically establish that the visible participant controls the key. Do not present this concept as an available meeting identity check.Help define the next step
We are interested in meeting-client partners who can help specify challenge delivery, session binding and clear participant-facing outcomes. Start by reaching out. Early-access work uses staging after we allowlist the app origin; the SDK's public package is coming soon.
For asynchronous evidence that is buildable now, use signed messages.