Sur Internet, l’identification repose le plus souvent sur un login/identifiant et un password/secret. Ce modèle fonctionne bien pour les humains. Quant aux programmes qui accèdent à des services, on dispose de mécanismes encore plus limités : on trouvera le plus souvent une clé d’API, même quand il s’agit d’agents autonomes qui effectuent des actions au nom de personnes (personnes physiques, personnes morales).

Je vous présente brièvement ce qui compose une identité numérique, comment cela marche pour l’identification de logiciels et/ou d’agents autonomes, et comment donner à ces agents autonomes des identités vérifiables.

Ce qui compose une identité

On retrouve dans l’identité trois éléments :

  • un identifiant : ça désigne un utilisateur unique, par exemple un login ou une adresse mail ;
  • une preuve : c’est le secret dont dispose l’utilisateur pour prouver qu’il est bien celui qu’il prétend être, par exemple un mot de passe ou un code reçu par mail ;
  • des attributs : c’est l’ensemble des informations qui permettent de décrire la personne, par exemple le nom, le prénom, la date de naissance…

On peut les retrouver généralement dans une base de données. Ça ressemble à peu près au JSON ci-dessous :

{
  "email": "alice@example.com",
  "password_hash": "$argon2id$v=19$m=65536,t=3,p=4$...",
  "name": "Alice Martin",
  "role": "comptable",
  "email_verified": true
}

Dans ce cas, l’email sert d’identifiant, le password_hash contient l’empreinte du mot de passe, le secret qui sert de preuve du contrôle de l’utilisateur sur le compte lors de la connexion, et les autres champs sont des attributs qui décrivent l’utilisateur en question.

La plupart du temps, les attributs sont fournis par l’utilisateur lui-même et le service ne les a probablement jamais vérifiés, voire n’a aucun moyen de le faire. Un moyen d’obtenir des attributs fiables est de s’appuyer sur un service tiers qui, lui, les a vérifiés (un employeur pour un rôle, une université pour un diplôme, l’État pour une identité civile). Un des moyens de disposer d’identités vérifiables sans fournisseur d’identité tiers est discuté dans ce billet sur l’architecture des comptes sans e-mail.

L’identité des non-humains

Les programmes aussi ont besoin d’une identité. Un site web, un script de sauvegarde ou une intégration entre deux logiciels doivent prouver qui ils sont avant d’accéder à un service. On parle alors d’identités non humaines (non-human identities).

L’exemple le plus courant est le certificat HTTPS. Lorsqu’un navigateur se connecte à un site, le serveur présente un certificat qui associe son nom de domaine à une clé publique. On peut afficher celui de ce blog avec openssl :

openssl s_client -connect blog.kaizensphere.dev:443 \
  -servername blog.kaizensphere.dev </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

À la date de rédaction de cet article, la commande affiche :

subject=CN = blog.kaizensphere.dev
issuer=C = US, O = Let's Encrypt, CN = YR2
notBefore=Aug 27 02:03:17 2026 GMT
notAfter=Nov 25 02:03:16 2026 GMT

La ligne subject contient l’identifiant, ici le nom de domaine. La ligne issuer, quant à elle, désigne l’autorité de certification qui a signé le certificat ci-dessus. Pour les lignes notBefore et notAfter, ce sont les limites de validité. On peut remarquer qu’on retrouve les éléments principaux de l’identité, à savoir un identifiant, une preuve grâce à la clé privée que seul le serveur possède et une attestation signée par un tiers en qui le navigateur a confiance.

L’accès à une API est beaucoup plus simple : une clé d’API. Par exemple, un script qui importe des factures dans un logiciel de comptabilité reçoit une configuration dans ce genre :

{
  "name": "import-factures",
  "api_key": "7f3a9c1e...",
  "scopes": ["*"],
  "expires_at": null,
  "owner": null
}

C’est un cas où la clé sert à la fois d’identifiant et de secret. L’accès à cette clé permet donc d’agir en lieu et place du script auquel cette clé est destinée.

rattachée à aucun responsable ("owner": null). Toute personne ou tout programme qui récupère cette clé peut donc agir à la place du script.

On observe trois différences avec l’identité d’une personne :

  • les programmes agissent pour le compte de personnes (physiques ou morales) et le service doit savoir qui est responsable ;
  • un programme ou un agent autonome peut être créé pour une tâche puis supprimé quelques minutes plus tard, et ses droits doivent avoir la même durée ;
  • la quantité d’identités pour les programmes/agents autonomes est importante : en octobre 2025, le Forum économique mondial relevait que les agents IA multipliaient le besoin d’identités pour les programmes, et souvent avec des accès plus larges et durables.

Le cas des agents autonomes

Les différences dont nous avons parlé deviennent critiques lorsque le programme choisit lui-même ce qu’il fait, de façon autonome. À partir d’objectifs, il décide des étapes et effectue des actions : consulter des factures, vérifier un solde, préparer un paiement. Son comportement évolue en fonction de la situation, et une même clé lui servirait pour toutes ces actions.

Si un agent est chargé de traiter les factures d’une entreprise, dans le cas classique avec une clé d’API, le service de comptabilité qu’il appelle sait seulement que la requête vient de quelqu’un qui possède la clé. Il ignore qu’il s’agit d’un agent, et pour le compte de quel service il agit.

Le service aurait besoin de savoir quel agent s’adresse à lui, pour le compte de quel service, et ce qu’il a le droit de faire. Ces vérifications sont regroupées sous le nom Know Your Agent, par analogie avec le Know Your Customer des banques, et la Decentralized Identity Foundation y consacre une spécification.

Principe des attestations vérifiables

Une attestation vérifiable (Verifiable Credential, ou VC) est un document signé par un émetteur, qui affirme des attributs sur un sujet. On a trois rôles :

  • l’émetteur, qui signe et émet l’attestation ;
  • le détenteur, qui conserve l’attestation ;
  • le vérificateur, qui contrôle la signature pour confirmer la validité des attributs.

Ces attestations VC peuvent être émises par toutes les organisations. Le fonctionnement rappelle celui du certificat HTTPS, où le navigateur accepte une signature parce qu’il fait confiance à l’autorité qui l’a produite. Dans le cas des VC, c’est le vérificateur qui décide des émetteurs qu’il accepte en fonction des attributs.

Étant donné qu’une attestation désigne toujours son sujet par un identifiant, on pourra ensuite affecter à l’agent en question des droits dont lui seul dispose, et pas les sous-agents qu’il utiliserait par exemple.

Donner un identifiant à un agent autonome

Le W3C définit un standard, les Decentralized Identifiers (DID), dont la spécification est une recommandation qui date de 2022. Un DID pointe vers un document qui publie les clés publiques de son titulaire. Une des méthodes est did:web, que l’on pourrait retrouver dans notre cas sous la forme :

did:web:example.com:agents:factures

Cette méthode did:web permet d’indiquer que le document est publié sur un site web. Ce document contient les informations suivantes :

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:web:example.com:agents:factures",
  "controller": "did:web:example.com",
  "verificationMethod": [
    {
      "id": "did:web:example.com:agents:factures#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:web:example.com:agents:factures",
      "publicKeyJwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
    }
  ],
  "authentication": ["did:web:example.com:agents:factures#key-1"]
}

La spécification KYA-OS accepte également la méthode did:key, qui dérive l’identifiant de la clé publique elle-même plutôt que de récupérer le document à une autre adresse comme avec did:web.

Cela signifie que quand l’agent signe une requête avec sa clé privée, le service peut récupérer ce document pour la méthode did:web, ou vérifier directement avec la méthode did:key.

Décrire les droits de l’agent dans un mandat

Les droits de l’agent sont décrits dans une Verifiable Credential. La spécification KYA-OS la nomme delegation credential, car elle porte des capacités de délégation. L’exemple ci-dessous s’appuie sur ZCAP-LD :

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/security/zcap/v1",
    "https://kya-os.org/ns/delegation/v1"
  ],
  "type": ["VerifiableCredential", "DelegationCredential"],
  "issuer": "did:web:example.com",
  "validUntil": "2026-09-22T18:00:00Z",
  "credentialSubject": {
    "id": "urn:zcap:del_2026_09_22_001",
    "invoker": "did:web:example.com:agents:factures",
    "invocationTarget": "did:web:compta.example.com",
    "parentCapability": "did:web:compta.example.com",
    "allowedAction": ["invoices.read", "payments.propose"],
    "caveats": [
      { "type": "MaxAmount", "limit": "500.00", "currency": "EUR" }
    ]
  },
  "credentialStatus": {
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.com/status/delegations"
  }
}

Le modèle ZCAP-LD sert à prouver ce que l’agent a le droit de faire sur une ressource distante. Il permet également de déléguer de façon sécurisée le droit d’exécuter des actions à des sous-agents, tout en respectant le principe du moindre privilège.

J’aimerais faire remarquer une petite différence par rapport à HTTPS. En HTTPS, l’autorité de certification est impliquée dans la certification de l’identité, là où les delegation credentials se basent sur le modèle Object Capability (OCAP), qui permet à un agent de délivrer une delegation credential à un autre agent.

Une différence cruciale existe aussi avec les Verifiable Credentials classiques : là où celles-ci sont optimisées pour la divulgation sélective, la delegation credential fournit toutes les informations. On veut connaître précisément l’agent et les capacités dont il dispose sur les ressources.

Concrètement, comment se passe cette identification ?

Pour envoyer sa requête, l’agent autonome ajoute trois en-têtes : la delegation credential dans KYA-OS-Delegation-Credential, la preuve qu’il détient la clé dans KYA-OS-Delegation-Proof, et son identité dans KYA-OS-Agent-DID. Il existe trois autres en-têtes, qui ne servent pas à la décision d’autorisation : KYA-OS-Session-Id, un identifiant de session, KYA-OS-Delegation-Chain, la chaîne de délégation, utile pour le routage, et KYA-OS-Granted-Scopes, les droits accordés en clair, utiles pour la journalisation ou le débogage.

Le service doit ensuite effectuer à son tour les actions suivantes :

1. Résoudre le DID de l'agent dans KYA-OS-Agent-DID et récupérer sa clé publique
2. Vérifier la preuve de détention de la clé dans KYA-OS-Delegation-Proof
3. Résoudre le DID de l'émetteur et vérifier la signature du mandat dans KYA-OS-Delegation-Credential
4. Vérifier que le champ invoker désigne bien cet agent
5. Vérifier que invocationTarget désigne bien la ressource appelée
6. Contrôler la date validUntil
7. Consulter la liste de statuts pour vérifier que le mandat est toujours actif
8. Comparer l'action demandée avec allowedAction et les caveats

Une fois toutes ces vérifications effectuées et concluantes, on peut attester de l’identifiant du mandant de l’agent, qu’il s’agisse d’une personne ou d’une organisation.

Le mandant, lui, stocke ses credentials dans un portefeuille numérique. L’Union européenne prépare une version normalisée de ce portefeuille pour les entreprises, présentée dans les nouveautés EUDI Wallet de juin 2026.

Limites

Les agents étant imprévisibles, rien ne garantit qu’ils se limitent à ce qu’ils sont autorisés à faire. Les moteurs de décision, comme celui présenté dans l’article sur ODRL, permettent au service de réduire ce risque.

ZCAP-LD n’est pas encore adopté. Pour l’instant, les discussions sur ce format évoluent au sein du W3C.

Pour tester le fonctionnement, la spécification KYA-OS propose une démonstration en ligne.