appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-05-06 drafted

draft-ietf-vcon-overview — vCon Overview

draft-ietf-vcon-overview (McCarthy-Howe) is the working group’s informational counterpart to the core specification — the document that explains what vCons are, what problem they solve, and how the high-level design fits a handful of illustrative use cases. Thomas McCarthy-Howe (Strolid) is the sole author. Currently draft-ietf-vcon-overview-01 (published 2 March 2026, expires 3 September 2026). Informational. Active working group document. I co-chair the vCon working group with Brian Rosen.

The conceptual framing for vCons across this site lives on the vCon topic page; the core spec page covers what’s specific to the JSON schema. This page covers what’s specific to the overview document — the use cases, the design rationale, and the framing that the working group chose for its informational on-ramp.

What the overview document does

The overview is deliberately not the place to read the schema — it’s the place to read what a vCon is for. McCarthy-Howe sets the analogy early: a vCon is to a real-time conversation what a vCard is to a contact card. The four major content categories (parties, dialog, analysis, attachments) and three forms (unsigned, signed, encrypted) are introduced descriptively rather than normatively, with the normative schema language living in the core.

Three illustrative use cases anchor the rest of the document:

  • Contact center, where customer interactions span voice, chat, email, SMS, and video, often with handoffs between agents and channels — vCons unify what’s currently fragmented across proprietary recording and metadata systems.
  • Healthcare messaging, where HIPAA-grade privacy and consent are first-class requirements and conversation records need to integrate with EHR systems while still enforcing data minimization.
  • ECRIT (Emergency Context Resolution with Internet Technologies), where multi-agency coordination, location data, and tamper-evident record-keeping all need to be present in real time.

The use cases are illustrative, not exhaustive. They were chosen because they exercise different parts of the design surface — privacy, consent, multi-modal dialog, real-time vs post-call construction, multi-domain handoff — and because each is a domain where existing data-handling fragmentation imposes a real cost.

Why JSON

The overview is the place where the binding choice gets explained. JSON is the lingua franca of modern application software, and most of the network and analysis tooling that will produce or consume vCons (SIP user agents, SMTP servers, transcription services, NLU pipelines) already speaks JSON. The overview leaves the door open — CBOR and CDDL bindings are noted as future work for other documents — but takes the position that the initial format binding has to be the one that minimizes integration friction.

Privacy framing

The overview gives more space to privacy than the core does, which is appropriate given its informational role. The parties section is described as the locus of GDPR-significant personal data, and the document introduces the privacy-vs-utility framing that runs through the working group’s design choices. Data minimization, consent validation, integrity protection, and the cross-domain lifecycle (a vCon being signed when it leaves a trust boundary, then amended on the receiving side) all get their place. Redaction is described as the heart of data minimization, and amendment is described as the mechanism that keeps the chain of custody verifiable as a vCon evolves across domains.

Lifecycle and amendment

Section 3.8 of the overview is the most useful for implementers thinking about how a vCon flows in practice. A vCon may start unsigned with only metadata, accumulate dialog and analysis as the conversation proceeds, get signed when exported, then be amended further by the receiving domain (which produces a new, signed amended vCon containing a deep copy of the prior version plus its additions). The pattern supports the realistic case where a communications platform, an analysis service, and a business-intelligence platform each contribute different parts of the record, and each wants its contributions cryptographically attestable.

Status

Currently draft-ietf-vcon-overview-01, published 2 March 2026, expires 3 September 2026. Active working group document, Informational. WG state is WG Document and IESG state is I-D Exists. The overview is expected to progress alongside the core — the two are companions, and bringing the core to publication without the overview would leave the on-ramp document missing.