vCon T. McCarthy-Howe Internet-Draft Strolid Intended status: Standards Track 25 September 2025 Expires: 29 March 2026 vCon Lawful Basis draft-howe-vcon-lawful-basis-00 Abstract This document defines a lawful basis extension for Virtualized Conversations (vCon) that provides standardized mechanisms for recording, verifying, and managing the lawful basis for processing data within conversation containers. The lawful basis extension addresses privacy compliance challenges through structured attachment metadata, including the specific lawful basis being asserted, temporal validity periods where applicable, and cryptographic proof mechanisms. The extension is designed as a Compatible vCon extension that introduces lawful basis management capabilities without altering existing vCon semantics. It defines a "lawful_basis" attachment type with structured records for each of the six lawful bases defined in regulations like GDPR, including consent, contract, legal obligation, vital interests, public task, and legitimate interests. Key features include automated lawful basis detection during conversation processing, auditable records with cryptographic proofs, granular purpose-based permissions for all lawful bases, documented justifications for other lawful bases, and integration with privacy regulations including GDPR, CCPA, and HIPAA. 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://vcon- dev.github.io/draft-howe-vcon-consent/draft-howe-vcon-lawful-basis- latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-howe-vcon-lawful-basis/. Discussion of this document takes place on the vCon 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 Expires 29 March 2026 [Page 1] Internet-Draft vCon Lawful Basis September 2025 Source for this draft and an issue tracker can be found at https://github.com/vcon-dev/draft-howe-vcon-lawful-basis. 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 29 March 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2.1. Core Terms . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Lawful Bases . . . . . . . . . . . . . . . . . . 5 4. vCon Lawful Basis Extension Definition . . . . . . . . . . . 6 4.1. Extension Classification . . . . . . . . . . . . . . . . 6 4.2. Extension Registration . . . . . . . . . . . . . . . . . 6 4.3. Extension Usage . . . . . . . . . . . . . . . . . . . . . 7 5. Lawful Basis Attachment Structure . . . . . . . . . . . . . . 7 5.1. Attachment Container . . . . . . . . . . . . . . . . . . 7 5.2. Lawful Basis Body Structure . . . . . . . . . . . . . . . 7 5.2.1. Required Fields . . . . . . . . . . . . . . . . . . . 8 McCarthy-Howe Expires 29 March 2026 [Page 2] Internet-Draft vCon Lawful Basis September 2025 5.2.2. Optional Fields . . . . . . . . . . . . . . . . . . . 8 5.2.3. Purpose Grant Objects . . . . . . . . . . . . . . . . 9 5.2.4. Proof Mechanism Objects . . . . . . . . . . . . . . . 9 5.3. Example Lawful Basis Attachment . . . . . . . . . . . . . 10 6. Lawful Basis Processing Requirements . . . . . . . . . . . . 10 6.1. Content Hash Validation . . . . . . . . . . . . . . . . . 10 6.2. Temporal Validity . . . . . . . . . . . . . . . . . . . . 11 6.3. Reference Validation . . . . . . . . . . . . . . . . . . 11 6.4. Granular Permission Evaluation . . . . . . . . . . . . . 11 6.5. Proof Verification . . . . . . . . . . . . . . . . . . . 12 7. Transparency Service Integration . . . . . . . . . . . . . . 12 7.1. Registry Services . . . . . . . . . . . . . . . . . . . . 12 7.2. Registry Integration Requirements . . . . . . . . . . . . 12 7.3. Privacy Considerations for Registries . . . . . . . . . . 13 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 13 9. Interoperability . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10.1. Cryptographic Protection and Forgery . . . . . . . . . . 14 10.2. Replay Attack Prevention . . . . . . . . . . . . . . . . 15 10.3. Secure Communication Channels . . . . . . . . . . . . . 15 10.4. Audit Logging . . . . . . . . . . . . . . . . . . . . . 16 11. Privacy and Regulatory Compliance . . . . . . . . . . . . . . 16 11.1. Data Minimization . . . . . . . . . . . . . . . . . . . 16 11.2. Regulatory Alignment . . . . . . . . . . . . . . . . . . 16 11.3. Data Subject Rights . . . . . . . . . . . . . . . . . . 17 12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Security and Privacy Considerations Summary . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 19 A.1. vCon Extensions Names Registry . . . . . . . . . . . . . 19 A.2. Attachment Object Parameter Names Registry . . . . . . . 20 A.3. Lawful Basis Attachment Type Values Registry . . . . . . 20 A.4. Lawful Basis Content Hash Algorithm Values Registry . . . 21 A.5. Lawful Basis Content Hash Canonicalization Values Registry . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Conversations originating from all modes (voice, video, email, fax and messaging), contain sensitive information that requires a documented lawful basis for processing to comply with privacy regulations and ethical standards. This document defines a lawful basis extension for Virtualized Conversations (vCon) that enables automated lawful basis detection, structured recording, and McCarthy-Howe Expires 29 March 2026 [Page 3] Internet-Draft vCon Lawful Basis September 2025 cryptographic proof mechanisms. A vCon (Virtualized Conversation) is a standardized container format for storing conversation data, including metadata, participants, and conversation content, as defined in [I-D.draft-ietf-vcon-core-00]. The vCon specification supports extensible attachments that can carry additional structured data related to the conversation. This lawful basis extension provides a Compatible vCon extension (as defined in Section 2.5 of [I-D.draft-ietf-vcon-core-00]) that introduces lawful basis management capabilities through a standardized "lawful_basis" attachment type. The extension captures essential metadata including: * The specific lawful basis being asserted for processing * Party identification (for consent-based processing) * Temporal validity periods (where applicable) * Granular purpose-based permissions * Documented justifications for non-consent-based lawful bases * Cryptographic proof mechanisms and external verification * Integration with SCITT transparency services for audit trails The lawful basis extension addresses key privacy and compliance challenges while maintaining compatibility with existing vCon implementations. Implementations that do not recognize the lawful basis extension can safely ignore lawful basis attachments while maintaining valid processing of other vCon content. 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 [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Core Terms *Lawful Basis*: A valid justification, as defined by applicable law (e.g., GDPR), for the processing of personal data. One of six potential bases must be identified prior to processing. McCarthy-Howe Expires 29 March 2026 [Page 4] Internet-Draft vCon Lawful Basis September 2025 *Data Subject*: The identified or identifiable natural person to whom personal data relates [GDPR]. *Lawful Basis Attachment*: A vCon attachment with type "lawful_basis" that contains structured information documenting the lawful basis for processing conversation data. *Attestation Registry*: An external transparency service that maintains an authoritative, verifiable log of attestations about a vCon, which can include attestations of a lawful basis. This document defines integration with registries using the SCITT protocol. *Compatible Extension*: A vCon extension that introduces additional data without altering the meaning or structure of existing elements, as defined in [I-D.draft-ietf-vcon-core-00]. 3. Overview of Lawful Bases While this document defines an extension for recording any lawful basis for processing, it is important to understand the distinctions between them. Under regulations like the GDPR, there are six lawful bases for processing personal data. Consent is unique in that it is a permission granted by the data subject, while the other five are justifications asserted by the data controller. Understanding this distinction is critical for correctly implementing this extension. The six lawful bases for processing under GDPR are: 1. *Consent*: The data subject has given clear, unambiguous consent for their personal data to be processed for a specific purpose. This basis is unique because it originates with the data subject. 2. *Contract*: The processing is necessary for a contract that the data subject has with the organization, or because they have asked the organization to take specific steps before entering into a contract. For example, processing a customer's address to deliver a purchased product. 3. *Legal Obligation*: The processing is necessary for the organization to comply with the law (not including contractual obligations). For example, a financial institution may be legally required to report certain transactions to prevent fraud. 4. *Vital Interests*: The processing is necessary to protect someone's life. For example, sharing a patient's medical history with emergency services. McCarthy-Howe Expires 29 March 2026 [Page 5] Internet-Draft vCon Lawful Basis September 2025 5. *Public Task*: The processing is necessary for the organization to perform a task in the public interest or for its official functions, and the task or function has a clear basis in law. For example, a local authority processing data to provide public services. 6. *Legitimate Interests*: The processing is necessary for the organization's legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual's personal data which overrides those legitimate interests. For example, a business using customer data for marketing analysis to improve its services, provided it does not infringe on the customer's privacy rights. This lawful basis extension for vCon provides a standardized way to record and verify any of these lawful bases. The presence and content of a lawful_basis attachment are intended to be the primary mechanism for determining the authorized uses of a vCon's data. 4. vCon Lawful Basis Extension Definition 4.1. Extension Classification The lawful basis extension is a *Compatible Extension* as defined in Section 2.5 of [I-D.draft-ietf-vcon-core-00]. This extension: * Introduces additional lawful basis metadata without altering existing vCon semantics * Can be safely ignored by implementations that don't support lawful basis processing * Does not require listing in the must_support parameter * Maintains backward compatibility with existing vCon implementations 4.2. Extension Registration This document defines the "lawful_basis" extension token for registration in the vCon Extensions Names Registry: * *Extension Name*: lawful_basis * *Extension Description*: Lawful basis management for conversation participants with cryptographic proof mechanisms and regulatory compliance support McCarthy-Howe Expires 29 March 2026 [Page 6] Internet-Draft vCon Lawful Basis September 2025 * *Change Controller*: IESG * *Specification Document*: This document 4.3. Extension Usage vCon instances that include lawful basis attachments SHOULD include "lawful_basis" in the extensions array: json { "uuid": "01234567-89ab-cdef-0123-456789abcdef", "extensions": ["lawful_basis"], "created_at": "2025-01-02T12:00:00Z", "parties": [...], "dialog": [...], "attachments": [ { "type": "lawful_basis", "start": "2025-01-02T12:15:30Z", "party": 0, "dialog": 0, "encoding": "json", "body": { // Lawful basis data structure defined below } } ] } 5. Lawful Basis Attachment Structure 5.1. Attachment Container Lawful basis information MUST be included as vCon attachments using the standard attachment object structure defined in Section 4.4 of [I-D.draft-ietf-vcon-core-00]. The lawful basis attachment MUST include: * *type*: MUST be set to "lawful_basis" * *encoding*: MUST be set to "json" for structured lawful basis data * *body*: MUST contain the lawful basis data structure as defined below The lawful basis attachment SHOULD include: * *start*: ISO 8601 timestamp when lawful basis was recorded * *party*: Index of the party in the vCon parties array * *dialog*: Index of the associated dialog in the vCon dialog array 5.2. Lawful Basis Body Structure The body field of the lawful basis attachment MUST contain a JSON object with the following structure: McCarthy-Howe Expires 29 March 2026 [Page 7] Internet-Draft vCon Lawful Basis September 2025 5.2.1. Required Fields * *lawful_basis*: String enum from consent, contract, legal_obligation, vital_interests, public_task, legitimate_interests * *expiration*: ISO 8601 timestamp indicating when the lawful basis expires, or null for indefinite * *purpose_grants*: Array of purpose grant objects specifying permissions 5.2.2. Optional Fields * *terms_of_service*: URL reference to applicable terms of service document * *status_interval*: Duration string for revalidation intervals (e.g., "30d") * *content_hash*: An object containing content integrity information for the lawful basis attachment. The object has the following fields: - *algorithm*: (string, required) The hash algorithm used. This document defines initial values of "sha-256", "sha-3-256", and "blake2b-256". Other values may be registered in an IANA registry. - *canonicalization*: (string, required) The canonicalization method used. This document defines an initial value of "jcs" (JSON Canonicalization Scheme per RFC 8785). Other values may be registered in an IANA registry. - *value*: (string, required) The hexadecimal-encoded hash value of the canonicalized lawful basis attachment body. * *registry*: An object containing information about an external attestation registry for audit trails. The object has the following fields: - *type*: (string, required) The type of the attestation registry service. This document defines an initial value of "scitt". Other values may be registered in an IANA registry. - *url*: (string, required) The URL endpoint for the attestation registry service. McCarthy-Howe Expires 29 March 2026 [Page 8] Internet-Draft vCon Lawful Basis September 2025 * *proof_mechanisms*: Array of proof objects supporting the lawful basis * *metadata*: Additional implementation-specific metadata 5.2.3. Purpose Grant Objects Each object in the purpose_grants array MUST contain: * *purpose*: String identifying the processing purpose (e.g., "recording", "transcription", "analysis") * *granted*: Boolean indicating whether permission is granted (true) or denied (false) * *granted_at*: ISO 8601 timestamp when this specific permission was granted * *conditions*: Optional array of strings describing conditions or restrictions 5.2.4. Proof Mechanism Objects Each object in the proof_mechanisms array MUST contain: * *proof_type*: String identifying the proof mechanism type * *timestamp*: ISO 8601 timestamp when proof was created * *proof_data*: Object containing proof-type-specific data Supported proof types include: * *verbal_confirmation*: Lawful basis given verbally within the conversation * *signed_document*: External signed lawful basis form or agreement * *cryptographic_signature*: Digital signature using COSE standards * *external_system*: Lawful basis recorded in external system with API verification McCarthy-Howe Expires 29 March 2026 [Page 9] Internet-Draft vCon Lawful Basis September 2025 5.3. Example Lawful Basis Attachment json { "type": "lawful_basis", "start": "2025-01-02T12:15:30Z", "party": 0, "dialog": 0, "encoding": "json", "body": { "lawful_basis": "consent", "expiration": "2026-01-02T12:00:00Z", "purpose_grants": [ { "purpose": "recording", "granted": true, "granted_at": "2025-01-02T12:15:30Z" }, { "purpose": "transcription", "granted": true, "granted_at": "2025-01-02T12:15:30Z" }, { "purpose": "sentiment_analysis", "granted": false, "granted_at": "2025-01-02T12:15:30Z" } ], "proof_mechanisms": [ { "proof_type": "verbal_confirmation", "timestamp": "2025-01-02T12:15:30Z", "proof_data": { "dialog_reference": 0, "time_offset": "00:01:23", "confirmation_text": "Yes, I consent to recording this call" } } ], "terms_of_service": "https://example.com/terms/v2024.1", "status_interval": "30d", "content_hash": { "algorithm": "sha-256", "canonicalization": "jcs", "value": "a1b2c3d4e5f6789abcdef0123456789abcdef0123456789abcdef0123456789ab" }, "registry": { "type": "scitt", "url": "https://transparency.example.com/lawful_purpose/registry" } } } 6. Lawful Basis Processing Requirements 6.1. Content Hash Validation Implementations MUST validate content hashes when present in lawful basis attachments: 1. *Canonicalization*: Apply the specified canonicalization method to the lawful basis attachment body * For "jcs" canonicalization: Use JSON Canonicalization Scheme per RFC 8785 * Sort object keys lexicographically * Remove insignificant whitespace * Ensure consistent number representations 2. *Hash Computation*: Compute the hash using the specified algorithm * For "sha-256": Use SHA-256 algorithm * For "sha-3-256": Use SHA-3-256 algorithm * For "blake2b-256": Use BLAKE2b-256 algorithm McCarthy-Howe Expires 29 March 2026 [Page 10] Internet-Draft vCon Lawful Basis September 2025 3. *Hash Verification*: Compare computed hash with the provided value * Reject processing if hashes do not match * Log hash validation results for audit purposes 4. *Error Handling*: Provide specific error reporting for hash validation failures * *ContentHashMismatchError*: Computed hash does not match provided value * *UnsupportedHashAlgorithmError*: Hash algorithm not supported by implementation * *UnsupportedCanonicalizationError*: Canonicalization method not supported by implementation 6.2. Temporal Validity Implementations MUST validate lawful basis expiration before processing: 1. Compare current time against expiration timestamp 2. Account for reasonable clock skew (maximum 5 minutes recommended) 3. Reject processing if lawful basis has expired 4. Support null expiration for indefinite validity subject to revalidation intervals 6.3. Reference Validation Implementations MUST validate attachment references: 1. Verify party index exists in vCon parties array 2. Verify dialog indices exist in vCon dialog array 6.4. Granular Permission Evaluation When processing vCon content, implementations MUST: 1. Check for applicable lawful basis attachments for the requested processing purpose McCarthy-Howe Expires 29 March 2026 [Page 11] Internet-Draft vCon Lawful Basis September 2025 2. Evaluate all relevant purpose grants for the specific purpose 3. Apply most restrictive permission when multiple grants apply 4. Deny processing if no valid permission exists or if it is explicitly denied 6.5. Proof Verification Implementations SHOULD verify proof mechanisms when present: 1. Validate cryptographic signatures using appropriate algorithms 2. Verify external document integrity using content hashes 3. Check external system lawful basis status via API calls 4. Log proof verification results for audit purposes 7. Transparency Service Integration 7.1. Registry Services The optional registry field enables integration with external attestation registries for audit trails. The registry object's type field specifies the protocol to be used. When the registry object is present and its type is "scitt", the url field MUST: * Reference a SCITT (Supply Chain Integrity, Transparency, and Trust) Transparency Service implementing SCRAPI [I-D.draft-ietf-scitt-scrapi-05] * Provide cryptographic receipts for state changes * Support status queries and updates * Implement appropriate access controls and privacy protections Other transparency service types may be used if they are registered with IANA. The documentation for each registered type must specify the necessary protocols and interaction models. 7.2. Registry Integration Requirements Implementations that support registries MUST: McCarthy-Howe Expires 29 March 2026 [Page 12] Internet-Draft vCon Lawful Basis September 2025 1. Use HTTPS with TLS 1.2 or higher for all communications 2. Implement appropriate authentication mechanisms 3. Validate SCITT receipts using standard verification procedures 4. Handle service unavailability gracefully 5. Cache lawful basis state within configured intervals 7.3. Privacy Considerations for Registries Registry services SHOULD: * Store only lawful basis metadata, not full conversation content * Implement privacy-preserving query mechanisms * Maintain audit logs for regulatory compliance * Support deletion and other personal data compliance responsibilities 8. Error Handling Implementations SHOULD provide specific error reporting: * *LawfulBasisExpiredError*: Lawful basis has expired and cannot be used * *PermissionDeniedError*: Permission explicitly denies the requested processing * *LawfulBasisMissingError*: No valid lawful basis found for the requested processing * *ProofVerificationError*: Lawful basis proof mechanisms failed validation * *ReferenceValidationError*: Attachment references invalid vCon elements * *ContentHashMismatchError*: Computed hash does not match provided value * *UnsupportedHashAlgorithmError*: Hash algorithm not supported by implementation McCarthy-Howe Expires 29 March 2026 [Page 13] Internet-Draft vCon Lawful Basis September 2025 * *UnsupportedCanonicalizationError*: Canonicalization method not supported by implementation 9. Interoperability To ensure interoperability across implementations: * Use only standard JSON data types in lawful basis body structures * Support graceful degradation when advanced features are unavailable * Implement lawful basis attachment format negotiation for multi- party exchanges 10. Security Considerations The vcon-core specification provides general-purpose security mechanisms, such as digital signatures, designed to ensure the basic integrity of the vCon container. These mechanisms answer the question, "Has this vCon been tampered with?" However, managing lawful basis requires addressing a more specific and legally significant question: "Did this specific person provide a valid basis for this specific action at a specific time?" Answering this question requires a higher level of security and contextual awareness. The following sections detail the additional security considerations that are critical for a lawful basis mechanism to be considered trustworthy and compliant with privacy regulations. 10.1. Cryptographic Protection and Forgery *Background:* Forgery is the act of creating a fake record or altering an existing one—for instance, by changing the expiration date, expanding the scope of what was agreed to, or faking the identity of the party. The ability to prove that a lawful basis is authentic and unaltered is the bedrock of any privacy compliance framework like GDPR or CCPA. A forged record is equivalent to having no lawful basis at all and carries severe legal and financial penalties. While vcon-core provides a signature field, this extension adds the necessary business rules to ensure that a signature represents a trusted, verifiable, and legally binding act. *Requirements:* Implementations MUST prevent forgery through: * Cryptographic signature verification for digital proof mechanisms. * External document integrity validation using content hashes. McCarthy-Howe Expires 29 March 2026 [Page 14] Internet-Draft vCon Lawful Basis September 2025 * Secure communication channels for external verification. * Audit logging of all validation activities. 10.2. Replay Attack Prevention *Background:* A replay attack involves an attacker copying a valid lawful basis attachment from one vCon and maliciously inserting it into a different vCon that the user never actually provided a basis for. Without replay protection, a user's lawful basis for a non- sensitive inquiry could be "replayed" to appear as if they provided it for the recording and analysis of a highly sensitive conversation. This would be a massive privacy violation and would render the mechanism meaningless. *Requirements:* The lawful basis attachment design MUST prevent replay attacks through: * Cryptographic binding to specific vCon instances. * Timestamp validation with appropriate clock skew tolerance. * Nonce inclusion in proof mechanisms where applicable. * Reference validation to ensure lawful basis applies to correct content. 10.3. Secure Communication Channels *Background:* Lawful basis records are themselves sensitive personal data. It is critical that they are protected while in transit between systems. An attacker in a "man-in-the-middle" position could intercept a vCon and alter it before it reaches its destination, potentially stripping or modifying lawful basis information. *Requirements:* All lawful basis attachments MUST be integrity protected using vCon signing mechanisms as defined in [I-D.draft-ietf-vcon-core-00]. Lawful basis attachments containing sensitive information SHOULD be encrypted when transmitted outside secure environments, for instance by using TLS 1.2 or higher for all communications. McCarthy-Howe Expires 29 March 2026 [Page 15] Internet-Draft vCon Lawful Basis September 2025 10.4. Audit Logging *Background:* Lawful basis is a matter of legal and regulatory compliance. If a dispute arises, the organization processing the data must be able to _prove_ it had a valid lawful basis at the time of the action. An audit log provides this crucial, non-repudiable evidence for regulators, auditors, and courts. It is a cornerstone of the "accountability" principle in modern privacy law. *Requirements:* Systems that process or manage lawful basis attachments SHOULD maintain a secure, immutable record of all related activities (e.g., when a lawful basis was given, checked, revoked, or expired). When a registry is used, this requirement may be fulfilled by the registry service. 11. Privacy and Regulatory Compliance 11.1. Data Minimization Lawful basis attachments MUST implement data minimization principles by: * Including only information necessary for verification * Avoiding duplication of personal data already in vCon elements * Supporting attachment redaction while maintaining verifiability * Implementing privacy-preserving verification mechanisms 11.2. Regulatory Alignment The lawful basis extension addresses requirements from major privacy regulations: * *GDPR Article 7*: Conditions for lawful basis including withdrawal mechanisms * *CCPA Section 1798.135*: Requirements for personal information processing * *HIPAA Privacy Rule*: Requirements for protected health information Implementers MUST ensure their implementations comply with applicable regulations in their jurisdiction. McCarthy-Howe Expires 29 March 2026 [Page 16] Internet-Draft vCon Lawful Basis September 2025 11.3. Data Subject Rights Implementations MUST support data subject rights including: * *Right of Access*: Enable data subjects to access their records * *Right of Rectification*: Allow correction of inaccurate information * *Right to be Forgotten*: Support deletion and data erasure * *Right of Portability*: Enable export of data in interoperable formats * *Withdrawal*: Provide mechanisms for revocation of a lawful basis 12. Conclusion This document defines a comprehensive lawful basis extension for vCon that balances privacy protection with practical implementation requirements. The extension provides a foundation for lawful basis- aware conversation processing while maintaining compatibility with existing vCon infrastructure. 13. Security and Privacy Considerations Summary This lawful basis extension addresses several critical security and privacy concerns: *Integrity*: Cryptographic protection prevents unauthorized modification of records while maintaining verifiability across system boundaries. *Temporal Security*: Expiration controls and revalidation intervals ensure a lawful basis cannot be misused beyond its intended temporal scope. *Audit Transparency*: SCITT integration provides cryptographic audit trails for operations while maintaining privacy protections. *Regulatory Compliance*: Structured management supports compliance with GDPR, CCPA, HIPAA and other privacy regulations through standardized metadata and processing controls. *Data Minimization*: Privacy-preserving design minimizes data collection and supports lawful basis-driven access controls throughout the conversation lifecycle. McCarthy-Howe Expires 29 March 2026 [Page 17] Internet-Draft vCon Lawful Basis September 2025 Implementers should conduct thorough security reviews and ensure compliance with applicable privacy regulations in their deployment environments. 14. References 14.1. Normative References [I-D.draft-ietf-scitt-scrapi-05] Birkholz, H., "SCITT Receipt API", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-05, February 2025, . [I-D.draft-ietf-vcon-core-00] Petrie, D., "Virtualized Conversation (vCon) Container", Work in Progress, Internet-Draft, draft-ietf-vcon-core-00, March 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G., "Date and Time on the Internet: Timestamps", July 2002, . [RFC7693] Saarinen, M., "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", November 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., "JSON Canonicalization Scheme (JCS)", June 2020, . [RFC8949] Bormann, C., "Concise Binary Object Representation (CBOR)", December 2020, . 14.2. Informative References [CCPA] State of California, "California Consumer Privacy Act", 2018, . [COSE-ALG] IANA, "COSE Algorithms", September 2025, . McCarthy-Howe Expires 29 March 2026 [Page 18] Internet-Draft vCon Lawful Basis September 2025 [FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, . [FIPS-202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", August 2015, . [GDPR] European Union, "General Data Protection Regulation", 2018, . [HIPAA] U.S. Department of Health and Human Services, "Health Insurance Portability and Accountability Act", 1996, . [I-D.draft-ietf-vcon-overview] McCarthy-Howe, T., "The vCon - Conversation Data Container - Overview", Work in Progress, Internet-Draft, draft-ietf- vcon-overview-00, July 2025, . [NIST-PRIVACY] National Institute of Standards and Technology, "NIST Privacy Framework", 2020, . Appendix A. IANA Considerations A.1. vCon Extensions Names Registry This document requests IANA to register the following extension in the vCon Extensions Names Registry established by [I-D.draft-ietf-vcon-core-00]: * *Extension Name*: lawful_basis * *Extension Description*: Lawful basis management for conversation participants with cryptographic proof mechanisms and regulatory compliance support * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX McCarthy-Howe Expires 29 March 2026 [Page 19] Internet-Draft vCon Lawful Basis September 2025 A.2. Attachment Object Parameter Names Registry This document requests IANA to register the following parameter in the Attachment Object Parameter Names Registry: * *Parameter Name*: type * *Parameter Description*: Semantic type identifier for attachment content * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX, Section 4 Note: This addresses the "TODO: type or purpose" noted in Section 6.3.6 of [I-D.draft-ietf-vcon-core-00]. A.3. Lawful Basis Attachment Type Values Registry This document requests IANA to establish a new registry for lawful basis attachment type values with the following initial registration: * *Type Value*: lawful_basis * *Description*: Structured lawful purpose records with temporal validity and cryptographic proof mechanisms * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX Registration Template: *Type Value*: The string value used as the attachment type identifier *Description*: Brief description of the attachment type and its purpose *Change Controller*: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. *Specification Document(s)*: Reference to defining documents with URIs where available ## Lawful Basis Registry Type Values Registry This document requests IANA to establish a new registry for lawful basis registry type values with the following initial registration: * *Type Value*: scitt McCarthy-Howe Expires 29 March 2026 [Page 20] Internet-Draft vCon Lawful Basis September 2025 * *Description*: A transparency service implementing the SCITT (Supply Chain Integrity, Transparency, and Trust) protocol. * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX, [I-D.draft-ietf-scitt-scrapi-05] Registration Template: *Type Value*: The string value used as the registry type identifier *Description*: Brief description of the registry type and its purpose *Change Controller*: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. *Specification Document(s)*: Reference to defining documents with URIs where available A.4. Lawful Basis Content Hash Algorithm Values Registry This document requests IANA to establish a new registry for lawful basis content hash algorithm values with the following initial registrations: * *Algorithm Value*: sha-256 * *Description*: SHA-256 hash algorithm as defined in FIPS 180-4 * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX, [FIPS-180-4] * *Algorithm Value*: sha-3-256 * *Description*: SHA-3-256 hash algorithm as defined in FIPS 202 * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX, [FIPS-202] * *Algorithm Value*: blake2b-256 * *Description*: BLAKE2b-256 hash algorithm as defined in RFC 7693 * *Change Controller*: IESG McCarthy-Howe Expires 29 March 2026 [Page 21] Internet-Draft vCon Lawful Basis September 2025 * *Specification Document(s)*: RFC XXXX, [RFC7693] Registration Template: *Algorithm Value*: The string value used as the hash algorithm identifier *Description*: Brief description of the hash algorithm and its purpose *Change Controller*: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. *Specification Document(s)*: Reference to defining documents with URIs where available A.5. Lawful Basis Content Hash Canonicalization Values Registry This document requests IANA to establish a new registry for lawful basis content hash canonicalization values with the following initial registration: * *Canonicalization Value*: jcs * *Description*: JSON Canonicalization Scheme as defined in RFC 8785 * *Change Controller*: IESG * *Specification Document(s)*: RFC XXXX, [RFC8785] Registration Template: *Canonicalization Value*: The string value used as the canonicalization method identifier *Description*: Brief description of the canonicalization method and its purpose *Change Controller*: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. *Specification Document(s)*: Reference to defining documents with URIs where available McCarthy-Howe Expires 29 March 2026 [Page 22] Internet-Draft vCon Lawful Basis September 2025 Appendix B. Acknowledgements * Appreciation to Vinnie Micciche for his unwavering support during the development of this lawful basis attachment in particular, and vCons in general. Author's Address Thomas McCarthy-Howe Strolid Email: ghostofbasho@gmail.com McCarthy-Howe Expires 29 March 2026 [Page 23]