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-02 (published 22 January 2026, expires 26 July 2026). 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.

What changed in -02

The schema evolved substantially between -00 and -02 in response to working-group discussion. The vcon schema-version parameter was deprecated — version-pinning is replaced by the extension mechanism, where extensions lists what’s present and critical lists what an implementation must understand to safely process the document. The Append-vs-Amend rename landed (the “appended” object became “amended”). Civic-address parameters and time-based GPS location moved out of the core. The group object was deferred to a separate extension. SHA-512 remains the default content-hash algorithm for externally referenced files.

Open items continuing into the next revision include the draft-name change (the working group agreed to drop the duplicate “vcon” — draft-ietf-vcon-vcon-core will become draft-ietf-vcon-core and reset to -00, with the current naming marked as abandoned), inclusion of a JSON Schema as an appendix, and consolidation of the Mimi messaging extension’s party-history changes into the core.

IANA

The core establishes the mediatypes for JSON and gzip vCon representations and the registries that make the extension mechanism work — the vCon Extensions Names Registry (where extension tokens like “CC” are registered), and parameter-name registries for each of the major object types (vCon, Party, Dialog, Attachment, Analysis, Redacted, Amended, Party History). Each extension that adds parameters registers them into the appropriate per-object registry, citing its specification document.

Status

Currently draft-ietf-vcon-vcon-core-02, published 22 January 2026, expires 26 July 2026. Active working group document, Standards Track. WG state is WG Document and IESG state is I-D Exists. The working group is targeting WG Last Call by the next IETF meeting. The renamed -00 (under draft-ietf-vcon-core per the WG decision) is expected to land in the next revision cycle.