Voice Conversation (vCon) Consent Attachment

2.1. Core Terms

Consent: Any freely given, specific, informed, and unambiguous indication of the data subject's wishes by which they, by a statement or by a clear affirmative action, signify agreement to the processing of personal data relating to them [GDPR].¶

Data Subject: The identified or identifiable natural person to whom personal data relates [GDPR]. Also referred to as "consumer" in some jurisdictions [CCPA].¶

Data Controller: The natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data [GDPR].¶

Data Processor: A natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller [GDPR].¶

Personal Data: Any information relating to an identified or identifiable natural person [GDPR].¶

Processing: Any operation or set of operations performed on personal data [GDPR].¶

2.2. vCon-Specific Terms

vCon: A standardized container for conversational information, including metadata, participants, dialog content, analysis, and attachments [I-D.draft-ietf-vcon-vcon-container].¶

vCon Instance: A vCon populated with data for a specific conversation [I-D.draft-ietf-vcon-vcon-container].¶

vCon Instance Version: A single version of an instance of a conversation, which may be modified to redact or append additional information [I-D.draft-ietf-vcon-vcon-container].¶

Party: An observer or participant to the conversation, either passive or active [I-D.draft-ietf-vcon-vcon-container].¶

Dialog: The captured conversation in its original form (e.g., text, audio, or video) [I-D.draft-ietf-vcon-vcon-container].¶

Analysis: Analysis, transformations, summary, sentiment, or translation typically of the dialog data [I-D.draft-ietf-vcon-vcon-container].¶

Attachment: A data block either included or referenced in a vCon [I-D.draft-ietf-vcon-vcon-container].¶

2.3. Consent-Specific Terms

Consent Attachment: A vCon attachment of type "consent" that contains structured consent information for one or more parties to a conversation.¶

Consent Statement: A structured representation of consent that includes the consenting party, purposes, temporal validity, and proof mechanisms.¶

Consent Ledger: A SCITT Transparency Service that maintains authoritative consent state and provides cryptographic receipts for consent operations.¶

Consent Proof: Cryptographic or other evidence that validates the authenticity and integrity of a consent statement.¶

Consent Purpose: A specific use case or processing activity for which consent is granted or denied.¶

Consent Status: The current state of consent (granted, denied, revoked, expired) for a specific purpose.¶

Consent Expiration: The point in time when consent becomes invalid, either through explicit expiration or revocation.¶

Consent Revocation: The withdrawal of previously granted consent by the data subject.¶

Consent Verification: The process of validating that consent is current, valid, and applicable to the requested processing activity.¶

2.4. Technical Terms

SCITT: Supply Chain Integrity, Transparency, and Trust - a protocol for maintaining append-only transparency ledgers [I-D.draft-ietf-scitt-scrapi-05].¶

SCRAPI: SCITT Receipt API - the interface for interacting with SCITT Transparency Services [I-D.draft-ietf-scitt-scrapi-05].¶

COSE: CBOR Object Signing and Encryption - a standard for creating and processing signed, encrypted, and MACed objects [RFC8949].¶

COSE Sign1: A COSE structure containing a single signature [RFC8949].¶

AI Preferences Vocabulary: A standardized vocabulary for expressing preferences related to automated processing systems [I-D.draft-ietf-aipref-vocab-01].¶

Clock Skew: The difference in time between different systems, which must be accounted for when validating temporal constraints.¶

Referential Integrity: The consistency of references between consent attachments and the vCon elements they reference.¶

Data Minimization: The principle of limiting personal data collection to what is necessary for the specified purpose [GDPR].¶

Privacy by Design: The principle of embedding privacy considerations into the design and architecture of systems and processes [NIST-PRIVACY].¶

2.5. Regulatory Terms

GDPR: General Data Protection Regulation - the primary data protection law in the European Union [GDPR].¶

CCPA: California Consumer Privacy Act - a state statute intended to enhance privacy rights and consumer protection for residents of California [CCPA].¶

HIPAA: Health Insurance Portability and Accountability Act - a US law that provides data privacy and security provisions for safeguarding medical information [HIPAA].¶

Right to be Forgotten: The right of data subjects to have their personal data erased [GDPR].¶

Right of Access: The right of data subjects to obtain confirmation of whether their personal data is being processed and access to that data [GDPR].¶

Right of Rectification: The right of data subjects to have inaccurate personal data corrected [GDPR].¶

Right of Portability: The right of data subjects to receive their personal data in a structured, commonly used, machine-readable format [GDPR].¶

Lawful Basis: One of the six legal grounds for processing personal data under GDPR: consent, contract, legal obligation, vital interests, public task, or legitimate interests [GDPR].¶

3.1. Consent Attachment Requirements Summary

The vCon consent specification establishes standardized requirements for managing consent information within voice conversation containers. The specification addresses privacy compliance challenges through structured consent attachments that capture essential metadata and proof mechanisms.¶

3.2. Consent Attachment Structure

The consent attachment MUST be a JSON object that is included in the vCon attachments array. The consent attachment MUST contain the following top-level fields: "expiration", "party", "dialog" and "consents". Implementations MUST reject consent attachments that are missing any of these required fields.¶

The consent attachment MAY contain the following top-level fields "terms_of_service", "status_interval", "consent_ledger", "proof".¶

The consent attachment SHOULD include appropriate metadata fields as defined in the base vCon attachment specification, including "type", "start", and "signature" fields when applicable.¶

3.3. Temporal Validity and Expiration

The "expiration" field MUST contain a timestamp in RFC3339 format indicating when the consent becomes invalid. Implementations MUST compare the current time against this expiration timestamp and SHALL reject expired consent attachments.¶

The expiration timestamp MAY be set to null to indicate indefinite consent duration, as defined by local policy or applicable regulations. When the expiration field is null, the consent is considered valid indefinitely until explicitly revoked. However, implementations SHOULD provide mechanisms for periodic consent revalidation even when indefinite consent is granted.¶

When processing consent attachments, implementations MUST account for clock skew and SHOULD allow for reasonable time differences between systems. The acceptable clock skew tolerance SHOULD be configurable but MUST NOT exceed 5 minutes by default.¶

3.4. Terms of Service Integration

The "terms_of_service" field MUST contain either a URI reference to the applicable terms of service document or an embedded terms object. When using URI references, implementations MUST support HTTPS URLs and SHOULD support content integrity verification through cryptographic hashes.¶

The terms of service reference MUST be immutable for the lifetime of the consent attachment. If terms of service change, a new consent attachment MUST be created rather than modifying the existing reference.¶

Implementations SHOULD maintain a local cache of terms of service documents to ensure availability during consent verification. The cache SHOULD respect HTTP cache control headers when fetching terms documents via URI.¶

3.5. Party and Dialog References

The "party" field MUST contain a zero-based integer index referencing an entry in the vCon parties array. Implementations MUST validate that the referenced party index exists in the vCon and SHOULD verify that the party has authority to grant consent for the specified dialog.¶

The "dialog" field MUST contain a zero-based integer index referencing an entry in the vCon dialog array. Multiple consent attachments MAY reference the same dialog entry to represent consent from different parties or for different purposes.¶

Implementations MUST maintain referential integrity between consent attachments and the referenced vCon elements. When a vCon is modified through redaction or amendment, consent attachment references MUST be updated accordingly or the consent MUST be invalidated.¶

3.6. Status Monitoring and Intervals

The "status_interval" field MUST specify the maximum time interval, in seconds, between consent status verifications. Implementations MUST perform consent status checks at least as frequently as specified by this interval.¶

The status interval MUST be a positive integer value. A status interval of zero indicates that consent status MUST be verified on every access to the associated dialog content.¶

3.7. Consent Ledger Integration

The "consent_ledger" field SHOULD contain a URL referencing a SCITT Transparency Service that maintains the authoritative consent state. Implementations MAY use this URL to verify current consent status and detect consent revocations.¶

3.8. Cryptographic Proof Requirements

The "proof" field MUST contain an array of proof objects that provide cryptographic evidence of valid consent. Each proof object MUST include a "type" field specifying the proof mechanism and a "value" field containing the proof data.¶

Proof objects MAY include various types of evidence: - Dialog-based proofs: Consent statements or confirmations given verbally or textually within the conversation dialog itself - External document proofs: Signed consent forms, terms of service agreements, or other legal documents referenced by URL or embedded content - External site proofs: Consent granted through web interfaces, mobile applications, or other external systems that provide cryptographic attestation¶

Implementations MUST support digital signature proofs using algorithms specified in the IANA COSE Algorithms registry [COSE-ALG]. The proof SHOULD include a timestamp indicating when the consent was granted and MUST include a reference to the consenting party's cryptographic identity.¶

When multiple proofs are present, implementations MUST verify all proofs and SHALL reject the consent attachment if any proof fails validation. The proof verification process MUST include validation of the signing key authority and certificate chain when applicable.¶

Proof objects MAY reference external proof data to minimize consent attachment size. When external references are used, implementations MUST verify the integrity of externally referenced proof data using cryptographic hashes included in the proof object.¶

3.9. Granular Consent Management

The "consents" field MUST contain an array of consent objects, each specifying a particular permission granted by the consenting party. Each consent object MUST include a "purpose" field identifying the specific use case and a "status" field indicating whether consent is granted or denied.¶

Standard consent purposes MUST include "recording", "transcription", "analysis", "storage", and "sharing". Implementations MAY define additional purpose categories but SHOULD use standardized purpose taxonomies when available.¶

3.10. Consent Withdrawal and Revocation

Implementations MUST support consent withdrawal mechanisms that allow data subjects to revoke previously granted consent. When consent is revoked, the consent status in the ledger service MUST be updated immediately and all processing of the associated dialog content MUST cease.¶

The consent withdrawal process MUST provide confirmation to the data subject and SHOULD include a timestamp of when the revocation became effective. Implementations MUST honor consent revocations even if they cannot immediately delete or modify existing vCon instances.¶

When consent is revoked, implementations SHOULD notify all parties that have received copies of the vCon containing the revoked consent. The notification mechanism MAY use the SCITT transparency service integration described in related vCon lifecycle specifications.¶

3.11. Privacy and Data Minimization

Consent attachments MUST implement data minimization principles by including only information necessary for consent verification and audit purposes. Personal information SHOULD NOT be duplicated in consent attachments when it is already available in the referenced vCon elements.¶

The consent attachment design MUST support privacy-preserving verification mechanisms that allow consent validation without exposing sensitive personal information to all parties in a consent verification workflow.¶

Implementations SHOULD support consent attachment redaction techniques that allow sensitive consent details to be removed while maintaining the ability to verify that valid consent was originally present.¶

3.12. Error Handling and Validation

Implementations MUST validate consent attachment syntax according to the JSON schema defined in this specification. Malformed consent attachments MUST be rejected with appropriate error messages indicating the specific validation failures.¶

When consent validation fails, implementations MUST NOT process the associated dialog content and SHOULD log the failure for audit purposes. The error handling process MUST distinguish between temporary failures (such as network timeouts during ledger verification) and permanent failures (such as invalid cryptographic proofs).¶

Implementations SHOULD provide detailed error reporting to assist with troubleshooting consent validation issues while avoiding exposure of sensitive information in error messages.¶

3.13. Interoperability and Versioning

Consent attachments MUST include version information to support evolution of the consent attachment specification. Implementations MUST handle version mismatches gracefully and SHOULD support multiple consent attachment versions during transition periods.¶

The consent attachment format MUST be designed to support extensions while maintaining backward compatibility with existing implementations. New fields MAY be added to consent attachments but MUST NOT break existing validation logic.¶

Implementations SHOULD support consent attachment format negotiation when multiple parties exchange vCons with different consent attachment version support.¶

3.14. Security Considerations

All consent attachments MUST be integrity protected using the vCon signing mechanisms. Consent attachments containing sensitive information SHOULD be encrypted when the vCon is transmitted outside secure environments.¶

Implementations MUST protect consent ledger communications using TLS and SHOULD implement additional authentication mechanisms to prevent unauthorized consent status queries or modifications.¶

The consent attachment design MUST prevent replay attacks and consent forgery through appropriate use of timestamps, nonces, and cryptographic binding to the specific vCon instance and dialog content.¶

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.¶

{
  "expiration": "2026-01-02T12:00:00Z",
  "terms_of_service": "https://example.com/terms",
  "party": 0,
  "dialog": 0,
  "status_interval": "30d",
  "consent_ledger": "https://ledger.example.com/consent/123",
  "proof": [
    {
      "timestamp": "2025-01-02T12:15:30Z",
      "type": "verbal_confirmation"
    },
    {
      "url": "https://example.com/consent-form.pdf",
      "type": "external_asset"
    }
  ],
  "consents": [
    {
      "value": true,
      "consent": "recording"
    },
    {
      "value": true,
      "consent": "transcription"
    },
    {
      "value": true,
      "consent": "analysis"
    }
  ]
}

3.15. Attachment Fields

3.16. Consent Objects

Each consent object MUST contain:¶

• value: Boolean indicating consent status (true for granted, false for denied)¶

• consent: String identifying the consent type (e.g., "recording", "transcription", "analysis")¶

3.17. Proof Objects

Proof objects provide evidence of consent and MAY contain:¶

• timestamp: ISO 8601 timestamp when consent was given¶

• type: Proof type identifier (e.g., "verbal_confirmation", "external_asset")¶

• url: URL to external proof document (for external_asset type)¶

4.1. vCon Attachment Type Registration

This document requests IANA to register the following vCon attachment type:¶

• Type: consent¶

• Description: Consent information for voice conversation participants¶

• Reference: This document¶

5.1. Creating a Consent Attachment

To create a consent attachment for a vCon:¶

1. Identify the consenting party: Reference the party index in the vCon parties array¶

2. Specify the dialog segment: Reference the dialog index in the vCon dialog array¶

3. Define consent permissions: Create consent objects for each purpose¶

4. Set expiration: Define when the consent expires¶

5. Add proof mechanisms: Include cryptographic or other proof of consent¶

6. Include in vCon: Add the attachment to the vCon attachments array¶

5.2. Example Usage

json { "type": "consent", "start": "2025-01-02T12:15:30Z", "expiration": "2026-01-02T12:00:00Z", "party": 0, "dialog": 0, "consents": [ { "purpose": "recording", "status": "granted", "timestamp": "2025-01-02T12:15:30Z" } ], "proof": [ { "type": "verbal_confirmation", "timestamp": "2025-01-02T12:15:30Z" } ] } ¶

5.3. Processing Consent Attachments

When processing a vCon with consent attachments:¶

1. Validate structure: Ensure all required fields are present¶

2. Check expiration: Verify the consent hasn't expired¶

3. Verify references: Ensure party and dialog indices are valid¶

4. Validate proofs: Verify cryptographic or other proof mechanisms¶

5. Check ledger status: If a consent ledger is specified, verify current status¶

6. Apply permissions: Use consent status to determine allowed operations¶

7.1. Cryptographic Protection

• All consent attachments MUST be integrity protected using vCon signing mechanisms¶

• Consent attachments containing sensitive information SHOULD be encrypted when transmitted outside secure environments¶

• Implementations MUST use strong cryptographic algorithms as specified in [COSE-ALG]¶

7.2. Access Control

• Implementations MUST implement appropriate access controls for consent data¶

• Consent verification SHOULD be performed with minimal privilege¶

• Audit logging MUST be implemented for all consent operations¶

7.3. Network Security

• All communications with consent ledger services MUST use TLS 1.2 or higher¶

• Implementations MUST validate certificate chains and hostnames¶

• Implementations SHOULD implement certificate pinning for critical services¶

7.4. Data Protection

• Consent data SHOULD be encrypted at rest¶

• Implementations MUST implement secure key management¶

• Implementations SHOULD support hardware security modules for key storage¶

7.5. Threat Mitigation

• Implementations MUST prevent replay attacks through proper use of timestamps and nonces¶

• Implementations MUST validate all cryptographic proofs to prevent forgery¶

• Implementations SHOULD implement rate limiting to prevent abuse¶

8.1. Normative References

[I-D.draft-ietf-aipref-vocab-01]

Keller, P. and M. Thomson, "A Vocabulary For Expressing AI Usage Preferences", Work in Progress, Internet-Draft, draft-ietf-aipref-vocab-01, 18 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-01>.

[I-D.draft-ietf-scitt-scrapi-05]

Birkholz, H. and J. Geater, "SCITT Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-05, 2 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-05>.

[I-D.draft-ietf-vcon-vcon-container]

Petrie, D. and T. McCarthy-Howe, "The JSON format for vCon - Conversation Data Container", Work in Progress, Internet-Draft, draft-ietf-vcon-vcon-container-03, 19 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-vcon-vcon-container-03>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8949]

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>.

8.2. Informative References

[CCPA]

State of California, "California Consumer Privacy Act", 2018, <https://oag.ca.gov/privacy/ccpa>.

[COSE-ALG]

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

[GDPR]

European Union, "General Data Protection Regulation", 2018, <https://gdpr.eu/>.

[HIPAA]

U.S. Department of Health and Human Services, "Health Insurance Portability and Accountability Act", 1996, <https://www.hhs.gov/hipaa/index.html>.

[NIST-PRIVACY]

National Institute of Standards and Technology, "NIST Privacy Framework", 2020, <https://www.nist.gov/privacy-framework>.