Identité, Registry et sessions

6. Identité, Agent Registry et sessions

6.1 Agent Cartes

Le Organization MUST émet, vérifie, versionne et signe chaque Agent Card. Un Agent MUST NOT doit être approuvé simplement parce qu’il auto-déclare une capacité. Le Agent Card MUST distinct :

Identité stable, propriété, point de terminaison, clés publiques et protocole pris en charge variantes ;
capacités versionnées régies par Organization avec entrée/sortie déclarée schémas, contraintes et vérification Evidence ; et
concurrence maximale prise en charge.

La capacité n’est pas l’autorisation. Un Agent Card MUST NOT contient des informations d’identification réutilisables ou accorde l’accès à des outils ou à des données d’entreprise. L’éligibilité à l’autorisation et la politique actuelle restent des décisions Organization.

Les affectations MUST épingler la version de l’Agent Card et chaque version de capability requise. Une mise à niveau sur place compatible MAY se poursuivre selon la politique Organization. Une mise à niveau incompatible MUST créer un point de contrôle du travail actif et obtenir une nouvelle acceptation avant la reprise de l’exécution. Chaque Artifact MUST enregistrer les versions de l’Agent Card et des capabilities qui l’ont produit.

Le Registry SHOULD conserve des enregistrements de performances contextuels spécifiques aux capacités séparément des cartes Agent. Les enregistrements MAY incluent les résultats d’achèvement, d’échec, de réaffectation, de demande de modification humaine, de délai, de budget et d’expiration du bail. Une implémentation SHOULD NOT réduit les performances à un score de réputation globale opaque.

6.2 Enregistrements de présence

La présence est éphémère et MUST doit être distincte de la version stable Agent Card. Un enregistrement de présence MAY signale l’état en ligne, les emplacements d’exécution actuellement disponibles, la disponibilité des fonctionnalités, la latence de réponse estimée et le dernier battement de cœur. Un enregistrement de présence obsolète MUST NOT soit traité comme une acceptation de cession ou un renouvellement de bail.

Les mises à jour de présence MAY doivent être transportées dans des trames PING authentifiées et ne nécessitent pas de signature individuelle durable. La présence MUST NOT expose l’identité, le contenu, les WorkItems ou la position exacte de la file d’attente d’un autre Group.

6.3 Authentification et clôture Session Epoch

Chaque Agent MUST possède au moins une clé publique Organization enregistrée Ed25519. La poignée de main v0.1 WebSocket utilise un nouveau défi de serveur :

l’Agent envoie HELLO/client_init avec son Agent ID, son key ID, son nonce et les versions de protocole prises en charge ;
le serveur répond HELLO/server_challenge avec un défi imprévisible et version sélectionnée ;
le Agent répond à HELLO/client_response avec une signature Ed25519 sur le transcription canonique du défi ; et
le serveur répond à HELLO/server_accept avec un jeton de session de courte durée et un Session Epoch nouvellement émis.

L’émission de l’Epoch n + 1 invalide chaque session à l’Epoch n ou inférieure pour cet Agent ID. Le Group Authority MUST valider le Session Epoch sur chaque Agent Command qui modifie l’état. Les Command humains et ceux des services Organization ne portent pas d’Agent Session Epoch et MUST NOT en inventer un. Un runtime redémarré MAY récupérer son Agent ID stable ; deux runtime MUST NOT exploiter cette identité simultanément.

Les commandes durables et les manifestes Artifact MUST doivent être signés individuellement. Les battements de cœur et les enregistrements de présence s’appuient sur la session authentifiée. Les clés API partagées de longue durée sont NOT RECOMMENDED. Une implémentation MAY ajoute une authentification mTLS ou Workload-Identity, à condition qu’elle préserve l’ID Agent et la sémantique de clôture.