Résumé

  • Les révisions 02 de l’overview vCon et 04 du core sont des Internet-Drafts de travail. Elles organisent un dossier conversationnel dont le créateur choisit la portée et dont les quatre grandes parties restent facultatives.
  • Une signature JWS peut protéger le payload et établir la possession de la clé de signature. Elle ne prouve seule ni que toute la conversation a été captée, ni que les personnes sont bien identifiées, ni que l’usage est autorisé.
  • La chaîne d’amendements conserve des états signés successifs. Pour prendre une décision, il faut en plus un registre reliant chaque assertion à sa source, son périmètre, sa finalité et l’autorité qui l’assume.

Le dossier arrive avec une apparence presque irréprochable. Les deux signatures JWS sont valides, le certificat est accepté et le content_hash correspond au fichier audio récupéré. La version la plus récente référence l’UUID de la précédente dans amended. Le système affiche donc « vérifié ».

Mais un deuxième canal audio est inaccessible. Le nouvel état remplace un pseudonyme de compte par le nom d’une personne sans fournir l’événement de vérification. Une analyse de sentiment donne le vendor, pas la version du modèle ni la configuration linguistique. Le consentement conservé dans le dossier décrivait l’enregistrement, pas cette nouvelle inférence. Tous les contrôles cryptographiques peuvent réussir alors que l’usage envisagé doit s’arrêter.

Ce constat ne diminue pas la signature. Il précise son objet.

draft-ietf-vcon-overview-02, daté du 30 septembre 2026, et draft-ietf-vcon-vcon-core-04, daté du 7 septembre 2026, proposent un conteneur JSON pour des informations liées à une conversation humaine. Ce sont des documents du groupe Virtualized Conversations encore en cours de travail, pas des RFC ni des normes achevées. Leur intérêt est de rendre portable un ensemble hétérogène entre plateformes de communication, services d’analyse et domaines de sécurité. La portabilité transporte toutefois les assertions avec les octets ; elle ne leur attribue pas automatiquement la même force probante.

Cinq décisions cachées derrière un voyant vert

Le mot « vérifié » mélange souvent cinq opérations. L’intégrité demande si le payload reçu est celui qui a été signé. L’identification du signataire demande quelle identité la clé et la chaîne de certificats établissent réellement. La provenance de capture demande quels systèmes ont observé ou transformé chaque élément. La vérité sémantique porte sur les noms, dates, transcriptions et inférences. Enfin, l’autorité détermine si l’acteur pouvait collecter, modifier, divulguer ou utiliser ces données pour cette finalité.

JWS répond directement à la première question et contribue à la deuxième si la politique de confiance est solide. La structure vCon peut conserver des éléments pour la troisième. Les deux dernières exigent une décision extérieure au payload. Une assertion fausse ne devient pas vraie parce qu’elle est signée ; une assertion exacte peut rester interdite d’usage.

Il faut donc bannir le statut global « conversation vérifiée ». Afficher séparément « intégrité du payload valide », « chaîne du signataire acceptée », « couverture de capture non établie » et « usage non autorisé » évite qu’une propriété technique se transforme en délégation implicite.

La portée est une décision du créateur

L’overview explique qu’une conversation n’a pas toujours de frontières naturelles. Un vCon peut ne contenir qu’un enregistrement, ou suivre un parcours depuis un message jusqu’à un appel puis un courriel. Pour le SMS, la session est souvent une construction éditoriale. Quelqu’un décide donc ce qui appartient au dossier.

Cette liberté est inscrite dans le format. Les quatre grandes parties — parties, dialog, attachments et analysis — sont facultatives. Un enregistrement sans personnes définies peut être valide. Le core autorise des dialogues incomplets ou des placeholders et distingue enregistrement, ensemble d’enregistrements, texte, transfert et tentative inachevée. Une piste peut ne représenter qu’un tronçon et ne pas nommer tous les participants.

La validité syntaxique n’équivaut donc pas à l’exhaustivité. L’omission peut être une minimisation légitime, une panne honnête ou une sélection intéressée. La signature immobilise ce qui a été choisi ; elle ne montre pas que ce choix couvre la réalité pertinente.

Avant un usage important, le destinataire doit conserver une déclaration de portée : début, fin, canaux, transferts, systèmes contributeurs, exclusions connues, politique de capture et responsable de la sélection. Les journaux de contrôle d’appel, identifiants de messages, états des enregistreurs ou traces d’un autre domaine peuvent alors corroborer cette déclaration.

Le draft appelle les dialogues les « ground truths » de la conversation. Il faut lire cette formule dans son contexte : le dialogue est la matière primaire, par opposition à une analyse dérivée. Elle ne garantit ni que le capteur a tout vu, ni que le compte émetteur correspond à la personne indiquée, ni que l’horloge est juste.

Une identité signée reste une assertion attribuée

Un objet party peut contenir nom, téléphone, adresse électronique, SIP URI, DID, UUID ou localisation. Le paramètre validation décrit la manière dont l’identité aurait été vérifiée sans exposer les données de contrôle. Cette séparation réduit la divulgation, mais elle n’emporte pas la preuve sous-jacente.

Si un vCon signé dit « validation par identifiants », on sait que le signataire assume cette phrase. On ne sait pas quels identifiants, à quelle date, avec quel niveau d’assurance, sur quel cycle de compte, ni si le contrôle convient à la décision présente. Le destinataire doit rattacher la méthode à un événement vérifiable, à une source et à un domaine responsable.

Même prudence pour un UUID persistant. Il peut corréler un agent dans le système de l’opérateur. Il n’acquiert pas une identité universelle lorsqu’il traverse une frontière. Le namespace et l’autorité d’attribution doivent l’accompagner.

Lorsqu’un amendement transforme un alias en nom civil, la nouvelle signature prouve que le domaine a produit la modification. Elle ne lui donne pas automatiquement compétence pour certifier l’identité. L’autorité doit être évaluée champ par champ.

Le hash protège des octets qu’on peut ne plus atteindre

Les dialogues, pièces jointes et analyses peuvent être intégrés ou référencés par une URL HTTPS. Le content_hash, avec prise en charge de SHA-512, permet de vérifier que les octets récupérés correspondent à ceux engagés par le conteneur signé.

Cette relation d’intégrité est forte. Elle ne stocke pas le fichier, ne délivre pas de droit d’accès et ne garantit aucune disponibilité. Le core place hors périmètre le stockage sécurisé, l’accès et l’échange des identifiants nécessaires aux objets externes. Une URL peut répondre 403 ou 404 ; la rétention peut avoir supprimé le média ; le destinataire peut ne pas être autorisé. Le hash reste correct devant une absence parfaite.

Un état opérationnel doit donc distinguer : référence signée intacte, objet effectivement récupéré, droit d’en faire l’usage prévu. Il faut encore contrôler le décodage, les logiciels malveillants et la couverture du média.

Pour l’archivage, le choix est stratégique. Garder uniquement le conteneur et le hash conserve la preuve qu’un contenu précis a existé, non la possibilité future de l’examiner. Il faut soit archiver les octets sous contrôle, soit garantir un accès durable, soit accepter explicitement que certaines décisions deviennent invérifiables.

La provenance d’une analyse ne mesure pas sa qualité

L’objet analysis peut porter transcription, traduction, résumé, sentiment ou rapport. Le core ne fige pas tous les formats. Il requiert vendor et permet product et schema, précisément parce que les implémentations divergent.

Ces champs aident à reconnaître un producteur et un format. Ils ne documentent pas forcément le modèle, le prompt, la langue, le seuil, le prétraitement, les entrées exactes ou les corrections humaines. Un sentiment signé peut correspondre exactement aux octets produits par le fournisseur et rester faux ou impropre à une décision sur une personne.

Chaque résultat dérivé mérite son propre reçu : hashes et indices des entrées, vendor, produit, schéma, version de modèle ou de règles, configuration, locale, hash de sortie, sens de la confiance, revue humaine et finalité admise. Cette proposition de registre est une analyse de Daniel Kade, pas une exigence du draft.

Le format reste ainsi extensible sans imposer un fournisseur. En contrepartie, la conformité du JSON ne peut servir de politique qualité. type: sentiment décrit la prétention de l’objet, pas sa justesse.

Le consentement garde une date et une finalité

L’overview souligne que consentement et provenance font partie du contexte de la conversation. Le privacy primer et le draft sur la lawful basis examinent notification, but et juridiction. Aucun n’autorise à traiter la signature comme un certificat juridique universel.

Une assertion de consentement suppose un sujet, une méthode, une date, une version de politique, des finalités et un état de retrait. Capturer, analyser, divulguer et conserver peuvent relever de justifications différentes. La base applicable peut d’ailleurs ne pas être le consentement. Cet article ne tranche aucune règle juridique générale ; il indique seulement la donnée que la gouvernance locale doit vérifier.

La signature peut authentifier qu’un acteur a enregistré telle assertion à tel moment. Le destinataire décide encore si cet acteur pouvait la formuler, si l’assertion couvre l’usage actuel et si elle reste valide. Un retrait futur ne doit pas invalider cryptographiquement l’histoire ; il doit modifier la décision de traitement présente.

La chaîne d’amendements conserve des engagements, pas une vérité finale

Modifier un vCon signé invalide sa signature. Les drafts créent donc une nouvelle version : copie profonde de l’état antérieur, enrichie ou corrigée, qui référence le prédécesseur par UUID et éventuellement URL et hash. Plusieurs domaines de sécurité peuvent signer des étapes successives.

On obtient une histoire d’engagements. On n’obtient pas automatiquement la preuve que la copie est complète, que la correction est juste ou que son auteur avait compétence. Le destinataire doit récupérer le prédécesseur, vérifier sa signature, comparer les objets, préserver la signification des indices et approuver l’autorité de chaque changement.

La redaction rend le problème plus sensible. Le core met la méthode hors périmètre et attribue l’assurance au domaine qui produit et signe la version redacted. Le texte de synthèse place aussi la validation de ces changements au-delà de la signature hors périmètre. Un service peut signer honnêtement une redaction tout en oubliant une donnée dans une analyse, une pièce jointe ou une extension inconnue.

La « dernière version signée » ne doit jamais être synonyme de « version autoritative ». Un service d’analyse peut ajouter une transcription sans pouvoir renommer une partie. Une entité peut masquer des données pour un public sans avoir le droit de détruire la source.

Une extension inconnue change la décision selon le métier

Les extensions vCon ajoutent des paramètres et peuvent redéfinir la sémantique. Les extensions incompatibles doivent apparaître dans critical; un processeur qui ne les comprend pas doit rejeter le document ou signaler l’incompatibilité.

Le caractère ignorable dépend de l’opération. Un transcripteur peut tolérer un champ nouveau. Un redactor doit parfois comprendre tout champ susceptible de contenir des données personnelles. La même extension est donc acceptable pour une tâche et bloquante pour une autre.

Le reçu doit lister les extensions, la valeur critical, la version du registre et du logiciel, l’opération demandée, puis la justification d’ignorer ou de rejeter. La réussite du parseur JSON ne vaut pas preuve d’interopérabilité sémantique.

Le registre de preuves relie le conteneur au monde réel

Pour chaque décision, conserver l’UUID, le hash du payload et sa forme ; la portée et les omissions ; les systèmes contributeurs ; le signataire, la validation du certificat et la politique de confiance ; les preuves d’identité ; la couverture de capture ; l’accès aux objets externes ; les entrées et paramètres d’analyse ; la finalité ; les extensions ; le prédécesseur vérifié et les différences ; enfin la décision, son responsable et son chemin de retour.

Séparer observations et assertions. « Le SHA-512 des octets récupérés correspond » est observé. « L’identité a été validée » est copié du payload tant qu’aucun événement n’est lié. « Usage admis jusqu’à telle date » est une décision locale.

La séquence devient : définir la portée -> récupérer -> vérifier les octets -> identifier le signataire -> autoriser ses assertions -> examiner les extensions -> reconstruire la lignée -> valider les claims -> autoriser la finalité -> consigner -> surveiller les retraits.

Dans notre dossier initial, l’intégrité est conservée. L’usage exigeant l’exhaustivité attend le canal absent. Le changement d’identité est mis en quarantaine. L’analyse peut être archivée sans être décisionnelle. L’ancien consentement reste une trace authentique, tandis que la finalité nouvelle requiert sa propre autorisation.