Résumé

  • La révision 02 de Identity Verification Methods Values, datée du 2 octobre 2026, dit qu’une valeur ivm signale la réussite de la méthode indiquée. Elle précise aussi que le claim ne fournit ni la preuve ni les détails de son utilisation.
  • Le vocabulaire proposé peut faciliter l’interopérabilité, mais il ne certifie pas le fournisseur, l’autorité de la source, l’équivalence des procédures, la fraîcheur, le niveau d’assurance ou la décision prise ensuite.

Une taxonomie devient dangereuse lorsqu’un lecteur confond la netteté du nom avec la richesse de ce qu’il nomme. Le nouveau texte de draft-skyfire-oauth-id-verification-02 rend cette limite exceptionnellement visible.

Le projet propose ivm, tableau JSON de chaînes sensibles à la casse. Huit valeurs initiales couvrent la vérification par bases de données, une ou plusieurs sources, un document numérique ou physique, une pièce secondaire, un contrôle en personne et un entretien vidéo en direct. Le résultat tient dans quelques caractères.

Mais la révision 02 refuse de faire de ces caractères un dossier. La présence d’une valeur signifie que la méthode a réussi selon l’émetteur. Elle ne livre pas la preuve et n’explique pas comment la méthode a été appliquée. Pour une représentation plus détaillée, le document cite OpenID Identity Assurance et Vectors of Trust.

Cette modestie permet précisément au vocabulaire d’être utile. Des identifiants communs simplifient journaux, règles et échanges. Ils n’ont pas à transporter chaque document, contrôle et jugement. Le problème commence quand une politique aval reconstruit, sans données, une assurance que le code n’a jamais exprimée.

dbv1 et dbvm montrent l’écart. Ils distinguent une source de plusieurs sources de données de consommation. Ils ne donnent ni leur nom, ni leur indépendance, ni la date des enregistrements, ni les attributs comparés, ni la résolution des contradictions, ni le seuil de correspondance. Plusieurs copies d’une même erreur ne forment pas automatiquement une preuve plus forte.

Les méthodes documentaires sont tout aussi ouvertes. phy ne dit pas quel passeport, quelle version, quelle autorité, quel appareil ou quel test antifraude a été utilisé. dig ne porte pas son cadre de confiance. vid ne décrit ni liveness, ni opérateur, ni script, ni exception. inp ne nomme pas le site, l’agent ou le matériel supervisé.

Un JWT signé peut établir qui a émis l’affirmation et protéger ses octets. Il ne prouve pas la vérité de l’identité au-delà de ce qui est effectivement affirmé. « Réussi » reste le résultat d’une procédure possédant son seuil, son fournisseur et sa version.

Le registre proposé doit lui aussi rester à sa place. Le projet demande un claim JWT et un registre IANA soumis à Expert Review, avec trois semaines d’examen et des critères de non-duplication, portée générale, usage réel et clarté. C’est une gouvernance du vocabulaire, pas une accréditation des fournisseurs ou un score universel.

Les registres IANA vivants sont l’autorité pour les allocations effectives. Une table initiale dans un Internet-Draft individuel reste une demande. Le Datatracker gelé ne donne au texte ni stream, ni niveau de standard, ni adoption OAuth. Ce n’est pas un RFC.

L’analogie avec amr confirme la prudence. RFC 8176 prévient qu’une politique attachée directement à des méthodes peut devenir fragile lorsque les attaques et déploiements évoluent. Le nom de méthode rapporte ce qui a été employé ; un contexte d’assurance explique la politique sous laquelle ce résultat est acceptable.

OpenID Identity Assurance sépare cadre de confiance, niveau et processus d’assurance, date globale, référence du dossier, objets de preuve et détails des contrôles. RFC 8485 exige que les valeurs soient comprises dans leur cadre de confiance. NIST SP 800-63A-4 distingue résolution, collecte et force de la preuve, validation et vérification. Ces coordonnées ne tiennent pas dans phy ou vid.

Une organisation peut donc accepter ivm tout en conservant un reçu distinct : version du vocabulaire, émetteur, cadre, sujet et transaction, méthodes, fournisseur et politique, référence immuable de la preuve, source et juridiction, contrôles, liveness ou revue humaine, dates, assurance, exceptions, décision locale et résultat applicatif. Ce reçu est une proposition éditoriale BTW, pas une obligation du projet.

La spécification initiale minimale de Heng Lu recommande justement de partager le plus petit contrat commun sans centraliser les conséquences. La primauté du code en exécution demande quels contrôles ont vraiment tourné. Les couches de réalité empêchent le terme de registre, l’affirmation, la preuve et l’action de devenir un seul verdict.

La bonne règle tient en trois verbes : le label nomme, la preuve démontre, le destinataire décide.

Sources