The vCon - Conversation Data Container - Overview

1.1. What's in a vCon?

A vCon contains four major categories of data (parties, dialog, analysis and attachments), with descriptive identifiers and metadata, inside a JSON container that can be signed and encrypted. The parties portion allows for an expanded set of data from a typical call detail record ([CDR]), with identifications of the participants or parties to the conversation. The dialog portion contains a set of multimedia and media type elements, each representing the actual, physical conversation in original media form: text, audio, video and imagery. The analysis portion contains data derived from the party and dialog portions, intended to carry items like transcripts, translations, summaries, text to speech, sentiment analysis and other semantic tagging. Finally, the attachment portion contains any other documents, such as slide deck or sales lead information, expressions of consent or authenticity, which provides context and support for the conversation itself.¶

In addition to these four major categories, the vCon itself carries top-level metadata including a globally unique identifier (UUID), creation and last-modified timestamps (created_at and updated_at), an optional subject, and references to other vCons through redaction or amendment. The vCon may also contain integrity checking information such as the issuer of the vCon and tamper-proof features such as signatures. An extensions mechanism allows the vCon schema to be extended for specialized use cases while maintaining interoperability with implementations that support only the core format.¶

1.2. Data Responsibility: Privacy vs Utility

Since vCons are designed to carry conversational data between systems, they must provide the ability to balance the utility and sensitivity of the information they contain. The transmission of information outside of a security boundary does not release the controller of the data from the responsibility of handing personal data. vCons enable the best practices of personal data management through approaches such as data minimization, consent validation and integrity protection.¶

The parties section carries significant privacy implications and responsibilities; the very definition of the sensitive biometric data addressed by the GDPR. Each party identified in a vCon represents an individual or entity whose personal information is being captured and potentially shared. The vCon creator and any subsequent processors of the vCon have a responsibility to ensure that the collection, storage, and sharing of party information complies with applicable privacy laws and regulations (such as GDPR, CCPA, or other regional privacy frameworks). This includes obtaining appropriate consent for data collection, implementing data minimization practices, and providing mechanisms for data subjects to exercise their rights regarding their personal information.¶

At the same time, the conversations defined by the vCon carry the most authentic and important data in many scenarios from healthcare to commerce; a powerful addition to any data set. To enable adoption, the JSON format implemented by the vCon is the lingua franca of modern software; a frictionless integration to applications that require the human conversation. It is expected that JavaScript handling of vCons in the front end and RESTful interfaces and back end platforms will be used for operations and manipulation of vCons. Many media analysis services which will be used with vCons, such as transcription, already use JSON based interfaces. For these reasons, JSON [JSON] has been chosen for the initial format binding of vCons and the scope of this document. Other bindings (e.g. [CBOR] or [CDDL]) may be considered for vCon in the future in other documents.¶

For most application architectures, JSON objects are created by applications, for applications. However, most of the initial set of use cases differ from this established pattern, and are expected to be in the interchange between front end and back end application and lower layers of the network stack, critical for enablement of analysis of conversations. Thus, the contents of the vCon, if not the vCon itself, are generated by various and diverse network and communications elements like SIP user agents and SMTP servers, and then delivered across networks, and sometimes across security boundaries. This diversity of conversational data creates difficulty in creating unified views of customer conversations, especially as they traverse conversational modes. By providing a common mechanism to describe conversations, appropriate to the various network elements that create them, enables new scenarios and usage kinds.¶

1.3. Use Cases and Requirements

1.4. VCON Requirements

• Standardize container for conversational data exchange¶

• Consolidation of data and information for a conversation¶

• Multiple modes of communication, changing over time¶

• Snapshots of conversation during or once completed along with analysis¶

• Ease of integration of services and analysis¶

• Better organize conversational data so that it can be handled in a consistent, privacy safer means¶

• Immutable¶

• Hiding of PII or entire conversation¶

• Amendable with additional information and data elements¶

2.1. Terminology

• amended vCon - a new vCon instance version created by adding to or modifying a prior signed vCon, referencing the earlier version through the amended parameter while containing a deep copy of all prior data plus new content¶

• analysis - analysis, transformations, summary, sentiment, or translation typically of the dialog data¶

• compatible extension - a vCon schema extension that introduces additional data or fields without altering the meaning of existing elements, allowing implementations that do not recognize the extension to safely ignore it¶

• consent - explicit permission granted by a party for the collection, processing, or sharing of their conversation data¶

• conversation - an exchange of communication using text, audio or video medium between at least one human and one or more bots or humans¶

• critical extension - an incompatible vCon schema extension that modifies existing semantics and must be listed in the vCon's critical parameter; implementations that do not support a critical extension must reject the vCon¶

• data minimization - the practice of limiting the collection and processing of personal data to what is necessary for the stated purpose¶

• de-identification - removal of all information that could identify a party in a conversation. This includes PII as well as audio and video recordings. Voice recordings might be re-vocalized with a different speaker.¶

• dialog - the captured conversation in its original form (e.g. text, audio or video)¶

• encrypted form - encrypted [JWE] document with the [JWS] signed vCon form contained in the ciphertext¶

• extension - a registered addition to the vCon schema that defines new parameters or modifies existing semantics, identified by a unique token value registered with IANA¶

• file - a data block either included or referenced in a vCon¶

• object - JSON object containing key and value pairs¶

• parameter - JSON key and value pair¶

• party - an observer or participant to the conversation, either passive or active¶

• payload - the contents or bytes that make up a file¶

• PII - Personal Identifiable Information¶

• PII masked - may include voice recordings, but PII is removed from transcripts and recordings (audio and video)¶

• redaction - the process of removing or obscuring specific content from a vCon while maintaining the overall structure and integrity¶

• signed form - [JWS] signed document with the unsigned vCon form contained in the payload¶

• vCon - container for conversational information¶

• vCon instance - a vCon populated with data for a specific conversation¶

• vCon instance version - a single version of an instance of a conversation, which may be modified to redact or amend additional information forming a subsequent vCon instance version¶

2.2. Inline vs Externally Referenced Files

Due to the size and complexity of some portions of a vCon, both inline and externally referenced dialog, analysis, attachments and other vCon reference assets are supported. For instance, vCons may reference a video conference media recording as an external URL with an accompanying content hash of the contents to detect tampering. Alternatively, vCons may directly contain the media of the entire dialog internally, keeping the conversation in one place, and optionally encrypted.¶

3.1. A Conversational Definition

vCons define conversations, and are created by systems during and after the conversation itself. vCons provide ways to express and define the contents, participants and context of a particular conversation. Unlike some measurable physical phenomena, like mass and volume, conversations are heterogeneous, relatively complex and contain relevant information outside of the physical phenomena, such as consent and provenance. Some communication modes, like SMS texting, lack natural session boundaries and require explicit definition. Thus, the definition of a conversation requires more than a simple scalar value, or a series of samples of a time-based waveform. The definition of a conversation enables tools and systems to precisely identify, responsibly manage, efficiently process and accurately govern their use.¶

vCons also enables the definer of the conversation to express the scope of the conversations. A vCon may contain any combination of content appropriate to the use case:¶

• A vCon may be a single audio recording, or a complete conversational journey from a text message, to a resulting conversation and a followup email.¶

• A vCon may represent a conversation between two people, a conversation between a person and a machine, or all of the conversations between customers and a contact center team.¶

• A vCon may be sent in response to a Right To Know request to a single customer, or to a governance body during an audit¶

None of the major parts of the vCon (parties, dialog, attachments and analysis) are required to be present, to maximize the conversations that can be expressed. For instance, a recording without a parties definition is a valid expression of a conversation without defining the people involved, either because it is unknown, to be discovered through the analysis of the recording, or to be hidden for data minimization reasons. vCons may have two or more parties involved, but since a fundamental role of the vCon is to define and protect the data it contains, at least one should be, in the words of the GDPR, a "natural person." For instance, an interaction between a bot and a human is an appropriate scope for vCons, but a conversation between two bots would not.¶

3.2. Parties

The parties section in a vCon serves as the container for all participant identity information involved in the conversation. Structurally, it is an array of party objects, each of which can include various attributes such as telephone numbers, email addresses, names, and even structured contact information (like civic addresses and geographic coordinates). The purpose of this section is to provide clear attribution of every interaction by documenting who participated in the conversation. This not only supports accurate record-keeping but also enables accountability, context, and subsequent analysis of the conversation data.¶

Each party object may contain a variety of identification attributes. Traditional contact identifiers include telephone numbers, email addresses, SIP URIs, and participant names. Decentralized Identifiers (DIDs) provide a verifiable, decentralized digital identity that is independent of centralized registries. A validation parameter records how the party's identity was verified (for example, by social security number, date of birth, or user credentials), capturing the method of validation without exposing the actual verification data. For scenarios requiring cross-conversation correlation, such as contact center agents handling multiple interactions, a persistent UUID can be assigned to a party that remains stable across vCon instances. Geographic context can be captured through geolocation coordinates and civic address information, recording the party's location at the time of conversation.¶

The identification of parties serves multiple purposes beyond simple attribution. It enables proper consent management by clearly identifying whose data is being processed, supports data subject rights requests by providing a clear mapping of individuals to their conversation data, and facilitates compliance with privacy regulations that require organizations to track and manage personal data throughout its lifecycle. Additionally, the structured nature of party identification allows for consistent handling of privacy-related operations such as data deletion, anonymization, or redaction requests across different systems and jurisdictions.¶

3.3. Dialog

The dialog section in a vCon captures the actual conversation content that occurred between parties. This is the core of what makes a vCon valuable - it contains the real communication that took place, whether that was spoken words, text messages, or other forms of interaction. The dialog section serves as the primary record of what was said, when it was said, and who was involved in each exchange. Dialogs contain the "ground truths" of the conversation.¶

Each dialog entry represents a distinct communication event within the broader conversation. This could be a single text message, a phone call, a video conference session, or any other form of communication. The dialog section maintains the chronological flow and context of the conversation, preserving not just what was communicated, but the timing and sequence of exchanges that give meaning to the interaction.¶

The identification and tracking of dialog content serves critical privacy and compliance functions. The structured format enables precise identification of which specific conversations contain personal information, allowing for targeted data subject rights fulfillment such as selective deletion of specific dialog segments rather than entire conversation records. The timestamp and party reference metadata provide essential context for privacy impact assessments and data retention decisions. Additionally, the content hash mechanism ensures data integrity while also enabling verification that external content has not been tampered with, which is crucial for maintaining the trustworthiness of conversation records in legal or compliance contexts.¶

The dialog section supports several types of content. Recording dialogs capture audio or video segments of the conversation. Text dialogs contain written exchanges such as chat messages, SMS, or email content. Transfer dialogs record call transfer events, identifying the transferee, transferor, and transfer target roles along with references to the original and resulting dialog segments. Incomplete dialogs capture failed or unanswered communication attempts, with a disposition parameter indicating the reason for failure (such as no-answer, busy, congestion, or voicemail without a message).¶

Each dialog entry carries rich metadata beyond the conversation content itself. An originator parameter explicitly identifies the initiating party (the caller, message sender, or conference host). A party_history array tracks temporal events within the dialog, such as when participants join, drop, go on hold, mute, or press DTMF keys, providing a detailed timeline of the interaction dynamics. The application parameter identifies the communication platform or service provider (for example, distinguishing between different video conferencing services), while a message_id parameter enables cross-referencing with messaging system identifiers such as SMTP message-ids for deduplication and threading. A session_id parameter links the dialog to SIP Session-ID values for cross-system correlation in telephony environments.¶

The purpose of the dialog section is two-fold:¶

• Content Representation: It accurately captures the details of any conversation exchange -- be it spoken words, text messages, or other communication types. This ensures that the exact sequence and content are archived in a standardized format. The content appropriate to dialogs are any of the times and places where personal data is communicated and recorded: audio, video, email, fax, rich emails as examples.¶

• Interoperability and Analysis: The dialog's structured format supports further analysis (such as transcription or sentiment analysis) and ensures that conversations can be reliably exchanged between systems. By storing metadata like timestamps and participant references, the dialog section also enables the reconstruction of events (such as when participants join or leave a conversation) and aids in analytic processing.¶

3.4. Attachments

Attachments carry the context of the conversation; storing supplemental files and data that support the conversation record. In the vCon, attachments are designed as an array of opaque objects. They can be documents, images or any valid mediatype that can serve the proper analysis and comprehension of the conversation by providing context. In them, they may contain expressions of consent, references to content authenticity, authorization receipts and business tracking objects.¶

In parallel with each opaque object is a set of metadata that enables semantic understanding of the contents without the exposure of the underlying data. Attachment metadata contains information such as the type of data it contains, the party or dialog it refers to, and whether or not the data is contained in the attachment itself, or is referenced by external network identifier. A purpose parameter provides a free-form description of why the attachment is included, enabling downstream systems to understand the relevance of supplemental materials without necessarily inspecting their contents. Each attachment is linked to a specific party (the contributor, not necessarily the author) and a specific dialog segment through index references, maintaining clear provenance within the conversation record.¶

3.5. Analysis

The analysis section of a vCon contains processed insights and derived information from the original conversation data, serving as a bridge between the raw conversation data and business intelligence applications. The analysis section increases the utility of the conversation record by transforming raw dialog data into meaningful information. This can include automatically deriving summaries, measuring sentiment, extracting key topics, and identifying action items. Common analysis types include reports, sentiment assessments, summaries, transcripts, translations, and text-to-speech renderings. Such insights are pivotal in generating business intelligence, facilitating quality control, and supporting various applications where actionable information from conversations is crucial.¶

Each analysis entry identifies its provenance through a required vendor parameter, which names the service or organization that produced the analysis. This is important because different analysis implementations can produce significantly different results in quality, format, and interpretation. An optional product parameter differentiates between multiple offerings from the same vendor, while a schema parameter labels the specific data format or configuration used to generate the analysis. Together, these parameters enable consumers of vCon data to understand exactly how analysis was produced and to select appropriate processing logic for different analysis sources.¶

Analysis data represents a significant privacy consideration as it often contains processed personal information that may reveal insights about individuals beyond what is explicitly stated in the original conversation. This includes inferred characteristics, behavioral patterns, emotional states, and other derived information that could be considered personal data under privacy regulations. The vCon creator and processors must ensure that any analysis performed complies with applicable privacy laws and that data subjects are informed about what analysis is being conducted on their data.¶

The "Right to know" principle is particularly important in the analysis section, as individuals have the right to understand what information is being derived from their conversations and how it is being used. This includes transparency about what types of analysis are being performed, what insights are being generated, and how those insights are being applied. Organizations processing vCons must provide clear information about the analytical processes being applied to conversation data, including the purposes of analysis, the types of insights being generated, and how those insights may be used to make decisions about individuals.¶

The analysis section enables organizations to extract value from conversations while maintaining accountability for how personal information is processed. By clearly documenting what analysis has been performed and linking it back to specific dialog segments, the analysis section supports compliance with data subject rights requests, enables audit trails for analytical processes, and provides transparency about how conversation data is being transformed into business intelligence.¶

3.6. Relationships between vCons

Relationships between vCons may also be defined, either through grouping, redaction or through amending past vCons. Groups of vCons can be expressed, to indicate general interrelationships. Redactions are at the heart of data minimization, a primary technique of personal data protection. vCons enable the sharing of limited data through redaction, while retaining the ability of systems to guarantee the accuracy of the redaction itself.¶

3.7. Extensions Mechanism

The vCon schema provides a formal mechanism for extending the core format to address specialized use cases and evolving requirements. Extensions allow new parameters to be defined at any level of the schema, and can also redefine the semantics of or deprecate existing parameters. This replaces the earlier approach of schema versioning through a version parameter, which has been deprecated.¶

Extensions are classified into two categories:¶

• Compatible extensions introduce additional data or fields without altering the meaning or structure of existing elements. Implementations that do not recognize these extensions can safely ignore them while maintaining valid processing of the vCon. Wherever feasible, extensions should be designed as compatible to preserve interoperability.¶

• Incompatible (critical) extensions modify existing semantics or schema definitions in ways that require explicit awareness for correct interpretation. The names of all such extensions must be listed in the vCon's critical parameter, allowing implementations to determine whether they can safely process the vCon. An implementation that encounters an unsupported critical extension must reject the vCon rather than risk misinterpretation.¶

The distinction between compatible and incompatible is somewhat context-dependent. A transcription service can be fairly tolerant of new parameters added to a vCon. A redaction service, on the other hand, must be aware of the implications of all parameters to ensure complete redaction of sensitive information, and may need to reject vCons with any unrecognized extension.¶

Each extension must define a unique token value registered with IANA, specify its new or modified parameters and their semantics, and use snake_case naming conventions for parameter names. This framework ensures that vCon remains adaptable to industry-specific needs (such as contact centers, messaging platforms, and emergency services) while maintaining a consistent base format for data exchange.¶

3.8. Amended Use Cases

A vCon will often evolve over time. It is not always created with all of its metadata, conversation media, attachments, and analysis at once. There are several reasons for this:¶

• Different components of the vCon may be produced by different application platforms or entities.¶

• The vCon may pass across multiple trust boundaries during its lifecycle, with entities on either side contributing content.¶

• Each of these entities may wish to sign the vCon to attest to its integrity or to the authenticity of their contributions.¶

Once a vCon has been signed, it becomes immutable. Any modification will invalidate the signature. To address this, a new vCon can be created containing the updated or additional content. This new vCon can reference the previously signed version, preserving the integrity of the earlier state while allowing the overall conversation record to evolve.¶

This approach can also be applied even when a vCon is unsigned, for scenarios where maintaining a historical snapshot is important. For example, an application may wish to preserve a point-in-time representation of the vCon at a significant stage in its lifecycle.¶

There are two competing requirements in this use case:¶

• Ease of use and access to the latest version of the vCon¶

• Data size minimization and normalization¶

For ease of use, it is often desirable to work with a fully composed vCon that contains all prior and newly added or updated content. This has sometimes been referred to in vCon discussions as a "deep copy." Such a vCon requires no special handling, redirection, or reconstruction. It contains all relevant information in a single, self-contained structure.¶

However, this approach introduces duplication and increases document size. To address concerns around efficiency and data normalization, a more compact representation using patches or incremental updates may be preferred. This method allows changes to be recorded relative to earlier versions, reducing redundancy. Additionally, it enables labeling or referencing specific stages in the vCon's lifecycle, offering a flexible way to manage changes. In vCon discussions, this method has been referred to as representing incremental changes.¶

                --------------
Signed          | JWS        |
amended vCon:   |            | payload parameter
                |    payload-|-- contains unsigned
                -------------- / amended vCon
                              /
            -------------    /
vCon with   |vCon       |<---
amended     |           | amended parameter contains
data:       |  amended -|--- or refers to JWS
            |  analysis |  / signed original vCon
            ------------- / along with additional
                         / conversational data
                        / (e.g. analysis)
                       /
                      /
                     /
                    / ------------
                    ->| JWS      | payload
Encrypted signed      |          | parameter
original vCon:        |  payload-|--- contains
                      ------------  / unsigned
                                   / original
                  -------------   / vCon
Original vCon:    |vCon       |<--
                  |           |
                  |   parties |
                  |   dialog  |
                  -------------