Summary

  • The vCon overview revision 02 and core revision 04 are IETF works in progress. They define a flexible conversation-data container whose four major parts are optional and whose scope is selected by its creator.
  • JWS can establish the integrity of the signed payload and possession of a signing key. It does not by itself establish complete capture, correct party identity, valid consent, accurate analysis or the signer's authority for a downstream use.
  • Amendment chains preserve successive signed states. A decision-grade system still needs an evidence ledger that binds every relied-on claim to its source, scope, lineage, purpose and accountable authority.

The review room has all the signs of success. The vCon signature is valid. Its certificate chain builds. The SHA-512 value for an externally stored recording matches the bytes that were retrieved. A newer vCon names the older UUID in its amended object, and both payloads are intact.

Then the reviewer asks for the second recording leg. The URL returns 403. The amended version changes one party's identity from an account alias to a named person, but says only that credentials were used for validation. A sentiment result names its vendor but not the model or language configuration. The consent statement predates the new analysis purpose. Every cryptographic lamp remains green; the decision has become less certain.

That is not a cryptographic failure. It is a category error about what the cryptography was asked to prove.

draft-ietf-vcon-overview-02, dated 30 September 2026, and draft-ietf-vcon-vcon-core-04, dated 7 September 2026, describe a JSON container for information about human conversations. The overview is an Informational-track working-group Internet-Draft; the core is also an active working-group Internet-Draft. Neither is an RFC or a finished standard. Their architecture is valuable precisely because it makes conversational material portable across communications platforms, analysis services and security domains. Portability, however, moves claims as well as bytes. A receiver needs to know which kind of assurance travelled with each one.

One package, five different questions

A vCon can hold or reference parties, dialog, attachments and analysis. It can be signed with JWS and, when confidentiality is needed, encrypted with JWE after signing. The signature protects an exact payload from undetected change and demonstrates possession of the signing key under the verifier's trust rules. That is substantial. It is not the same as answering five questions that interfaces often compress into one word, “verified.”

First is integrity: are these the bytes the signer signed? Second is signer authentication: what identity does the verified key and certificate chain actually establish? Third is capture provenance: which systems observed, transformed or supplied each item? Fourth is semantic truth: are the participant, timestamp, transcript, sentiment and consent claims accurate? Fifth is authority: was the signer entitled to collect, change, disclose and rely on those claims for this purpose?

JWS directly supports the first question and can support the second. The vCon structure can carry evidence for the third. The fourth and fifth remain decisions about the world outside the payload. A signed false claim is still false. A signed accurate claim can still have been made or used without the necessary authority.

The distinction is not a reason to distrust signatures. It is the reason to label their result precisely. “Payload integrity valid” is an actionable fact. “Conversation verified” is an undocumented conclusion unless the receiver can show the other four decisions.

The creator chooses what the conversation contains

The overview treats a conversation as a definition rather than a natural scalar. One vCon may contain a single audio recording. Another may span an initial message, a call and a follow-up email. Modes such as SMS have no obvious session boundary, so somebody has to decide where the record begins and ends.

That somebody has considerable control. All four major sections—parties, dialog, attachments and analysis—are optional. The overview says a recording without a parties definition can be a valid expression. The core permits placeholder dialog objects when little is known and distinguishes recordings, recording sets, text, transfers and incomplete calls. It notes that one recording object may contain only a leg or subset of a session and need not identify every participant.

A conforming container can therefore be partial by design. That may be correct data minimisation, an honest operational gap or a misleading selection. Syntax cannot tell the receiver which. Nor can a signature: it freezes the selected scope; it does not prove the scope was complete.

Before a consequential use, a receiver needs a scope declaration: the purported start and end, channels, transfer legs, participating systems, known omissions, capture policy and identity of the operator that selected them. The declaration may itself be signed, but the important question is whether independent operational evidence—call-control events, message IDs, recorder health or another system's logs—supports it.

This is where the draft's phrase “ground truths” needs care. The overview calls dialog the ground truths of a conversation because dialog is the primary captured exchange rather than a later inference. The phrase does not make every recording exhaustive or every text message attributable to the human named in a party object. A primary record is still scoped by the sensors and policies that created it.

A party record authenticates a statement about identity

Party objects may carry names, telephone numbers, email addresses, SIP URIs, DIDs, UUIDs and location data. A validation field can record how an identity was verified without placing the underlying verification data in the vCon. This is a useful privacy-conscious separation.

It also makes the trust boundary visible. If a signed party object says validation was performed with credentials, the signature proves that the signer committed to that statement. It does not show which credentials, when they were checked, at what assurance, against which account lifecycle, or whether the method remains adequate for the receiver's decision.

Persistent UUIDs have a similar limit. They can correlate an agent across interactions inside an operator's system. They do not acquire universal identity semantics merely because they appear in a portable container. A receiver has to bind the identifier to the assigning authority and namespace.

For each relied-on party claim, record the source system, verification method, evidence reference, event time, assurance level and responsible domain. Separate “name displayed” from “person identified.” When a later amendment changes an alias into a legal name, require authority for that specific correction rather than inheriting trust from the container-wide signature.

A hash can outlive access to the thing it identifies

Dialog, attachments and analysis may be inline or externally referenced through HTTPS. The core uses content_hash and requires support for SHA-512 so a receiver can compare retrieved bytes with the value committed to by the signed container.

That creates a strong integrity relation. It does not create storage, authorization or availability. The core explicitly leaves secure storage, access and the exchange of credentials for externally referenced data outside its scope. A URL can return 403, 404 or a network error. A receiver can lack permission. A retention service can delete the object. The hash may still be perfectly valid while the evidence can no longer be inspected.

The operational state needs at least three fields, not one green badge: the signed reference is intact; the external object was or was not retrieved; and this relying party was or was not authorized to use it for the intended purpose. Malware scanning, media decoding and completeness are separate again.

This distinction matters for long-lived records. If a decision relies on an external recording, preserving only the vCon and hash preserves a commitment to unavailable bytes. It does not preserve the evidence. Leadership must choose whether to archive the bytes, maintain durable controlled access, or accept that some future decisions will be unverifiable.

Analysis provenance is a beginning, not a quality score

The Analysis Object can carry transcripts, translations, summaries, sentiment and reports. The core deliberately does not standardise all analysis formats. It requires a vendor and allows product and schema to distinguish implementations and data configurations. The overview recognises that implementations can differ significantly in quality and interpretation.

Naming a vendor helps a parser and an auditor. It does not reveal the model version, prompt, locale, confidence threshold, decoding settings, input preprocessing or human edits. Nor does it prove that the referenced dialog bytes were the exact input used. A signed sentiment label may be authentic to the system that packaged it and still be wrong, stale or unsuitable for a decision about a person.

Treat analysis as a derived claim with its own receipt. Bind it to the hashes and object indices of its inputs. Record vendor, product, schema, model or ruleset version, configuration, locale, output hash, confidence semantics, human review and permitted purpose. Preserve corrections without pretending that a later signature made the earlier inference true.

The format's flexibility is beneficial: it can carry future analysis without freezing one vendor's schema into the core. That same flexibility means the receiver cannot delegate quality policy to schema conformance. type: sentiment tells a system what the item purports to be, not whether the inference deserves reliance.

Consent is a claim with a clock and a purpose

The overview treats consent and provenance as context that a conversation record may need. The companion privacy and lawful-basis work explores notice, consent, purpose and jurisdiction. None of that turns the vCon signature into a universal certificate of lawful processing.

A consent claim has a subject, method, time, policy version, described purposes, jurisdiction and withdrawal state. Different capture, analysis, disclosure and retention purposes may require different authority. The applicable basis may not be consent at all. Those are questions for the relevant governance and legal regime, not properties JWS can infer from a payload.

The safe technical statement is narrow. A valid signature can authenticate that a signer recorded a particular consent assertion at a particular state. A relying organisation still has to decide whether the signer was qualified to assert it, whether the evidence covers the present purpose, whether it remains current and what withdrawal requires downstream.

Cryptographic validity is deliberately durable. Permission can change. If consent is withdrawn tomorrow, yesterday's signature should not become invalid; history would be corrupted if it did. Instead, the operating system needs a current-purpose decision that can diverge from the historic signed state.

An amendment chain authenticates states, not the best version of reality

Once a vCon is signed, changing its payload invalidates the signature. The drafts address growth and correction by creating a new instance version. The newer vCon deep-copies the earlier state, changes or adds information, and points through amended to the predecessor's UUID, optionally with its URL and content hash. Multiple security domains can produce and sign successive versions.

The chain preserves a history of commitments. It does not automatically prove that the deep copy was faithful, that the changed field was correct, or that the new signer was authorized to change it. A receiver must retrieve and verify the predecessor, compare the object-level differences, preserve index meaning and evaluate the authority for each change.

Redaction has the same boundary in sharper form. The core puts the redaction method outside scope and says assurance in its accuracy comes from the entity that created and signed the redacted version. The overview lists validation beyond that changing domain's signature as outside scope. A redactor may honestly sign its output and still miss personal data in an attachment, analysis result or unfamiliar extension.

Never let “latest signed version” mean “authoritative version” by default. A later security domain may be authorized to add a transcript but not to rewrite party identity. Another may be authorized to redact for one audience but not to destroy the only recoverable source. Authority is claim-specific, not inherited from sequence.

Extensions turn parsing into a capability decision

vCon extensions can add fields, redefine semantics or deprecate existing parameters. Compatible extensions may be ignored safely. Incompatible extensions must appear in critical; a processor that does not support one must reject the vCon or report unsupported content instead of processing it.

Even compatibility depends on the operation. The core offers a telling contrast: a transcriber may tolerate an unknown addition, while a redactor may need to understand every data-bearing field to ensure personal information is removed. An extension that is ignorable for one task can be unsafe for another.

A JSON parse success is therefore not an acceptance result. Record the extension inventory, the critical list, the processor and registry version, the current operation, and the reason each unknown extension was ignored or rejected. Make rejection happen before data is used. Otherwise an apparently harmless parser silently turns a semantic incompatibility into a privacy or evidentiary error.

Build a conversation evidence ledger beside the container

The drafts need not become a universal governance system to solve these problems. Their architectural virtue is a minimum portable structure that leaves future trust choices local. The receiver can add a decision ledger without pretending it is part of the wire format.

For every reliance decision, bind the exact vCon UUID, payload hash and form; declared scope and known exclusions; contributing systems and security domains; signer chain, validation time and trust policy; party evidence; capture coverage; external retrieval and authorization; analysis inputs and production configuration; consent or other purpose authority; extension capability; predecessor verification and object-level change set; downstream action, responsible operator and reversal path.

Keep observed facts apart from copied claims. “SHA-512 matched retrieved bytes” is an observation. “Party identity validated by credentials” is a claim in the payload until linked to a verification event. “Use permitted for quality assurance until this date” is a local authority decision. Those statements can share a receipt without sharing an assurance level.

The acceptance path is sequential: scope -> retrieve -> verify bytes -> identify signer -> authorize signer -> inspect extensions -> reconstruct lineage -> validate claims -> authorize purpose -> record reliance -> monitor withdrawal.

Run it against the review-room case. The main payload and one external object pass integrity. The missing recording prevents a completeness-sensitive use. The identity amendment is quarantined until its evidence and changing authority are supplied. The sentiment object can be stored but not used for a consequential decision without its production record. Historic consent remains authentic as history; current-purpose authority must be decided anew. No cryptographic result is discarded. None is asked to carry more governance weight than it earned.