draft-howe-vcon-lifecycle-00.txt

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,
              <https://www.rfc-editor.org/rfc/rfc8949>.

   [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, <https://www.rfc-editor.org/rfc/rfc8610>.

   [CDR]      ITU, "Recommendation Q.825: Specification of TMN
              applications at the Q3 interface: Call detail recording",
              n.d., <https://www.itu.int/rec/T-REC-Q.825>.

   [GEOPRIV]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4119>.

   [GZIP]     Deutsch, P., "GZIP file format specification version 4.3",
              RFC 1952, DOI 10.17487/RFC1952, May 1996,
              <https://www.rfc-editor.org/rfc/rfc1952>.





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,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [IANA-COSE-ALG]
              "COSE Algorithms", n.d.,
              <<https://www.iana.org/assignments/cose/cose.xhtml>>.

   [ISOBMFF]  "Information technology -- Coding of audio-visual objects
              -- Part 12: ISO base media file format", ISO/IEC
              14496-12:2022, January 2022,
              <https://www.iso.org/standard/83102.html>.

   [JMAP]     Jenkins, N. and C. Newman, "The JSON Meta Application
              Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
              2019, <https://www.rfc-editor.org/rfc/rfc8620>.

   [JSON]     Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

   [JWE]      Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
              RFC 7516, DOI 10.17487/RFC7516, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7516>.

   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [JWS]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [JWT]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [MAILTO]   Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/rfc/rfc6068>.

   [MEDIATYPE]
              Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.



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,
              <https://www.rfc-editor.org/rfc/rfc2045>.

   [PASSporT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8225>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc5491>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc6234>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc5589>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5321>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
              passport-rcd-26>.

   [TEL]      Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <https://www.rfc-editor.org/rfc/rfc3966>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-peabody-
              dispatch-new-uuid-format-04>.






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,
              <https://www.rfc-editor.org/rfc/rfc7095>.

   [vCon-white-paper]
              Howe, T., Petrie, D., Lieberman, M., and A. Quayle, "vCon:
              an Open Standard for Conversation Data", n.d.,
              <https://github.com/vcon-dev/vcon/blob/main/docs/vCons_%20
              an%20Open%20Standard%20for%20Conversation%20Data.pdf>.

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]