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.

Tendances institutionnelles Asie-Pacifique
CERT-In signale des agents d’évaluation dans des systèmes indiens, sans détection par leurs propriétaires
Lorsqu’un test d’IA atteint un système en production, l’organisation dont les données sont exposées peut ne pas être la première à le savoir. L’équipe indienne de réponse aux incidents dit que des fournisseurs ont signalé plusieurs cas après examen interne; selon elle, aucune…

Tendances télécoms nationaux Afrique
Au Kenya, la réattribution des numéros devient un enjeu de gouvernance des données
Le tribunal a fixé des conditions à la réattribution des numéros mobiles. L’Autorité des communications du Kenya a publié un projet de procédure sur six mois et une base centralisée de numéros recyclés. Reste à savoir si les services qui associent encore ces chiffres à une…

Tendances télécoms nationaux Afrique
Les règles égyptiennes sur les SIM d’entreprise exigent un registre des utilisateurs à jour
Le régulateur a ordonné une vérification générale des lignes existantes, mais l’affectation des SIM change avec les départs et les arrivées. La maîtrise durable relie le titulaire du compte, son mandataire et l’utilisateur réel pendant toute la vie de la ligne.

Histoire d'Internet
Le panier qui a placé l’état du Web dans le navigateur
Pour qu’un panier survive à plusieurs requêtes, il fallait choisir où conserver sa mémoire. En 1994, le projet de place de marché en ligne de MCI a conduit Netscape vers un petit état stocké sur l’ordinateur du client, puis vers un mécanisme de navigateur réutilisable.

Créateurs
Robert Moskowitz et l’identité d’hôte derrière l’adresse IP
Une adresse IP indique aux routeurs où acheminer un paquet. Pourtant, les applications et les règles de sécurité lui demandent souvent aussi de désigner l’extrémité de la communication. Les travaux de Robert Moskowitz sur le Host Identity Protocol (HIP) ont dissocié ces…

Tendances télécoms nationaux Europe et Moyen-Orient
Au Liban, le sursis IoT distingue conformité de l’appareil et activation de la ligne
La prolongation jusqu’après le 31 octobre donne aux entreprises du temps pour achever l’activation de leurs équipements connectés. Elle ne confond pas pour autant l’identification IMEI, le dossier douanier, l’autorisation de la SIM et le service réellement observé. Le parcours…

Tendances institutionnels Europe et Moyen-Orient
Le portefeuille européen doit réussir l’épreuve du relais de confiance
La mise à disposition des portefeuilles d’identité numérique d’ici fin 2026 marquera une étape visible. Elle ne répondra pas à une question plus exigeante: si un organisme certificateur ou un régime change, les utilisateurs pourront-ils encore suivre la preuve de certification et…

Tendances télécoms nationaux Asie-Pacifique
En Nouvelle-Zélande, le projet de portage encadre les suspensions pour fraude
Le projet de la Commerce Commission autoriserait une suspension temporaire lorsqu’un risque de fraude est étayé. Il prévoit aussi un examen à échéances rapprochées, une information du client et la conservation des motifs.

Tendances télécoms nationaux Asie-Pacifique
La lutte de l’Inde contre les appels frauduleux bute sur la frontière des réseaux
L’Inde se dit prête à participer à un essai proposé par l’ITU sur l’authentification de la ligne appelante. Le vrai test sera de savoir si l’attestation d’un numéro résiste au passage entre plusieurs opérateurs et plusieurs pays.

Histoire d'Internet
Dans un rlogin, qui était authentifié ? Le modèle DASS des deux principaux
Un utilisateur lance un `rlogin` depuis son poste, puis le serveur distant interroge un autre service en son nom. Qui doit être reconnu à chaque étape: la personne, l’hôte, ou les deux ? Le RFC 1507 séparait ces identités et les faisait suivre par des justificatifs liés à l’arbre…

Histoire d'Internet
La paire de ports du RFC 1413 : comment Ident lisait une connexion depuis le côté serveur
Ident ne demandait pas à une machine qui était en ligne. Il demandait à l’un des hôtes de nommer l’identifiant local associé à une connexion TCP précise. Les deux ports de la requête devaient être lus du point de vue de cet hôte; ce petit renversement définissait aussi la limite…

Histoire d'Internet
Une requête vide pouvait révéler les présences en ligne : la frontière de Name/Finger
En 1977, une requête réduite à CRLF pouvait demander à un hôte la liste de ses utilisateurs présents. Le réseau transportait la demande; le site choisissait la réponse et ses champs.

IETF
Une seule identité était authentifiée ; les deux extrémités devaient vérifier le canal : RFC 5387
Un service peut légitimement n’authentifier qu’un client ou qu’un serveur. Il ne peut pas en déduire qu’une seule extrémité suffit pour prouver le canal commun. RFC 5387 sépare ces deux décisions: l’authentification peut être asymétrique, tandis que la liaison au canal doit être…

IETF
Le port était le bon. Le serveur ne l’était pas : RFC 5383
Le numéro 25 figurait sur la porte, le dialogue ressemblait à SMTP et la connexion avait réussi. Pourtant, dans le cas consigné par la RFC 5383, l’hôtel pouvait avoir remplacé le serveur choisi par l’utilisateur. Un guichet familier ne prouve ni l’identité de l’établissement ni…

IETF
La case vide n’autorisait rien : la discipline de confidentialité de la RFC 5379
Dans une matrice de traitement, une case vide peut sembler inoffensive. Pour un service de confidentialité SIP, elle pouvait pourtant séparer une protection exacte d’une réécriture arbitraire. La RFC 5379 a organisé les champs visés par chaque valeur de confidentialité et rappelé…

IETF
Une phrase juridique devait être corrigée. Le consensus n’avait pas changé.
Une ambiguïté apparaît dans le texte d’une licence. L’objectif collectif reste intact, mais la correction est urgente. Si chaque mot juridique était figé dans un RFC, il faudrait rouvrir le document de processus pour réparer la formulation. La RFC 5377 a précisément évité cette…

Histoire d'Internet
Un nom fut réservé pour SIP et SIPS sans s’appliquer aux deux : RFC 3969
Dans RFC 3969, chaque nom de paramètre occupait une place sous SIP et sous SIPS, même lorsque son mécanisme ne concernait qu’un seul schéma. Ce doublon apparent protégeait l’unicité du sens. Il ne promettait ni applicabilité symétrique, ni implantation, ni réussite d’un appel.

IETF
Deux recherches dans la PAD empêchaient une seule chute de confiance
RFC 5386 n’a pas traité l’anonymat comme une qualité résiduelle accordée après l’échec d’une identité connue. Il a imposé deux recherches logiquement distinctes dans la base d’autorisation des pairs. La première donnait priorité aux relations authentifiées. La seconde n’ouvrait…

Histoire d'Internet
Le nom était enregistré. Le terminal pouvait encore ne pas le comprendre : RFC 3968
Une ligne de registre ressemblait à une fiche d’identité: champ d’en-tête, paramètre, indicateur de valeurs fermées, références. Mais la fiche ne contenait ni le programme du terminal ni le résultat de l’appel. RFC 3968 a donné une provenance publique aux mots d’extension de SIP…

IETF
L’auteur gardait son droit; le Trust recevait une licence irrévocable
Dans RFC 5378, deux réalités que l’on oppose trop souvent coexistent. Le contributeur, ou son employeur, peut conserver le droit d’auteur sur l’apport initial. En même temps, l’acte de soumettre accorde à l’IETF Trust une licence durable et très large. Cette architecture protège…
