{
  "title": "OpenID Connect pour les Agents (OIDC-A) 1.0 - Proposition",
  "excerpt": "Proposition technique pour étendre OpenID Connect Core 1.0 afin de fournir un cadre pour représenter, authentifier et autoriser les agents basés sur les LLM au sein de l'écosystème OAuth 2.0.",
  "content_html": "<p><em>Ce document propose une extension standard à OpenID Connect pour représenter et vérifier l'identité des agents basés sur les LLM. Il intègre la proposition principale avec des cadres détaillés pour la vérification, l'attestation et les chaînes de délégation.</em></p>\n\n<h2>Résumé</h2>\n\n<p>OpenID Connect pour les Agents (OIDC-A) 1.0 est une extension d'OpenID Connect Core 1.0 qui fournit un cadre pour représenter, authentifier et autoriser les agents basés sur les LLM au sein de l'écosystème OAuth 2.0. Cette spécification définit des revendications standard, des points de terminaison et des protocoles pour établir l'identité des agents, vérifier l'attestation des agents, représenter les chaînes de délégation et permettre une autorisation fine basée sur les attributs des agents.</p>\n\n<h2>1. Introduction</h2>\n\n<h3>1.1 Justification</h3>\n\n<p>Alors que les agents basés sur les LLM deviennent de plus en plus répandus dans les écosystèmes numériques, il existe un besoin croissant de méthodes standardisées pour représenter leur identité et gérer leur autorisation. Les protocoles traditionnels OAuth 2.0 et OpenID Connect ont été conçus principalement pour les utilisateurs humains et les applications conventionnelles, manquant des constructions nécessaires pour représenter les caractéristiques uniques des agents autonomes, telles que :</p>\n\n<ul>\n<li>Agir au nom des utilisateurs avec différents degrés d'autonomie</li>\n<li>Opérer au sein de chaînes de délégation</li>\n<li>Posséder des capacités dynamiques basées sur leurs modèles sous-jacents</li>\n<li>Nécessiter une attestation de leur intégrité et de leur origine</li>\n</ul>\n\n<p>Cette spécification comble ces lacunes en étendant OpenID Connect pour fournir un cadre complet pour l'identité et l'autorisation des agents.</p>\n\n<h3>1.2 Terminologie</h3>\n\n<p>Cette spécification utilise les termes définis dans OAuth 2.0 [RFC6749], OpenID Connect Core 1.0, et les termes supplémentaires suivants :</p>\n\n<ul>\n<li><strong>Agent</strong> : Une entité logicielle basée sur un LLM capable d'action autonome ou semi-autonome basée sur des instructions en langage naturel.</li>\n<li><strong>Fournisseur d'Agent</strong> : L'organisation responsable de la création, de l'entraînement et/ou de l'hébergement de l'agent.</li>\n<li><strong>Modèle d'Agent</strong> : Le modèle LLM spécifique qui alimente l'agent (par exemple, GPT-4, Claude 3).</li>\n<li><strong>Instance d'Agent</strong> : Une instance en cours d'exécution spécifique d'un agent, généralement associée à une tâche ou une conversation particulière.</li>\n<li><strong>Délégant</strong> : L'entité (généralement un utilisateur humain) qui délègue l'autorité à un agent pour agir en son nom.</li>\n<li><strong>Chaîne de Délégation</strong> : Une séquence d'étapes de délégation depuis l'utilisateur d'origine à travers potentiellement plusieurs agents.</li>\n<li><strong>Attestation</strong> : Preuve cryptographique de l'intégrité, de l'origine et/ou des propriétés d'un agent.</li>\n<li><strong>Preuve d'Attestation</strong> : Structure de données contenant la preuve utilisée pour l'attestation.</li>\n<li><strong>Partie de Confiance (RP)</strong> : Dans ce contexte, souvent un serveur de ressources ou une application cliente qui doit vérifier l'identité et l'autorisation d'un agent.</li>\n</ul>\n\n<h3>1.3 Vue d'ensemble</h3>\n\n<p>OIDC-A étend OpenID Connect en :</p>\n\n<ol>\n<li>Définissant de nouvelles revendications standard pour représenter l'identité, la délégation et les capacités des agents.</li>\n<li>Spécifiant des mécanismes et des formats pour les preuves d'attestation des agents.</li>\n<li>Établissant des protocoles pour représenter et valider les chaînes de délégation.</li>\n<li>Fournissant des mécanismes de découverte pour les capacités des agents et le support d'attestation.</li>\n<li>Définissant des cadres d'autorisation adaptés aux cas d'usage spécifiques aux agents.</li>\n<li>Introduisant des points de terminaison pour la vérification d'attestation et la découverte de capacités.</li>\n</ol>\n\n<h2>2. Revendications d'Identité des Agents</h2>\n\n<h3>2.1 Revendications d'Identité de Base des Agents</h3>\n\n<p>Les revendications suivantes DOIVENT ou DEVRAIENT être incluses dans les jetons d'identité émis pour ou concernant les agents :</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Revendication</th>\n            <th>Type</th>\n            <th>Description</th>\n            <th>Exigence</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_type</code></td>\n            <td>string</td>\n            <td>Identifie le type/classe d'agent (par exemple, \"assistant\", \"retrieval\", \"coding\")</td>\n            <td>OBLIGATOIRE</td>\n        </tr>\n        <tr>\n            <td><code>agent_model</code></td>\n            <td>string</td>\n            <td>Identifie le modèle spécifique (par exemple, \"gpt-4\", \"claude-3-opus\", \"gemini-pro\")</td>\n            <td>OBLIGATOIRE</td>\n        </tr>\n        <tr>\n            <td><code>agent_version</code></td>\n            <td>string</td>\n            <td>Identifiant de version du modèle d'agent</td>\n            <td>RECOMMANDÉ</td>\n        </tr>\n        <tr>\n            <td><code>agent_provider</code></td>\n            <td>string</td>\n            <td>Organisation qui fournit/héberge l'agent (par exemple, \"openai.com\", \"anthropic.com\")</td>\n            <td>OBLIGATOIRE</td>\n        </tr>\n        <tr>\n            <td><code>agent_instance_id</code></td>\n            <td>string</td>\n            <td>Identifiant unique pour cette instance spécifique de l'agent</td>\n            <td>OBLIGATOIRE</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.2 Revendications de Délégation et d'Autorité</h3>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Revendication</th>\n            <th>Type</th>\n            <th>Description</th>\n            <th>Exigence</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>delegator_sub</code></td>\n            <td>string</td>\n            <td>Identifiant de sujet de l'entité qui a le plus récemment délégué l'autorité à cet agent</td>\n            <td>OBLIGATOIRE</td>\n        </tr>\n        <tr>\n            <td><code>delegation_chain</code></td>\n            <td>array</td>\n            <td>Tableau ordonné des étapes de délégation (voir Section 2.4.2)</td>\n            <td>OPTIONNEL</td>\n        </tr>\n        <tr>\n            <td><code>delegation_purpose</code></td>\n            <td>string</td>\n            <td>Description de l'objectif/intention pour lequel l'autorité a été déléguée</td>\n            <td>RECOMMANDÉ</td>\n        </tr>\n        <tr>\n            <td><code>delegation_constraints</code></td>\n            <td>object</td>\n            <td>Contraintes placées sur l'agent par le délégant</td>\n            <td>OPTIONNEL</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.3 Revendications de Capacité, de Confiance et d'Attestation</h3>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Revendication</th>\n            <th>Type</th>\n            <th>Description</th>\n            <th>Exigence</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_capabilities</code></td>\n            <td>array</td>\n            <td>Tableau d'identifiants de capacités représentant ce que l'agent peut faire</td>\n            <td>RECOMMANDÉ</td>\n        </tr>\n        <tr>\n            <td><code>agent_trust_level</code></td>\n            <td>string</td>\n            <td>Classification de confiance de l'agent (par exemple, \"verified\", \"experimental\")</td>\n            <td>OPTIONNEL</td>\n        </tr>\n        <tr>\n            <td><code>agent_attestation</code></td>\n            <td>object</td>\n            <td>Preuve d'attestation ou référence (voir Section 2.4.4)</td>\n            <td>RECOMMANDÉ</td>\n        </tr>\n        <tr>\n            <td><code>agent_context_id</code></td>\n            <td>string</td>\n            <td>Identifiant pour le contexte de conversation/tâche</td>\n            <td>RECOMMANDÉ</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.4 Formats et Validation des Revendications</h3>\n\n<h4>2.4.1 <code>agent_type</code></h4>\n<p>Valeur de chaîne provenant d'un ensemble défini de types d'agents. Les implémenteurs DEVRAIENT utiliser l'une des valeurs suivantes le cas échéant :</p>\n<ul>\n<li><code>assistant</code> : Agent assistant à usage général</li>\n<li><code>retrieval</code> : Agent spécialisé dans la récupération d'informations</li>\n<li><code>coding</code> : Agent spécialisé dans la génération ou l'analyse de code</li>\n<li><code>domain_specific</code> : Agent spécialisé pour un domaine particulier</li>\n<li><code>autonomous</code> : Agent avec un haut degré d'autonomie</li>\n<li><code>supervised</code> : Agent nécessitant une supervision humaine pour les actions clés</li>\n</ul>\n\n<p>Des types personnalisés PEUVENT être utilisés mais DEVRAIENT suivre le format <code>vendor:type</code> (par exemple, <code>acme:financial_advisor</code>).</p>\n\n<h4>2.4.2 <code>delegation_chain</code></h4>\n<p>Tableau JSON contenant des objets représentant chaque étape de la chaîne de délégation, de l'utilisateur d'origine à l'agent actuel. Chaque objet DOIT contenir :</p>\n<ul>\n<li><code>iss</code> : OBLIGATOIRE. Chaîne identifiant le serveur d'autorisation ou l'entité qui a émis/validé cette étape de délégation.</li>\n<li><code>sub</code> : OBLIGATOIRE. Chaîne identifiant le délégant (l'entité accordant la permission).</li>\n<li><code>aud</code> : OBLIGATOIRE. Chaîne identifiant le délégataire (l'agent recevant la permission).</li>\n<li><code>delegated_at</code> : OBLIGATOIRE. NumericDate représentant le moment où la délégation s'est produite.</li>\n<li><code>scope</code> : OBLIGATOIRE. Chaîne séparée par des espaces de portées OAuth représentant les permissions accordées dans cette étape de délégation. DOIT être un sous-ensemble des portées détenues par le délégant (<code>sub</code>).</li>\n<li><code>purpose</code> : OPTIONNEL. Chaîne décrivant l'objectif prévu de cette étape de délégation.</li>\n<li><code>constraints</code> : OPTIONNEL. Objet JSON spécifiant les contraintes sur la délégation (par exemple, <code>{\"max_duration\": 3600, \"allowed_resources\": [\"/data/abc\"]}</code>).</li>\n<li><code>jti</code> : OPTIONNEL. Un identifiant unique pour cette étape de délégation spécifique, utile pour la révocation ou le suivi.</li>\n</ul>\n\n<p>Le tableau DOIT être ordonné chronologiquement.</p>\n\n<p><em>Règles de validation pour <code>delegation_chain</code> (effectuées par la Partie de Confiance) :</em></p>\n<ol>\n<li><strong>Vérification de l'ordre :</strong> Confirmer l'ordre chronologique basé sur <code>delegated_at</code>.</li>\n<li><strong>Confiance de l'émetteur :</strong> Vérifier que chaque <code>iss</code> est de confiance.</li>\n<li><strong>Correspondance de l'audience :</strong> Confirmer que <code>aud</code> de l'étape N correspond à <code>sub</code> de l'étape N+1.</li>\n<li><strong>Réduction de la portée :</strong> Vérifier que <code>scope</code> dans chaque étape est un sous-ensemble de/égal aux portées disponibles du délégant.</li>\n<li><strong>Application des contraintes :</strong> Assurer la conformité avec toutes les <code>constraints</code>.</li>\n<li><strong>Validation de signature (si applicable) :</strong> Valider les signatures si les étapes sont signées individuellement.</li>\n<li><strong>Vérification de politique :</strong> Évaluer la chaîne validée par rapport aux politiques d'autorisation (par exemple, longueur maximale).</li>\n</ol>\n\n<h4>2.4.3 <code>agent_capabilities</code></h4>\n<p>Tableau d'identifiants de chaîne représentant les capacités de l'agent. Les implémenteurs DEVRAIENT utiliser des identifiants de capacités provenant d'une taxonomie bien définie lorsqu'elle est disponible. Les capacités personnalisées DEVRAIENT suivre le format <code>vendor:capability</code> (par exemple, <code>acme:financial_analysis</code>).</p>\n\n<h4>2.4.4 <code>agent_attestation</code></h4>\n<p>Objet JSON contenant une preuve d'attestation ou une référence à celle-ci. DOIT inclure un champ <code>format</code> indiquant le type de preuve.</p>\n\n<p><em>Format recommandé :</em> Basé sur JWT, potentiellement compatible avec IETF RATS Entity Attestation Token (EAT).</p>\n\n<p>Exemple :</p>\n<pre><code class=\"language-json\">\"agent_attestation\": {\n  \"format\": \"urn:ietf:params:oauth:token-type:eat\",\n  \"token\": \"eyJhbGciOiJFUzI1NiIsInR5cCI6ImVhdCtqd3QifQ...\"\n}\n</code></pre>\n<p>D'autres formats (par exemple, <code>\"format\": \"TPM2-Quote\"</code>, <code>\"format\": \"SGX-Quote\"</code>) PEUVENT être utilisés.</p>\n\n<h2>3. Flux de Protocole</h2>\n\n<h3>3.1 Flux d'Authentification des Agents</h3>\n\n<p>Le flux d'authentification OIDC-A étend le flux d'authentification OpenID Connect standard :</p>\n\n<ol>\n<li><strong>Enregistrement du client</strong> : Les clients représentant des agents DOIVENT enregistrer des métadonnées supplémentaires (voir Section 4).</li>\n<li><strong>Demande d'authentification</strong> : Les agents DEVRAIENT inclure la portée <code>agent</code> et potentiellement <code>delegation_context</code>.</li>\n<li><strong>Réponse d'authentification</strong> : Le serveur d'autorisation inclut des revendications spécifiques aux agents dans le jeton d'identité.</li>\n<li><strong>Validation du jeton</strong> : Les RP DOIVENT valider les revendications OIDC standard et les revendications pertinentes spécifiques aux agents (y compris l'attestation et la délégation si présentes) selon la politique.</li>\n</ol>\n\n<h3>3.2 Flux de Délégation</h3>\n\n<p>Lorsqu'une autorité est déléguée à un agent :</p>\n\n<ol>\n<li>Le délégant s'authentifie et autorise la délégation.</li>\n<li>Le serveur d'autorisation émet un nouveau jeton d'identité à l'agent incluant <code>delegator_sub</code>, <code>delegation_chain</code> (mis à jour), <code>delegation_purpose</code>, et <code>scope</code> contraint.</li>\n</ol>\n\n<h3>3.3 Flux de Vérification d'Attestation</h3>\n\n<p>Pour vérifier l'attestation d'un agent :</p>\n\n<ol>\n<li>L'agent inclut la revendication <code>agent_attestation</code> dans son jeton d'identité ou fournit la preuve séparément.</li>\n<li>La RP valide la preuve en fonction du <code>format</code> spécifié :\n<ul>\n<li>Vérifier les signatures cryptographiques en utilisant des clés de confiance (obtenues via Discovery).</li>\n<li>Comparer les mesures de plateforme avec des valeurs connues comme bonnes.</li>\n<li>Valider les nonces pour prévenir les attaques par rejeu.</li>\n<li>Optionnellement, utiliser le <code>agent_attestation_endpoint</code> pour l'assistance à la validation.</li>\n</ul>\n</li>\n<li>Les décisions d'autorisation incorporent le statut d'attestation (par exemple, <code>verified: true/false</code>).</li>\n</ol>\n\n<h2>4. Enregistrement et Découverte des Clients</h2>\n\n<h3>4.1 Métadonnées d'Enregistrement des Clients Agents</h3>\n\n<p>Étend OAuth 2.0 Dynamic Client Registration [RFC7591] :</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Paramètre</th>\n            <th>Type</th>\n            <th>Description</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_provider</code></td>\n            <td>string</td>\n            <td>Identifiant du fournisseur d'agent</td>\n        </tr>\n        <tr>\n            <td><code>agent_models_supported</code></td>\n            <td>array</td>\n            <td>Liste des modèles d'agents pris en charge</td>\n        </tr>\n        <tr>\n            <td><code>agent_capabilities</code></td>\n            <td>array</td>\n            <td>Liste des capacités de l'agent</td>\n        </tr>\n        <tr>\n            <td><code>attestation_formats_supported</code></td>\n            <td>array</td>\n            <td>Liste des formats d'attestation pris en charge</td>\n        </tr>\n        <tr>\n            <td><code>delegation_methods_supported</code></td>\n            <td>array</td>\n            <td>Liste des méthodes de délégation prises en charge</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>4.2 Métadonnées de Découverte</h3>\n\n<p>Étend OpenID Connect Discovery 1.0 :</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Paramètre</th>\n            <th>Type</th>\n            <th>Description</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_attestation_endpoint</code></td>\n            <td>string</td>\n            <td>URL du point de terminaison d'attestation</td>\n        </tr>\n        <tr>\n            <td><code>agent_capabilities_endpoint</code></td>\n            <td>string</td>\n            <td>URL du point de terminaison de découverte des capacités</td>\n        </tr>\n        <tr>\n            <td><code>agent_claims_supported</code></td>\n            <td>array</td>\n            <td>Liste des revendications d'agents prises en charge</td>\n        </tr>\n        <tr>\n            <td><code>agent_types_supported</code></td>\n            <td>array</td>\n            <td>Liste des types d'agents pris en charge</td>\n        </tr>\n        <tr>\n            <td><code>delegation_methods_supported</code></td>\n            <td>array</td>\n            <td>Liste des méthodes de délégation prises en charge</td>\n        </tr>\n        <tr>\n            <td><code>attestation_formats_supported</code></td>\n            <td>array</td>\n            <td>Liste des formats d'attestation pris en charge</td>\n        </tr>\n        <tr>\n            <td><code>attestation_verification_keys_endpoint</code></td>\n            <td>string</td>\n            <td>URL pour récupérer les clés publiques pour vérifier les signatures d'attestation</td>\n        </tr>\n    </tbody>\n</table>\n\n<h2>5. Points de Terminaison</h2>\n\n<h3>5.1 Point de Terminaison d'Attestation des Agents</h3>\n\n<p>Une ressource protégée OAuth 2.0 qui renvoie des informations d'attestation sur un agent ou aide à valider les preuves fournies. URL annoncée via le paramètre de découverte <code>agent_attestation_endpoint</code>.</p>\n\n<h4>5.1.1 Exemple de Requête (Obtenir des Informations)</h4>\n\n<pre><code>GET /agent/attestation?agent_id=123&amp;nonce=abc\nAuthorization: Bearer &lt;token&gt;\n</code></pre>\n\n<h4>5.1.2 Exemple de Réponse</h4>\n\n<pre><code class=\"language-json\">{\n  \"verified\": true,\n  \"provider\": \"openai.com\",\n  \"model\": \"gpt-4\",\n  \"version\": \"2025-03\",\n  \"attestation_timestamp\": 1714348800,\n  \"attestation_signature\": \"...\"\n}\n</code></pre>\n\n<h3>5.2 Point de Terminaison des Capacités des Agents</h3>\n\n<p>Fournit des informations sur les capacités d'un agent. URL annoncée via le paramètre de découverte <code>agent_capabilities_endpoint</code>.</p>\n\n<h4>5.2.1 Exemple de Requête</h4>\n\n<pre><code>GET /.well-known/agent-capabilities\n</code></pre>\n\n<h4>5.2.2 Exemple de Réponse</h4>\n\n<pre><code class=\"language-json\">{\n  \"capabilities\": [\n    {\"id\": \"text_generation\", \"description\": \"...\"},\n    {\"id\": \"code_generation\", \"description\": \"...\"}\n  ],\n  \"supported_constraints\": [\"max_tokens\", \"allowed_tools\"]\n}\n</code></pre>\n\n<h2>6. Considérations de Sécurité</h2>\n\n<h3>6.1 Authentification des Agents</h3>\n\n<p>Les agents DEVRAIENT utiliser des méthodes asymétriques fortes (JWT Client Auth [RFC7523], mTLS [RFC8705]), potentiellement combinées avec l'attestation. Les secrets partagés ne sont PAS RECOMMANDÉS.</p>\n\n<h3>6.2 Sécurité de la Délégation</h3>\n\n<p>Les systèmes DOIVENT valider l'ensemble de la chaîne de délégation, appliquer la réduction de portée, mettre en œuvre des mécanismes de consentement et envisager une limitation temporelle. Les politiques peuvent limiter la longueur de la chaîne. Des mécanismes de révocation robustes sont nécessaires.</p>\n\n<h3>6.3 Sécurité de l'Attestation</h3>\n\n<p>Nécessite une gestion sécurisée des clés de signature, une gestion robuste des nonces, des mesures connues comme bonnes et fiables, des points de terminaison sécurisés et une protection contre les attaques par rejeu. Les preuves d'attestation peuvent avoir des implications en matière de confidentialité.</p>\n\n<h3>6.4 Sécurité des Jetons</h3>\n\n<p>Les jetons d'identité avec des revendications d'agents DEVRAIENT être chiffrés. Les jetons d'accès DEVRAIENT avoir des durées de vie limitées. Les jetons de rafraîchissement pour les agents nécessitent une attention particulière.</p>\n\n<h2>7. Considérations de Confidentialité</h2>\n\n<p>Les implémentations DOIVENT considérer la corrélation potentielle de l'identité des agents, les implications de confidentialité des chaînes de délégation, les exigences de consentement des utilisateurs et la minimisation des données dans les revendications.</p>\n\n<h2>8. Compatibilité et Versionnage</h2>\n\n<p>OIDC-A 1.0 est conçu pour la compatibilité avec OAuth 2.0 [RFC6749], OIDC Core 1.0, JWT [RFC7519] et les RFC associées. Les versions futures viseront la rétrocompatibilité.</p>\n\n<h2>9. Références</h2>\n\n<ul>\n<li>[RFC6749] The OAuth 2.0 Authorization Framework</li>\n<li>[RFC7519] JSON Web Token (JWT)</li>\n<li>[RFC7523] JWT Profile for OAuth 2.0 Client Authentication</li>\n<li>[RFC7591] OAuth 2.0 Dynamic Client Registration</li>\n<li>[RFC7662] OAuth 2.0 Token Introspection</li>\n<li>[RFC8705] OAuth 2.0 Mutual-TLS Client Authentication</li>\n<li>[OpenID Connect Core 1.0]</li>\n<li>[OpenID Connect Discovery 1.0]</li>\n<li>[IETF RATS] Remote Attestation Procedures Architecture</li>\n</ul>\n\n<h2>Annexe A : Exemple de Jeton d'Identité avec Revendications d'Agent</h2>\n\n<pre><code class=\"language-json\">{\n  \"iss\": \"https://auth.example.com\",\n  \"sub\": \"agent_instance_789\",\n  \"aud\": \"client_123\",\n  \"exp\": 1714435200,\n  \"iat\": 1714348800,\n  \"auth_time\": 1714348800,\n  \"nonce\": \"n-0S6_WzA2Mj\",\n  \"agent_type\": \"assistant\",\n  \"agent_model\": \"gpt-4\",\n  \"agent_version\": \"2025-03\",\n  \"agent_provider\": \"openai.com\",\n  \"agent_instance_id\": \"agent_instance_789\",\n  \"delegator_sub\": \"user_456\",\n  \"delegation_purpose\": \"Email management assistant\",\n  \"agent_capabilities\": [\"email:read\", \"email:draft\", \"calendar:view\"],\n  \"agent_trust_level\": \"verified\",\n  \"agent_context_id\": \"conversation_123\",\n  \"agent_attestation\": {\n    \"format\": \"urn:ietf:params:oauth:token-type:eat\",\n    \"token\": \"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\",\n    \"timestamp\": 1714348800\n  },\n  \"delegation_chain\": [\n    {\n      \"iss\": \"https://auth.example.com\",\n      \"sub\": \"user_456\",\n      \"aud\": \"agent_instance_789\",\n      \"delegated_at\": 1714348700,\n      \"scope\": \"email profile calendar\"\n    }\n  ]\n}\n</code></pre>\n\n<h2>Annexe B : Exemple de Chaîne de Délégation (Multi-étapes)</h2>\n\n<pre><code class=\"language-json\">\"delegation_chain\": [\n  {\n    \"iss\": \"https://auth.example.com\",\n    \"sub\": \"user_456\",\n    \"aud\": \"agent_instance_789\",\n    \"delegated_at\": 1714348800,\n    \"scope\": \"email calendar\",\n    \"purpose\": \"Manage my emails and calendar\"\n  },\n  {\n    \"iss\": \"https://auth.example.com\",\n    \"sub\": \"agent_instance_789\",\n    \"aud\": \"agent_instance_101\",\n    \"delegated_at\": 1714348830,\n    \"scope\": \"calendar:view\",\n    \"purpose\": \"Analyze available time slots\"\n  }\n]\n</code></pre>\n\n<style>\n.custom-table {\n    width: 100%;\n    border-collapse: collapse;\n    margin-bottom: 1em;\n}\n\n.custom-table th, .custom-table td {\n    border: 1px solid #ddd;\n    padding: 8px;\n    text-align: left;\n}\n\n.custom-table th {\n    background-color: #f2f2f2;\n    font-weight: bold;\n    text-align: center;\n}\n\n.custom-table tr:nth-child(even){background-color: #f9f9f9;}\n\n.custom-table tr:hover {background-color: #ddd;}\n\n.custom-table td {\n    color: #333;\n    vertical-align: top;\n}\n\n.custom-table td:nth-child(2) {\n    text-align: center;\n}\n.custom-table td:nth-child(4) {\n    text-align: center;\n}\n\n.custom-table code {\n    background-color: #eef;\n    padding: 0.2em 0.4em;\n    border-radius: 3px;\n    font-size: 90%;\n}\n</style>",
  "source_hash": "sha256:73ea6cb5f87d953b8052cd05e0a127fa1a9cf036913230dc7e62c81ec066af98",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-02T01:58:04.993916+00:00"
}