vCon — conversation containers and provenance

A vCon — “virtual conversation” — is a container for the record of a conversation: the voice or video recording, the transcript, the messages, the participants and how their identities were verified, the analysis derived from it, and the consent and provenance that govern how it may be used, all bound together as a single signed, machine-readable object. Where STIR provides cryptographic provenance for the call setup — proof of who placed the call — vCon provides cryptographic provenance for the conversation itself. The two are structurally complementary: one authenticates the channel opening, the other travels with what was said through it.

I co-chair the IETF vCon working group with Brian Rosen, and I regard this as one of the genuinely consequential ongoing developments in the trust-framework space. Three forces converged to make a standard container necessary: near-universal call and meeting recording, tightening and fragmenting consent regulation, and the arrival of AI systems that both consume conversations (as training and inference input) and generate them (as agents). Each of those needs a common, signed, interoperable way to say what this conversation was, who was in it, and what may be done with it. vCon is the format built to carry that.

The data model

At its core a vCon is a JSON object built around four arrays, with metadata wrapped around them. The core specification (edited by Daniel Petrie, currently a working-group draft heading toward Last Call) defines the schema in full; the shape is worth knowing here because it explains what the format can and cannot promise.

The four arrays are parties, dialog, analysis, and attachments. Parties carries the identity of each participant — telephone and SIP URIs, email addresses, names, decentralized identifiers, and, notably, PASSporTs, alongside a validation field that records how an identity was verified without exposing the verification material itself. Dialog carries the exchange itself — recordings, text, transfer events, or markers for calls that never completed. Analysis carries what was derived from the dialog: transcripts, translations, sentiment, summaries. Attachments carries related documents. Around these sit a globally unique uuid, creation and update timestamps, an optional subject, and an extension mechanism (extensions and critical) that lets the format grow — contact-center, provenance, and lifecycle extensions all hang off it — while telling a consumer which extensions it must understand to process the object safely.

That the identity of a party can be a PASSporT is the quiet hinge between this format and the rest of the library: the same signed assertion that authenticates a caller in STIR can be carried inside the conversation record as first-class evidence of who was present.

Three forms, and crossing trust boundaries

A vCon exists in one of three forms, and the progression is what lets it move safely between parties. An unsigned vCon is a working object, still being assembled. A signed vCon (JWS) is sealed and tamper-evident — its integrity and origin can be checked by anyone who receives it. An encrypted vCon (JWE) wraps the signed form so that only intended recipients can read it. Because a conversation record is often sensitive and frequently changes hands — from the platform that captured it to the enterprise that owns it to the analytics or compliance system that processes it — the ability to hand off an object that is both confidential in transit and verifiable on arrival is the property that makes vCon usable across organizational boundaries rather than only inside one system.

Consent and provenance

The part of vCon that makes it more than a file format is what it carries about permission and history. A conversation record is subject to a thickening, fragmenting body of consent regulation — recording consent, purpose limitation, retention limits, the right to deletion — that varies by jurisdiction and by the moment consent was given. Binding that information into the container, cryptographically and alongside the content it governs, is what lets the record answer questions a bare recording cannot: on what basis was this captured, for what purpose, and what may now be done with it. The privacy primer is the working group’s guidance for developers navigating exactly this.

Provenance runs alongside consent. As vCons are created, redacted, appended to, analyzed, and passed between systems, the format is designed so that the history of what happened to a conversation record can travel with it and be verified rather than asserted. This is the same transparency-and-provenance instinct that appears elsewhere in the library — append-only records of who did what, checkable after the fact — applied to the lifecycle of a conversation. It is also where several extension efforts are active, carrying provenance and lifecycle mechanics (including transparency approaches borrowed from the supply-chain world) into the format.

Relationship to STIR and the trust framework

vCon and STIR occupy adjacent layers of the same problem. STIR authenticates the setup of a call — the assertion that the calling party is who the number says. vCon authenticates the resulting conversation — what was said, by whom, under what consent. Because a vCon party can carry a PASSporT, a STIR assertion made at call time can be preserved inside the conversation record as durable evidence, rather than evaporating once the call connects.

The connection extends to the domain-trust and VESPER work: the same certificate and provenance machinery that anchors caller identity can anchor the identities and attestations inside a conversation container. Seen from the digital-identity hub, vCon is the provenance layer for conversations specifically — one instance of the broader pattern in which verifiable identity, consent, and tamper-evidence are bound to an artifact so that trust travels with the artifact instead of being reconstructed at each hop.

AI and conversation records

The reason this work is urgent now rather than merely tidy is AI. Modern AI systems sit on both sides of a conversation: they consume conversations in enormous volume as training and inference input, and they increasingly are a party to the conversation, as agents that call, message, and transact on someone’s behalf. Both directions need what vCon provides. A conversation used to train or prompt a model carries consent and provenance questions that a signed container can answer and a loose recording cannot — what was permitted, whether a party was an AI, whether the record was altered. And a conversation an agent participates in needs a verifiable account of who the agent was acting for and what was said, which is exactly the kind of evidence a signed vCon can hold.

This places vCon at the intersection of the conversation-provenance problem and the agent-identity problem the digital-identity hub tracks: as agents become parties to conversations, the container that records the conversation and the credentials that identify the agent have to meet. vCon is where the library expects much of that meeting to happen.

Working group status

vCon is an active IETF working group. The core specification is a working-group draft heading toward Last Call; a companion overview gives the informational framing, and the privacy primer covers developer privacy guidance. A cluster of extensions — contact-center, provenance, lifecycle, and others — is developing around the core at varying stages of maturity, some adopted by the working group and some still individual drafts to watch. The IETF section tracks each document’s current revision and status; this page stays at the conceptual level and points there for the specifics, which move faster than a topic overview should try to.

Where this fits

vCon sits alongside STIR/SHAKEN as the second half of conversation trust — STIR for the call, vCon for what the call becomes — and feeds the digital-identity hub as the provenance layer for conversations. The per-document detail lives in the IETF section; the planned sub-pages here will take the data model, the consent and provenance mechanics, the STIR relationship, and the AI implications each to the depth a working engineer or a policy reader needs.