vcon T. McCarthy-Howe Internet-Draft Strolid, Inc. Intended status: Standards Track S. Lasker Expires: 22 January 2026 Independent D. James Marashlian & Donahue, PLLC 21 July 2025 vCon Lifecycle Management using SCITT draft-howe-vcon-lifecycle-00 Abstract This document proposes using the SCITT (Supply Chain, Integrity, Transparency, and Trust) protocol to record, communicate and coordinate the lifecycle of Virtual Conversations (vCons), which are standardized containers for conversational data like call recordings, transcripts, and chat logs. While vCons enable capturing and sharing conversation details for AI analysis and business purposes, they lack mechanisms for proving compliance with privacy regulations and consent management. SCITT addresses this by providing an immutable, append-only transparency ledger that records key lifecycle events—from vCon creation and consent management to call recording, as well as data processing and deletion—enabling entities to demonstrate regulatory compliance and maintain trust across distributed systems. The framework specifically addresses consent management challenges under regulations like GDPR and CCPA, where consent can be revoked at any time, requiring coordinated deletion across all parties that have received the vCon. By combining vCons with SCITT, organizations can build scalable, transparent governance systems that protect personal data rights while enabling responsible use of conversational data for AI and business applications. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://howethomas.github.io/vcon-dev/draft-howe-vcon-lifecycle.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-howe-vcon-lifecycle/. Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (mailto:vcon@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/vcon/. Subscribe at https://www.ietf.org/mailman/listinfo/vcon/. McCarthy-Howe, et al. Expires 22 January 2026 [Page 1] Internet-Draft vCon Lifecycle July 2025 Source for this draft and an issue tracker can be found at https://github.com/vcon-dev/draft-howe-vcon-lifecycle. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acts of Trust and Transparency . . . . . . . . . . . . . 5 1.2. Standards-Based Interoperability . . . . . . . . . . . . 6 1.3. What Differentiates SCITT from a Database . . . . . . . . 6 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 3. vCon Lifecycle . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Example Use Case: Consent Management . . . . . . . . . . 9 3.2. vCon Lifecycle Scope . . . . . . . . . . . . . . . . . . 9 3.2.1. Creation, Distribution and Deletion . . . . . . . . . 9 3.2.2. Digital Rights Management . . . . . . . . . . . . . . 11 3.2.3. Amendment of Existing vCons . . . . . . . . . . . . . 12 4. Detailed Use Case . . . . . . . . . . . . . . . . . . . . . . 12 McCarthy-Howe, et al. Expires 22 January 2026 [Page 2] Internet-Draft vCon Lifecycle July 2025 4.1. vCon Create, Consent and Share . . . . . . . . . . . . . 12 4.1.1. Data Originator . . . . . . . . . . . . . . . . . . . 13 4.1.2. Data Controller . . . . . . . . . . . . . . . . . . . 14 4.1.3. Data Processor(s) . . . . . . . . . . . . . . . . . . 14 4.2. Revocation and the Right to Be Forgotten . . . . . . . . 15 4.2.1. Data Subject . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Data Controller Revocation . . . . . . . . . . . . . 16 4.2.3. Data Processor Revocation . . . . . . . . . . . . . . 16 5. vCon Lifecycle Events . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18 10. Informative References . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Virtual Conversations (vCons) draft-vcon (https://datatracker.ietf.org/wg/vcon/about) are powerful means of capturing and collaborating on the details of human conversations, built to travel. They feed AI systems, enable entities to respond more accurately to customer needs, and manage the health of their business more effectively. The vCon working group focuses on passing conversational data, such as data commonly generated and collected in business and security environments, from chat logs to transcripts to recordings. Most systems provide a way to store such information, but there are few standards or interoperability within the storage or transmission mechanisms. vCon is a framework for capturing and collaborating on the details of a Virtual Conversation, feeding AI systems, and enabling entities to respond to customer needs more accurately and manage their business's health more effectively. The two opposing forces influencing such information passing are trying to enforce personal data and communications privacy and providing the ability and interest to use conversations in various ways, e.g., AI analysis. Although vCons are tools that enable actors to do the right thing, they are not tools that enable actors in a distributed system to prove it. However, when combined with the SCITT protocol draft-scitt (https://datatracker.ietf.org/wg/scitt/about), proof becomes practical. SCITT allows Relying Parties to obtain information McCarthy-Howe, et al. Expires 22 January 2026 [Page 3] Internet-Draft vCon Lifecycle July 2025 pertinent to the lifecycle of a vCon in a "transparent" way. SCITT achieves this by having producers publish information in a Transparency Service, where Relying Parties can check the information. These relying parties can then use this information to make decisions based on the current state and context of the vCon to account for changes in consent, updates in the accuracy of the content, or amendments of the information it might contain. SCITT, the Supply Chain, Integrity, Transparency, and Trust protocol, enables clients to register statements about events, physical or virtual, such as when things are created or used. These statements are immutable and are useful to support auditing, governance, and coordination between various distributed systems. When using vCons to define a conversation, and SCITT to record the events that occur to them, more scalable and transparent systems of governance and provenance can be constructed to support privacy efforts. It is expected that there are many situations where this governance across security boundaries is common and desired by all parties. One real-world example of this is management of consent as it applies to the use of conversations for different purposes, such as machine learning. Using conversations as inputs to machine learning has great benefit to both customers and businesses, yet only responsibly within the defense of personal data rights and compliance with personal data and communications privacy laws, united together by consent. Although consent to a call recording or personal data collection and processing is not always required under the applicable laws, seeking consent is often the best practice, given the Privacy by Design principles, multijurisdictional business operations, and the ever-changing privacy laws. Please see the privacy-primer-vcon (https://datatracker.ietf.org/doc/draft-james-privacy-primer-vcon/) for more information on consent and other data subject protection concepts. In all of these cases, the ability to define and express the processing of conversations depends on the ability to authoritatively define the lifecycle of a vCon: * who originated the vCon in the first place to establish provenance * how it was analyzed and amended, to accurately respond to right- to-know requests * the authenticity both of the original document for downstream workflow McCarthy-Howe, et al. Expires 22 January 2026 [Page 4] Internet-Draft vCon Lifecycle July 2025 * and authenticity of the redactions that come from the original, in service of data minimization efforts * the various expressions of digital rights * the sharing or deletion in response to the same digital rights For this document and for purposes of illustration, consent will be used as an example use case. Proper consent management is fundamental to the responsible protection of data and the ability to leverage that data. Consent granted by the data subject of a vCon also needs to be stored and passed, exactly like the other information contained in a vCon. Unlike the rest of the information contained, the gathered consent is expressly not immutable. Consent, when gathered for a purpose, can also be revoked by the data subject at any time and surely after a vCon has been shared for analysis. Multiple regulations, including the US-born California Consumer Protection Act (CCPA) CCPA (https://oag.ca.gov/privacy/ccpa) and the EU-born General Data Protection Regulation (GDPR) GDPR (https://gdpr.eu/), outline requirements for entities to use and dispose of PII information responsibly upon request. Consent, although illustrative, is not the only example of mutability in the lifecycle of a vCon. Verification of parties, improvements in the analysis, and additions of contextual attachments result in updates to a vCon after data is shared, begging for a mechanism to track and govern such changes. To honor the working group's charter to pass conversational data safely between consenting parties, this draft provides an overview of the requirements, a workflow and an example consent structure for using SCITT to manage the vCon lifecycle at scale, providing end-to- end, interoperable services and tooling. The workflow enables entities in the workflow to collaborate on a vCon while assuring all entities in the workflow adhere to relevant PII regulations using a SCITT Ledger. Actual implementations of these workflows are left to implementers and applications; this draft provides an authoritative list of the entries that should appear on the SCITT transparency ledger to enable them. 1.1. Acts of Trust and Transparency Throughout this workflow, no single entity can prove that other entities performed the required actions. However, by auditing the SCITT Ledgers of all involved parties, entities can prove they acted on the acknowledged consent and intent of the Data Subject, holding other entities accountable for performing required operations. In short, this audit can help to prove that "the good guys did the right McCarthy-Howe, et al. Expires 22 January 2026 [Page 5] Internet-Draft vCon Lifecycle July 2025 thing", to measure the compliance of those outside this architecture who may have chosen different methods of compliance assurance. 1.2. Standards-Based Interoperability A wide range of industries and business scenarios benefit from virtual conversations, making them valuable across countless organizations.The breadth of industries and scenarios that benefit from virtual conversations spans numerous companies. The power of this technology lies in enabling cross-conversation collaboration. By implementing a standards-based approach, both collaborative and competitive companies can easily integrate with solutions for transcription, consent management, and CRM integration. Packaging conversations and associated metadata in the vCon format provides a standardized means to communicate what has been sent. Due to the personally identifiable information and digital fingerprinting in vCons, it's critical to understand and adhere to regulatory requirements for PII management. Defining and implementing a standard provides stability in information management throughout the lifecycle. Recording which vCon elements were sent to various parties holds each accountable for what was sent, what was received, and when these exchanges occurred. 1.3. What Differentiates SCITT from a Database The information written to SCITT could be compared to information in a standard database. What makes SCITT different: * *Immutable and Append-Only nature*: Once written, data cannot be modified or deleted * *Cryptographic security*: Through pre-signed statements, making SCITT a notary that cannot alter contents * *Independent verifiability*: Parties can verify data without trusting the service provider * *Separation*: Between the immutable, append-only ledger and the evidentiary metadata store (which can be deleted/redacted for PII governance) * *Standardized communication*: And enforcement of regulations and compliance McCarthy-Howe, et al. Expires 22 January 2026 [Page 6] Internet-Draft vCon Lifecycle July 2025 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 (https://www.rfc-editor.org/info/rfc8174) when, and only when, they appear in all capitals, as shown here. The following terms, derived from CCPA (https://oag.ca.gov/privacy/ ccpa), GDPR (https://gdpr.eu/) and privacy-primer-vcon (https://datatracker.ietf.org/doc/draft-james-privacy-primer-vcon/), are used throughout the document: *Conserver*: A vCon workflow engine that ingests vCons, routing them for processing and enhancements. A conserver doesn't store a vCon, rather it processes the vCon for transcription, sentiment, integrity protection on egress, verification on ingress, retrieving it from, and saving it to a vCon Registry. *Data Subject*: The individual(s) whose personal information is processed (also referred to as the "consumer" in many personal data privacy laws). *Data Originator*: The Entity that records and initiates the vCon, identifying the parties, including the media of the conversation. For a phone call, this may include the phone numbers and the audio recording. For internet-based calls, such as Microsoft Teams, Zoom, Google meet, this may include emails and audio/video recording. The Data Originator is a facilitator with access to the content of the call. This document addresses the instance where the Data Originator is a data processor under the applicable data privacy laws, collecting and processing data on behalf of a Data Controller. However, Data Originators may also act as Data Controllers when collecting and processing data for their own purposes. This document does not address such an instance, and implementers will need to adjust the technical process accordingly. In general, Data Originators may be required to collect consent by applicable law when acting as Data Controllers and by the relevant data processing agreements with Data Controllers when acting as Data Processors. . One or all of the Data Subjects must initiate consent, giving the Data Originator the right to record the conversation, which may be the Data Controller's responsibility to identify. *Data Controller*: An Entity or individual with decision-making authority over data processing who determines the purposes and methods of data processing, bears primary responsibility under privacy laws and is the main target of most privacy and data protection regulations. Under most data privacy laws, Data McCarthy-Howe, et al. Expires 22 January 2026 [Page 7] Internet-Draft vCon Lifecycle July 2025 Controllers are required to enter into data processing agreements with their Data Processors, detailing the rules for data collection and processing in accordance with applicable laws. *Data Processor*: An individual or an Entity, which processes personal data on behalf of the Data Controller. It is often a third- party service provider who processes data on behalf of the data controller. Under HIPAA data processors are referred to as "business associates." Data processors may be hired for specialized tasks or to improve efficiency; can subcontract to other processors, creating a chain of responsibility; must operate within the scope defined by the data controller; and are expected to maintain trust and adhere to the controller's guidelines. A Conserver often calls out to Data Processors for Transcription, Sentiment Analysis, Fraud Detection, email/text messaging. _Processing_: Any operation or set of operations which is performed on personal data or on sets of personal data. Among other things, this includes collection, storage, use, disclosure, and deletion. _Personal Data_: any information relating to an identified or identifiable Data Subject, including a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of the Data Subject. *Entity*: A generic reference to companies, groups or individuals that may share, alter, or use a vCon. An Entity may be a Data Originator, Data Controller, Data Processor or some other role that has not yet been defined that participates in the possession and/or processing of a vCon. *Party*: A party, or participant of a vCon, as identified in the vCon draft. *SCITT Transparency Service*: An append-only ledger for integrity protecting vCons, ensuring the state of a vCon is known at a point in time for conformance to governance and regulatory requirements. *vCon Registry*: A storage service, capable of storing vCons, including rich metadata and larger attachments including audio and video recordings. 3. vCon Lifecycle McCarthy-Howe, et al. Expires 22 January 2026 [Page 8] Internet-Draft vCon Lifecycle July 2025 3.1. Example Use Case: Consent Management The example use case, consent management, has the following requirements, all considered necessary to fulfill the proper sharing of personal information responsibly: * As an individual, I wish to express my data subject rights to express my consent for various purposes, and to withdraw the same. * As a member of an organization, I want to operationally assure that the processing of personal data is within the consent I gained from the data subject, and to safely record those activities to provide to both data subjects and governance bodies. * As a regulator, I wish to have a measurement system to support compliance, bias and regulatory enforcement of policy. * As a technologist, I wish to maintain the integrity of conversational pipelines, maintaining the trust both stakeholders and data subjects have in the trust and transparency of the process. 3.2. vCon Lifecycle Scope 3.2.1. Creation, Distribution and Deletion The vCon lifecycle comprises a series of phases from creation through distribution to deletion. Tracking these phases enables fundamental privacy rights, such as the right to know how your data was processed, and secures AI supply chains by establishing provenance and guaranteeing integrity. The phases of a vCon's life include: McCarthy-Howe, et al. Expires 22 January 2026 [Page 9] Internet-Draft vCon Lifecycle July 2025 +----------------+ +----------------+ +----------------+ | 1. vConCreated |---->| 2. Recording |---->| 3. vConSent | | | | Added | | | +----------------+ +----------------+ +----------------+ | v +----------------+ +----------------+ +----------------+ | 6. vConSentTo |<----| 5. vConEnhanced|<----| 4. vConReceived| | Processors | | | | | +----------------+ +----------------+ +----------------+ | v +----------------+ +----------------+ | 7. Data |---->| 8. vConDeletion| | Processing | | | +----------------+ +----------------+ 1. *vConCreated*: The call completes, and a vCon is created with call metadata stored in the vCon Registry. 2. *RecordingAdded*: The actual recording is saved and added to the attachments section of the vCon. 3. *vConSent*: The Data Originator sends the vCon to the Data Controller with integrity protection using SCITT. 4. *vConReceived*: The Data Controller receives the vCon and records this in the SCITT Transparency Service. 5. *vConEnhanced*: The Data Controller adds transcription and license information and identifies themselves. 6. *vConSentToProcessors*: The Data Controller sends the vCon to relevant Data Processors. 7. *Data Processing*: Value-added services are performed on the vCon data. 8. *vConDeletion*: The vCon is deleted when no longer needed, when consent is revoked, or when it expires. McCarthy-Howe, et al. Expires 22 January 2026 [Page 10] Internet-Draft vCon Lifecycle July 2025 3.2.2. Digital Rights Management Interwoven with the vCon lifecycle is consent management. A modern consent model is envisioned: consent is gathered by the Data Controller (or the Data Originator acting as a data processor on behalf of the Data Controller) for particular purposes (such as training or sharing) and can be withdrawn by the Data Subject on demand. This withdrawal may result in revoking the vCon or modifying it to remove non-consenting portions. +------------------+ +------------------+ +------------------+ | 1. ConsentTo |---->| 2. ConsentFor |---->| 3. Consent | | Record | | Purpose | | Recorded | +------------------+ +------------------+ +------------------+ | v +------------------+ +------------------+ +------------------+ | 6. RevokeRequest |<----| 5. ConsentReview |<----| 4. ConsentReceipt| | Processing | | Revocation | | Sent | +------------------+ +------------------+ +------------------+ Lifecycle events in Digital Rights Management include: 1. *ConsentToRecord*: Consent is requested from the Data Subject to record the conversation. 2. *ConsentForPurpose*: Confirmation of consent for specific purposes (e.g., "sales followup") is obtained. 3. *ConsentRecorded*: The Data Controller records where consent was confirmed in the transcript or recording. 4. *ConsentReceipt Sent*: Notification is sent to Data Subject(s) with a link to review consent details. 5. *ConsentReview/Revocation*: Data Subject can review or choose to revoke consent at any time. 6. *RevokeRequestProcessing*: If consent is revoked, the request is processed and communicated to all parties. McCarthy-Howe, et al. Expires 22 January 2026 [Page 11] Internet-Draft vCon Lifecycle July 2025 3.2.3. Amendment of Existing vCons Under normal circumstances, vCons may be amended. For example, at creation time, parties to a vCon may be verified through methods such as OAuth. However, if account credentials are later found to be compromised, the verification status may need revision. Party verification issues often trigger "Rights to Correct" requests and are fundamental to responsible data rights management. Other enhancements and modifications may occur for security reasons, future processing needs, or in response to regulatory changes. +----------------+ +----------------+ +----------------+ | 1. DialogAdded |---->| 2. vConProcessed|---->| 3. Data | | | | | | Redaction | +----------------+ +----------------+ +----------------+ Events that may be recorded on the distributed ledger include: 1. *DialogAdded*: A dialog is saved and added to the vCon. 2. *vConProcessed*: The Data Controller processes the vCon. 3. *Data Redaction*: Data Processors delete the data or redact the Data Subject. 4. Detailed Use Case 4.1. vCon Create, Consent and Share +-------------------+ +-------------------+ | Data Originator | | Data Controller | +---------+---------+ +---------+---------+ | | | 1. Call Initiation | |--------> | | | | 2. Consent to Record | |--------> | | | | 3. Consent to Share | |--------> | | | | 4. vCon Created | | | | 5. Recording Added | | | | 6. vCon Sent | |----------------------------------------->| McCarthy-Howe, et al. Expires 22 January 2026 [Page 12] Internet-Draft vCon Lifecycle July 2025 | | | | 7. vCon Received | | | | 8. vCon Enhanced | | | | 9. vCon Sent | |--------> | | | | +---------v---------+ +---------v---------+ | Data Originator | | Data Controller | +-------------------+ +-------------------+ | v +-------------------+ | Data Processor | +---------+---------+ | | 10. vCon Received | | 11. Consent Recorded | | 12. vCon Enhanced | | 13. Consent Receipt | Sent | | 14. Consent Review | | 15. Value-Add | Services | +---------v---------+ | Data Processor | +-------------------+ 4.1.1. Data Originator 1. *Initiating Call*: An initiating caller contacts a Data Subject to provide a service. 2. *Consent to Record*: The initiating caller requests consent to record the call for training purposes. McCarthy-Howe, et al. Expires 22 January 2026 [Page 13] Internet-Draft vCon Lifecycle July 2025 3. *Consent to Share*: The call completes, confirming consent for the recording to be used for "sales followup", noting that the Data Subject can review and revoke consent later. Depending on the types of personal data communicated on the call and the purpose of its processing, the consent request language may need to include additional information. 4. *vCon Created*: The call completes, the vCon is created, and call metadata is recordedin the vCon Registry. 5. *Recording Added*: The recording is saved to the vCon Registry, adding it to the vCon's attachments section. 6. *vCon Sent*: The Data Originator completes their responsibilities and sends the vCon to the Data Controller. 4.1.2. Data Controller 1. *vCon Received*: The vCon is received from the Data Originator, and a vcon_received operation is recorded in the SCITT Transparency Service. 2. *vCon Enhanced with License and Data Controller*: The Data Controller adds transcription, specifies the intended license, and identifies themselves as the Data Controller on the vCon. 3. *vCon Sent*: The Data Controller sends the vCon to the Data Processor(s). 4.1.3. Data Processor(s) 1. *vCon Received*: The Data Processor validates the vCon's SCITT receipt from the Data Controller. 2. *Consent Recorded*: The Data Processor records consent confirmation in the SCITT Transparency Service. 3. *vCon Enhanced*: Sentiment analysis and other enhancements are processed through the Data Processor's Conserver workflows. 4. *Consent Receipt Sent*: The Data Processor sends notification to the Data Subject(s) with a link to review consent details. 5. *Consent Review*: The Data Subject(s) can review vCon information at any time and revoke consent if desired. 6. *Data Processor Value-Add*: The Data Processor performs value- added services for the Data Subject(s). McCarthy-Howe, et al. Expires 22 January 2026 [Page 14] Internet-Draft vCon Lifecycle July 2025 4.2. Revocation and the Right to Be Forgotten At any point, a Data Subject can request revocation or the right to be forgotten, requiring all vCon possessors to act accordingly. vCons must be tracked for where they were sent and who to contact when a Data Subject makes such requests. The SCITT Transparency Service maintains metadata about ingested vCons, ensuring integrity and inclusion protection. +-------------------+ +-------------------+ | Data Subject | | Data Controller | +---------+---------+ +---------+---------+ | | | 1. Revoke Consent | |--------> | | | | 2. Revoke Request Sent | |----------------------------------------->| | | | | 3. Act on Revocation | | | | 4. Send Request to | | All Processors | |--------> | | +---------v---------+ +---------v---------+ | Data Subject | | Data Controller | +-------------------+ +-------------------+ | v +-------------------+ | Data Processor | +---------+---------+ | | 5. Deletion of Data | +---------v---------+ | Data Processor | +-------------------+ 4.2.1. Data Subject 1. *Revoke Consent*: The Data Subject revokes consent by some manner: i.e. clicks a link included in all communications between the Data Processor and the Data Subject(s), through an external system or in conversation with the data controller. McCarthy-Howe, et al. Expires 22 January 2026 [Page 15] Internet-Draft vCon Lifecycle July 2025 2. *Revoke Request Sent*: If the vcon_consent_revoked operation was handled by the Data Processor, they MUST contact the Data Controller to communicate the Data Subject's intent. 4.2.2. Data Controller Revocation 1. *Act on Consent Revocation Request*: The Data Controller receives the vCon Consent Revocation Request and records it on their SCITT Transparency Service. 2. *Send Revocation Request to Data Controllers*: If the vCon was sent to other Data Processors, they must communicate the revocation request to any Data Processor that hasn't yet acknowledged it. 4.2.3. Data Processor Revocation 1. *Deletion of Data*: Any Data Processor that hasn't yet acted on the request must acknowledge it. 5. vCon Lifecycle Events The following events outline important "moments that matter" in a vCon's lifecycle. These events are not intended to be stored within the vCon itself, but rather as operations stored on SCITT to provide context for the vCon's intent at specific points in time: * *vcon_created*: The initial vCon document as first recorded. The vCon may start with a basic structure defining minimal metadata, as recordings or attachments may be added asynchronously upon encoding completion. * *vcon_enhanced*: The vCon has been amended or appended. While vCons are considered immutable, information may be amended or appended—previous values exist in the vCon Registry but may be superseded. Amendments may include transcription corrections or consent changes. * *vcon_sent*: The vCon was sent to an external party. This operation seals the vCon's integrity, recording what was sent, to whom, and when in the SCITT Transparency Service. A SCITT receipt from the receiving service confirms possession. * *vcon_received*: The vCon was received from an external entity. This documents possession at a specific time, sealing content integrity and returning a SCITT receipt to the sender. McCarthy-Howe, et al. Expires 22 January 2026 [Page 16] Internet-Draft vCon Lifecycle July 2025 * *vcon_consent_accepted*: One or more parties have consented to the vCon being recorded and shared for its intended purpose. Consent may not be established during initial vCon creation, as the Data Controller, not the Data Originator (infrastructure provider), is responsible for managing Data Subject consent. * *vcon_consent_revoked*: One or more parties have revoked consent for one or more purposes. Depending on region, license, and regulatory requirements, one revocation may or may not require all Data Processors to act. * *vcon_party_redacted*: A party to the vCon has been redacted. This differs from consent revocation, as the vCon may remain viable if a party's information can be redacted while maintaining integrity and usefulness. * *vcon_deleted*: The vCon has been deleted due to an implicit act such as revocation or no longer being needed. When a Data Controller deletes a vCon, they must inform all recipients to either delete it or assume Data Controller responsibilities. * *vcon_expired*: The vCon has expired due to license terms or compliance requirements. This triggers deletion and notification to all shared entities. * *vcon_rcvr_purged*: When a vCon is sent from a Data Controller, the receiving Entity may maintain it indefinitely, for a set period, or delete it upon operation completion. If the Entity no longer needs to maintain the vCon, they can delete it and notify the sender. 6. Security Considerations The security of the vCon lifecycle depends heavily on the integrity and availability of the SCITT Transparency Service. Entities MUST ensure that their SCITT implementations are properly secured and that access controls are in place to prevent unauthorized modifications. The handling of personally identifiable information (PII) throughout the vCon lifecycle requires careful consideration of privacy regulations and data protection requirements. Entities MUST implement appropriate technical and organizational measures to protect PII and ensure compliance with applicable regulations. McCarthy-Howe, et al. Expires 22 January 2026 [Page 17] Internet-Draft vCon Lifecycle July 2025 7. Privacy Considerations This document describes a framework for managing vCons that contain personally identifiable information. Implementers MUST ensure compliance with applicable privacy regulations, including but not limited to GDPR GDPR (https://gdpr.eu/) and CCPA CCPA (https://oag.ca.gov/privacy/ccpa). The framework provides mechanisms for consent management and data subject rights, but implementers are responsible for ensuring that their implementations properly respect and enforce these rights. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References 9.2. Informative References 10. Informative References [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [CDDL] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [CDR] ITU, "Recommendation Q.825: Specification of TMN applications at the Q3 interface: Call detail recording", n.d., . [GEOPRIV] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, . [GZIP] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . McCarthy-Howe, et al. Expires 22 January 2026 [Page 18] Internet-Draft vCon Lifecycle July 2025 [HTTPS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [IANA-COSE-ALG] "COSE Algorithms", n.d., <>. [ISOBMFF] "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2022, January 2022, . [JMAP] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, . [MEDIATYPE] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . McCarthy-Howe, et al. Expires 22 January 2026 [Page 19] Internet-Draft vCon Lifecycle July 2025 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [PASSporT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [PIDF-LO] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, . [SHA-512] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [SIP-XFER] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, . [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [STIR-PASS] Wendt, C. and J. Peterson, "PASSporT Extension for Rich Call Data", Work in Progress, Internet-Draft, draft-ietf- stir-passport-rcd-26, 5 June 2023, . [TEL] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, . [UUID] Peabody, B. and K. R. Davis, "New UUID Formats", Work in Progress, Internet-Draft, draft-peabody-dispatch-new-uuid- format-04, 23 June 2022, . McCarthy-Howe, et al. Expires 22 January 2026 [Page 20] Internet-Draft vCon Lifecycle July 2025 [vCard] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . [vCon-white-paper] Howe, T., Petrie, D., Lieberman, M., and A. Quayle, "vCon: an Open Standard for Conversation Data", n.d., . Appendix A. Acknowledgments * Thank you to Allistair Woodman for connecting the first dots between VCon and SCITT * Thank you to Jeff Pulver and Cody Launius for their collaboration and support Authors' Addresses Thomas McCarthy-Howe Strolid, Inc. Email: thomas.howe@strolid.com S. Lasker Independent Email: stevenlasker@hotmail.com Diana James Marashlian & Donahue, PLLC Email: daj@commlawgroup.com McCarthy-Howe, et al. Expires 22 January 2026 [Page 21]