Sujet
Identité numérique et justificatifs
Au sein de la facette Sujet, la veille thématique Identité numérique et justificatifs rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.
IETF
Le certificat expirait en 9999. Son lien au document pouvait rester non vérifié.
Le certificat à signature unique promet une clé créée pour un seul acte puis détruite. Cette promesse n’est pourtant pas contenue dans le verdict cryptographique: le contrôle du document lié, la procédure de l’AC et la confiance à long terme restent trois preuves distinctes.
IETF
La signature composite a été validée. L’enveloppe nommait pourtant un autre algorithme.
Composite ML-DSA réunit une signature post-quantique et une signature classique sous une seule interface. Son profil CMS rappelle qu’un verdict cryptographique n’est fiable que si les identifiants, le préhachage et les octets réellement signés racontent la même histoire.
Histoire d'Internet
Le numéro était national. Sa persistance dépendait pourtant d’un service concret : RFC 3188
Une bibliothèque nationale pouvait attribuer un nom destiné à durer des siècles. Le nom ne conservait pourtant aucun octet par lui-même. Dans RFC 3188, la persistance reposait sur des catalogues, des archives, des résolveurs et des institutions capables de continuer leur travail…
IETF
L’émetteur a signé l’enveloppe. Il ne pouvait toujours pas changer la clé de l’agent.
Dans le profil AIC-JWT 02, l’autorisation signée par le mandant voyage à l’intérieur d’un jeton signé par l’émetteur. Cette superposition empêche le transporteur du titre de devenir, par simple commodité, l’auteur de la délégation.
Histoire d'Internet
Le livre était sur une étagère. Le résolveur ne pouvait offrir qu’une notice : RFC 3187
Une résolution réussie ne livrait pas toujours un fichier. Si l’ouvrage n’existait qu’en version physique, RFC 3187 estimait que la meilleure réponse pouvait être une notice bibliographique et l’emplacement d’un exemplaire en bibliothèque. Le nom persistait; l’accès restait une…
IETF
L’agent a signé le défi. La clé jointe ne faisait toujours pas autorité.
La révision 03 d’OpenA2A AIP oblige le vérificateur à distinguer une signature mathématiquement correcte d’une identité établie. La clé fournie prouve une possession; seul un registre ou un document DID peut en attribuer l’usage au bon agent.
IETF
L’agent s’est tu. Le score a sanctionné ce que le vérificateur ne voyait plus.
Le projet NBTP transforme l’absence de battements et le silence corrélé en décroissance de confiance, puis en états SUSPECT ou QUARANTINED. Cette mécanique peut aider l’exploitation, à condition de ne pas confondre un angle mort d’observation avec le comportement de l’agent.
Histoire d'Internet
Retirer un nom de l’enveloppe ne révoquait pas l’ancienne clé : RFC 3185
Une nouvelle enveloppe chiffrée pouvait omettre trois destinataires et pourtant rester lisible par eux. Leur nom avait disparu de la représentation; le pouvoir reçu avec la clé précédente, lui, n’avait pas été repris. RFC 3185 exposait cette différence sans détour: réduire la…
Histoire d'Internet
Le domaine a signé le message. La personne restait sans nom : RFC 3183
Entre « ce domaine a laissé partir ce message » et « cette personne en est l’auteur », il existe un espace probatoire que l’interface moderne efface volontiers. RFC 3183 plaça précisément son mécanisme dans cet espace: une organisation pouvait authentifier quelqu’un en interne et…
Histoire d'Internet
Le nom est entré dans RSVP. L’autorité devait encore décider ce qu’il signifiait : RFC 3182
Un localisateur de politique ressemble à une permission quand on le lit trop vite. Il n’en est pas une. Dans la RFC 3182, ce localisateur indiquait où chercher une règle; un identifiant, un ticket Kerberos ou un certificat apportait une preuve d’identité d’une qualité variable…
IETF
Les deux volets du paiement concordent. La livraison reste vide.
Une réconciliation financière peut être exacte des deux côtés et laisser intacte la question la plus concrète: la contrepartie promise est-elle arrivée ?
IETF
La preuve du lot est valide. Combien de jetons avez-vous vraiment reçus ?
L’émission groupée de Privacy Pass économise des échanges et mutualise un calcul de preuve. Elle ne tient pourtant pas le livre de stock à la place du client: entre la réponse de l’émetteur, la finalisation cryptographique, l’écriture durable et l’usage ultérieur, plusieurs…
IETF
Le registre peut nommer la question de sécurité. Il ne peut pas la rendre acceptable.
Nommer une méthode d’authentification facilite l’interopérabilité; cela ne confère ni robustesse, ni autorisation d’usage, ni niveau d’assurance.
IETF
La commande ACME a nommé un profil ; le certificat devait encore faire ses preuves
ACME Profiles donne aux autorités de certification un sélecteur propre pour leurs politiques d’émission. Ce nom améliore la coordination, mais il ne transforme ni la commande, ni le tableau de bord d’automatisation, en preuve des champs du certificat, de son déploiement ou de son…
IETF
La méthode AML a réussi. Cela ne dit pas que le client est autorisé.
Un code portable peut confirmer l’exécution d’un contrôle sans transporter la conclusion juridique et opérationnelle que le destinataire voudrait lui prêter.
IETF
Un vCon signé n’est pas encore une conversation prouvée
Le conteneur vCon peut réunir entités, échanges, pièces jointes et analyses tout en protégeant ses octets par signature. Cette intégrité est une fondation, pas un verdict sur l’exhaustivité de la capture, la véracité des identités, la validité du consentement ou l’autorité de…
IETF
La méthode a réussi. L’étiquette `ivm` n’est toujours pas la preuve.
Un code commun peut nommer une méthode de vérification sans rendre comparables les dossiers qui se cachent derrière elle.
IETF
Le jeton KYAPay peut identifier l’agent. Le destinataire garde la décision.
Une preuve signée rend une requête plus attribuable; elle ne transforme pas son émetteur en gardien de tous les services qui la reçoivent.
IETF
Un client désigne son garant ; le serveur d’autorisation garde le dernier mot
Un nouveau projet OAuth veut rendre visible l’autorité de l’attestateur dans les métadonnées du client. Cette transparence ne fusionne pourtant ni l’endossement, ni la confiance cryptographique, ni l’autorisation: elle oblige au contraire à prouver chacune de ces décisions.
IETF
Le jeton enfant était valide. La chaîne devait encore l’autoriser.
Une signature correcte sur un jeton délégué ne suffit pas à produire un pouvoir exploitable. Le projet OAuth étudié exige de remonter jusqu’à une racine reconnue, de prouver chaque délégation et chaque réduction, puis de laisser au serveur de ressources sa décision locale.