draft-ietf-vcon-vcon-core — The JSON format for vCon (the core specification)

draft-ietf-vcon-vcon-core (Petrie) is the IETF vCon working group’s core specification — the document that defines what a vCon actually is at the JSON-schema level. Daniel Petrie of SIPez LLC is the sole author on the cover. Currently draft-ietf-vcon-vcon-core-03. Standards Track. Active working group document, heading toward WG Last Call by the next IETF meeting. I co-chair the vCon working group with Brian Rosen.

The conceptual framing — what a vCon is for, why a standard container for conversation data matters, where this work sits relative to STIR and the broader trust framework — lives on the vCon topic page and in the companion overview draft. This page covers what’s specific to the core specification itself.

What the core specifies

The core defines the JSON object that is a vCon. At the top level, four arrays carry the bulk of the conversation: parties, dialog, analysis, and attachments. Around them sit the metadata — a globally unique uuid, created_at and updated_at timestamps, an optional subject, and the extensions and critical arrays that govern the extension mechanism.

The parties array carries identity information for each participant — telephone URLs, SIP URIs, mailto URLs, PASSporTs, names, decentralized identifiers, civic addresses, and a validation parameter that records how the identity was verified without leaking the verification data itself. The dialog array carries the actual exchange content — recordings, text, transfer events, or “incomplete” markers for calls that didn’t get setup. analysis carries derived content (transcripts, sentiment, summaries). attachments carries everything else — slide decks, consent receipts, documents discussed during the conversation.

A vCon exists in one of three forms:

• Unsigned — the working form, used while the conversation is in flight or being assembled.
• Signed — JWS-signed for integrity, with the unsigned form carried in the JWS payload.
• Encrypted — JWE-encrypted for privacy, with the JWS-signed form carried in the ciphertext.

Across security domains, a vCon flows through these forms. Once signed, the document is immutable — any further work creates a new amended vCon, where the new instance contains a deep copy of the prior signed version’s data plus whatever has been added or modified, with the prior version referenced by UUID. A redacted vCon is the same idea applied to data minimization — strip PII for downstream consumers and reference the unredacted parent by UUID, optionally URL plus content hash.

A note on the document name

The working group agreed to drop the duplicated word in the draft name: draft-ietf-vcon-vcon-core becomes draft-ietf-vcon-core, restarting at -00, with the current name marked abandoned. The content carries over unchanged.

Status

draft-ietf-vcon-vcon-core-03 (1 July 2026), vCon working group document, Standards Track. Current revision and state on the IETF datatracker.