{
  "title": "OpenID Connect für Agenten (OIDC-A) 1.0 Vorschlag",
  "excerpt": "Technischer Vorschlag zur Erweiterung von OpenID Connect Core 1.0, um ein Framework für die Darstellung, Authentifizierung und Autorisierung von LLM-basierten Agenten innerhalb des OAuth 2.0-Ökosystems bereitzustellen.",
  "content_html": "<p><em>Dieses Dokument schlägt eine Standarderweiterung für OpenID Connect vor, um die Identität von LLM-basierten Agenten darzustellen und zu verifizieren. Es integriert den Kernvorschlag mit detaillierten Frameworks für Verifizierung, Attestierung und Delegationsketten.</em></p>\n\n<h2>Abstract</h2>\n\n<p>OpenID Connect für Agenten (OIDC-A) 1.0 ist eine Erweiterung von OpenID Connect Core 1.0, die ein Framework für die Darstellung, Authentifizierung und Autorisierung von LLM-basierten Agenten innerhalb des OAuth 2.0-Ökosystems bereitstellt. Diese Spezifikation definiert Standard-Claims, Endpunkte und Protokolle zur Etablierung der Agentenidentität, Verifizierung der Agenten-Attestierung, Darstellung von Delegationsketten und Ermöglichung einer feingranularen Autorisierung basierend auf Agentenattributen.</p>\n\n<h2>1. Einführung</h2>\n\n<h3>1.1 Begründung</h3>\n\n<p>Da LLM-basierte Agenten in digitalen Ökosystemen zunehmend verbreitet sind, besteht ein wachsender Bedarf an standardisierten Methoden zur Darstellung ihrer Identität und Verwaltung ihrer Autorisierung. Traditionelle OAuth 2.0- und OpenID Connect-Protokolle wurden primär für menschliche Benutzer und konventionelle Anwendungen entwickelt und verfügen nicht über die notwendigen Konstrukte zur Darstellung der einzigartigen Eigenschaften autonomer Agenten, wie:</p>\n\n<ul>\n<li>Handeln im Namen von Benutzern mit unterschiedlichen Autonomiegraden</li>\n<li>Operieren innerhalb von Delegationsketten</li>\n<li>Besitz dynamischer Fähigkeiten basierend auf ihren zugrunde liegenden Modellen</li>\n<li>Erfordernis der Attestierung ihrer Integrität und Herkunft</li>\n</ul>\n\n<p>Diese Spezifikation adressiert diese Lücken durch Erweiterung von OpenID Connect, um ein umfassendes Framework für Agentenidentität und -autorisierung bereitzustellen.</p>\n\n<h3>1.2 Terminologie</h3>\n\n<p>Diese Spezifikation verwendet die in OAuth 2.0 [RFC6749], OpenID Connect Core 1.0 definierten Begriffe sowie die folgenden zusätzlichen Begriffe:</p>\n\n<ul>\n<li><strong>Agent</strong>: Eine LLM-basierte Software-Entität, die zu autonomen oder semi-autonomen Aktionen basierend auf natürlichsprachlichen Anweisungen fähig ist.</li>\n<li><strong>Agent Provider</strong>: Die Organisation, die für die Erstellung, das Training und/oder das Hosting des Agenten verantwortlich ist.</li>\n<li><strong>Agent Model</strong>: Das spezifische LLM-Modell, das den Agenten antreibt (z.B. GPT-4, Claude 3).</li>\n<li><strong>Agent Instance</strong>: Eine spezifische laufende Instanz eines Agenten, typischerweise mit einer bestimmten Aufgabe oder Konversation verbunden.</li>\n<li><strong>Delegator</strong>: Die Entität (typischerweise ein menschlicher Benutzer), die einem Agenten die Befugnis delegiert, in ihrem Namen zu handeln.</li>\n<li><strong>Delegation Chain</strong>: Eine Sequenz von Delegationsschritten vom ursprünglichen Benutzer durch potenziell mehrere Agenten.</li>\n<li><strong>Attestation</strong>: Kryptografischer Nachweis der Integrität, Herkunft und/oder Eigenschaften eines Agenten.</li>\n<li><strong>Attestation Evidence</strong>: Datenstruktur, die den für die Attestierung verwendeten Nachweis enthält.</li>\n<li><strong>Relying Party (RP)</strong>: In diesem Kontext oft ein Resource Server oder eine Client-Anwendung, die die Identität und Autorisierung eines Agenten verifizieren muss.</li>\n</ul>\n\n<h3>1.3 Überblick</h3>\n\n<p>OIDC-A erweitert OpenID Connect durch:</p>\n\n<ol>\n<li>Definition neuer Standard-Claims zur Darstellung von Agentenidentität, Delegation und Fähigkeiten.</li>\n<li>Spezifikation von Mechanismen und Formaten für Agenten-Attestierungsnachweise.</li>\n<li>Etablierung von Protokollen zur Darstellung und Validierung von Delegationsketten.</li>\n<li>Bereitstellung von Discovery-Mechanismen für Agentenfähigkeiten und Attestierungsunterstützung.</li>\n<li>Definition von Autorisierungs-Frameworks, die für agentenspezifische Anwendungsfälle geeignet sind.</li>\n<li>Einführung von Endpunkten für Attestierungsverifizierung und Fähigkeiten-Discovery.</li>\n</ol>\n\n<h2>2. Agentenidentitäts-Claims</h2>\n\n<h3>2.1 Kern-Agentenidentitäts-Claims</h3>\n\n<p>Die folgenden Claims MÜSSEN oder SOLLTEN in ID Tokens enthalten sein, die an oder über Agenten ausgestellt werden:</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Claim</th>\n            <th>Typ</th>\n            <th>Beschreibung</th>\n            <th>Anforderung</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_type</code></td>\n            <td>string</td>\n            <td>Identifiziert den Typ/die Klasse des Agenten (z.B. \"assistant\", \"retrieval\", \"coding\")</td>\n            <td>REQUIRED</td>\n        </tr>\n        <tr>\n            <td><code>agent_model</code></td>\n            <td>string</td>\n            <td>Identifiziert das spezifische Modell (z.B. \"gpt-4\", \"claude-3-opus\", \"gemini-pro\")</td>\n            <td>REQUIRED</td>\n        </tr>\n        <tr>\n            <td><code>agent_version</code></td>\n            <td>string</td>\n            <td>Versionskennung des Agentenmodells</td>\n            <td>RECOMMENDED</td>\n        </tr>\n        <tr>\n            <td><code>agent_provider</code></td>\n            <td>string</td>\n            <td>Organisation, die den Agenten bereitstellt/hostet (z.B. \"openai.com\", \"anthropic.com\")</td>\n            <td>REQUIRED</td>\n        </tr>\n        <tr>\n            <td><code>agent_instance_id</code></td>\n            <td>string</td>\n            <td>Eindeutige Kennung für diese spezifische Instanz des Agenten</td>\n            <td>REQUIRED</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.2 Delegations- und Autoritäts-Claims</h3>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Claim</th>\n            <th>Typ</th>\n            <th>Beschreibung</th>\n            <th>Anforderung</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>delegator_sub</code></td>\n            <td>string</td>\n            <td>Subject-Identifikator der Entität, die diesem Agenten zuletzt Befugnis delegiert hat</td>\n            <td>REQUIRED</td>\n        </tr>\n        <tr>\n            <td><code>delegation_chain</code></td>\n            <td>array</td>\n            <td>Geordnetes Array von Delegationsschritten (siehe Abschnitt 2.4.2)</td>\n            <td>OPTIONAL</td>\n        </tr>\n        <tr>\n            <td><code>delegation_purpose</code></td>\n            <td>string</td>\n            <td>Beschreibung des Zwecks/der Absicht, für die Befugnis delegiert wurde</td>\n            <td>RECOMMENDED</td>\n        </tr>\n        <tr>\n            <td><code>delegation_constraints</code></td>\n            <td>object</td>\n            <td>Einschränkungen, die dem Agenten vom Delegator auferlegt wurden</td>\n            <td>OPTIONAL</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.3 Fähigkeits-, Vertrauens- und Attestierungs-Claims</h3>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Claim</th>\n            <th>Typ</th>\n            <th>Beschreibung</th>\n            <th>Anforderung</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_capabilities</code></td>\n            <td>array</td>\n            <td>Array von Fähigkeitskennungen, die darstellen, was der Agent tun kann</td>\n            <td>RECOMMENDED</td>\n        </tr>\n        <tr>\n            <td><code>agent_trust_level</code></td>\n            <td>string</td>\n            <td>Vertrauensklassifizierung des Agenten (z.B. \"verified\", \"experimental\")</td>\n            <td>OPTIONAL</td>\n        </tr>\n        <tr>\n            <td><code>agent_attestation</code></td>\n            <td>object</td>\n            <td>Attestierungsnachweis oder Referenz (siehe Abschnitt 2.4.4)</td>\n            <td>RECOMMENDED</td>\n        </tr>\n        <tr>\n            <td><code>agent_context_id</code></td>\n            <td>string</td>\n            <td>Kennung für den Konversations-/Aufgabenkontext</td>\n            <td>RECOMMENDED</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>2.4 Claim-Formate und Validierung</h3>\n\n<h4>2.4.1 <code>agent_type</code></h4>\n<p>String-Wert aus einem definierten Satz von Agententypen. Implementierer SOLLTEN einen der folgenden Werte verwenden, wenn zutreffend:</p>\n<ul>\n<li><code>assistant</code>: Allzweck-Assistenten-Agent</li>\n<li><code>retrieval</code>: Agent spezialisiert auf Informationsabruf</li>\n<li><code>coding</code>: Agent spezialisiert auf Code-Generierung oder -Analyse</li>\n<li><code>domain_specific</code>: Agent spezialisiert für eine bestimmte Domäne</li>\n<li><code>autonomous</code>: Agent mit hohem Autonomiegrad</li>\n<li><code>supervised</code>: Agent, der menschliche Aufsicht für Schlüsselaktionen benötigt</li>\n</ul>\n\n<p>Benutzerdefinierte Typen KÖNNEN verwendet werden, SOLLTEN aber dem Format <code>vendor:type</code> folgen (z.B. <code>acme:financial_advisor</code>).</p>\n\n<h4>2.4.2 <code>delegation_chain</code></h4>\n<p>JSON-Array mit Objekten, die jeden Schritt in der Delegationskette darstellen, vom ursprünglichen Benutzer bis zum aktuellen Agenten. Jedes Objekt MUSS enthalten:</p>\n<ul>\n<li><code>iss</code>: REQUIRED. String, der den Authorization Server oder die Entität identifiziert, die diesen Delegationsschritt ausgestellt/validiert hat.</li>\n<li><code>sub</code>: REQUIRED. String, der den Delegator identifiziert (die Entität, die Berechtigung erteilt).</li>\n<li><code>aud</code>: REQUIRED. String, der den Delegatee identifiziert (der Agent, der Berechtigung erhält).</li>\n<li><code>delegated_at</code>: REQUIRED. NumericDate, das den Zeitpunkt der Delegation darstellt.</li>\n<li><code>scope</code>: REQUIRED. Leerzeichengetrennter String von OAuth-Scopes, die die in diesem Delegationsschritt erteilten Berechtigungen darstellen. MUSS eine Teilmenge der vom Delegator (<code>sub</code>) gehaltenen Scopes sein.</li>\n<li><code>purpose</code>: OPTIONAL. String, der den beabsichtigten Zweck dieses Delegationsschritts beschreibt.</li>\n<li><code>constraints</code>: OPTIONAL. JSON-Objekt, das Einschränkungen für die Delegation spezifiziert (z.B. <code>{\"max_duration\": 3600, \"allowed_resources\": [\"/data/abc\"]}</code>).</li>\n<li><code>jti</code>: OPTIONAL. Eine eindeutige Kennung für diesen spezifischen Delegationsschritt, nützlich für Widerruf oder Nachverfolgung.</li>\n</ul>\n\n<p>Das Array MUSS chronologisch geordnet sein.</p>\n\n<p><em>Validierungsregeln für <code>delegation_chain</code> (durchgeführt von Relying Party):</em></p>\n<ol>\n<li><strong>Reihenfolgenverifizierung:</strong> Chronologische Reihenfolge basierend auf <code>delegated_at</code> bestätigen.</li>\n<li><strong>Issuer-Vertrauen:</strong> Verifizieren, dass jeder <code>iss</code> vertrauenswürdig ist.</li>\n<li><strong>Audience-Matching:</strong> Bestätigen, dass <code>aud</code> von Schritt N mit <code>sub</code> von Schritt N+1 übereinstimmt.</li>\n<li><strong>Scope-Reduktion:</strong> Verifizieren, dass <code>scope</code> in jedem Schritt eine Teilmenge der/gleich den verfügbaren Scopes des Delegators ist.</li>\n<li><strong>Constraint-Durchsetzung:</strong> Einhaltung aller <code>constraints</code> sicherstellen.</li>\n<li><strong>Signaturvalidierung (falls zutreffend):</strong> Signaturen validieren, wenn Schritte einzeln signiert sind.</li>\n<li><strong>Policy-Prüfung:</strong> Die validierte Kette gegen Autorisierungsrichtlinien bewerten (z.B. maximale Länge).</li>\n</ol>\n\n<h4>2.4.3 <code>agent_capabilities</code></h4>\n<p>Array von String-Kennungen, die die Fähigkeiten des Agenten darstellen. Implementierer SOLLTEN Fähigkeitskennungen aus einer gut definierten Taxonomie verwenden, wenn verfügbar. Benutzerdefinierte Fähigkeiten SOLLTEN dem Format <code>vendor:capability</code> folgen (z.B. <code>acme:financial_analysis</code>).</p>\n\n<h4>2.4.4 <code>agent_attestation</code></h4>\n<p>JSON-Objekt, das Attestierungsnachweise oder eine Referenz darauf enthält. MUSS ein <code>format</code>-Feld enthalten, das den Typ des Nachweises angibt.</p>\n\n<p><em>Empfohlenes Format:</em> JWT-basiert, potenziell kompatibel mit IETF RATS Entity Attestation Token (EAT).</p>\n\n<p>Beispiel:</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>Andere Formate (z.B. <code>\"format\": \"TPM2-Quote\"</code>, <code>\"format\": \"SGX-Quote\"</code>) KÖNNEN verwendet werden.</p>\n\n<h2>3. Protokollablauf</h2>\n\n<h3>3.1 Agenten-Authentifizierungsablauf</h3>\n\n<p>Der OIDC-A-Authentifizierungsablauf erweitert den Standard-OpenID Connect-Authentifizierungsablauf:</p>\n\n<ol>\n<li><strong>Client-Registrierung</strong>: Clients, die Agenten repräsentieren, MÜSSEN zusätzliche Metadaten registrieren (siehe Abschnitt 4).</li>\n<li><strong>Authentifizierungsanfrage</strong>: Agenten SOLLTEN den <code>agent</code>-Scope und potenziell <code>delegation_context</code> einschließen.</li>\n<li><strong>Authentifizierungsantwort</strong>: Der Authorization Server schließt agentenspezifische Claims im ID Token ein.</li>\n<li><strong>Token-Validierung</strong>: RPs MÜSSEN Standard-OIDC-Claims und relevante agentenspezifische Claims (einschließlich Attestierung und Delegation, falls vorhanden) gemäß Richtlinie validieren.</li>\n</ol>\n\n<h3>3.2 Delegationsablauf</h3>\n\n<p>Wenn einem Agenten Befugnis delegiert wird:</p>\n\n<ol>\n<li>Der Delegator authentifiziert sich und autorisiert die Delegation.</li>\n<li>Der Authorization Server stellt ein neues ID Token für den Agenten aus, einschließlich <code>delegator_sub</code>, <code>delegation_chain</code> (aktualisiert), <code>delegation_purpose</code> und eingeschränktem <code>scope</code>.</li>\n</ol>\n\n<h3>3.3 Attestierungsverifizierungsablauf</h3>\n\n<p>Um die Attestierung eines Agenten zu verifizieren:</p>\n\n<ol>\n<li>Der Agent schließt den <code>agent_attestation</code>-Claim in seinem ID Token ein oder stellt Nachweise separat bereit.</li>\n<li>Die RP validiert die Nachweise basierend auf dem spezifizierten <code>format</code>:\n<ul>\n<li>Kryptografische Signaturen mit vertrauenswürdigen Schlüsseln verifizieren (über Discovery erhalten).</li>\n<li>Plattformmessungen mit bekannten guten Werten vergleichen.</li>\n<li>Nonces validieren, um Replay-Angriffe zu verhindern.</li>\n<li>Optional den <code>agent_attestation_endpoint</code> für Validierungsunterstützung verwenden.</li>\n</ul>\n</li>\n<li>Autorisierungsentscheidungen beziehen den Attestierungsstatus ein (z.B. <code>verified: true/false</code>).</li>\n</ol>\n\n<h2>4. Client-Registrierung und Discovery</h2>\n\n<h3>4.1 Agenten-Client-Registrierungsmetadaten</h3>\n\n<p>Erweitert OAuth 2.0 Dynamic Client Registration [RFC7591]:</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Parameter</th>\n            <th>Typ</th>\n            <th>Beschreibung</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_provider</code></td>\n            <td>string</td>\n            <td>Kennung des Agent Providers</td>\n        </tr>\n        <tr>\n            <td><code>agent_models_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Agentenmodelle</td>\n        </tr>\n        <tr>\n            <td><code>agent_capabilities</code></td>\n            <td>array</td>\n            <td>Liste der Agentenfähigkeiten</td>\n        </tr>\n        <tr>\n            <td><code>attestation_formats_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Attestierungsformate</td>\n        </tr>\n        <tr>\n            <td><code>delegation_methods_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Delegationsmethoden</td>\n        </tr>\n    </tbody>\n</table>\n\n<h3>4.2 Discovery-Metadaten</h3>\n\n<p>Erweitert OpenID Connect Discovery 1.0:</p>\n\n<table class=\"custom-table\">\n    <thead>\n        <tr>\n            <th>Parameter</th>\n            <th>Typ</th>\n            <th>Beschreibung</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td><code>agent_attestation_endpoint</code></td>\n            <td>string</td>\n            <td>URL des Attestierungs-Endpunkts</td>\n        </tr>\n        <tr>\n            <td><code>agent_capabilities_endpoint</code></td>\n            <td>string</td>\n            <td>URL des Fähigkeiten-Discovery-Endpunkts</td>\n        </tr>\n        <tr>\n            <td><code>agent_claims_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Agenten-Claims</td>\n        </tr>\n        <tr>\n            <td><code>agent_types_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Agententypen</td>\n        </tr>\n        <tr>\n            <td><code>delegation_methods_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Delegationsmethoden</td>\n        </tr>\n        <tr>\n            <td><code>attestation_formats_supported</code></td>\n            <td>array</td>\n            <td>Liste unterstützter Attestierungsformate</td>\n        </tr>\n        <tr>\n            <td><code>attestation_verification_keys_endpoint</code></td>\n            <td>string</td>\n            <td>URL zum Abrufen öffentlicher Schlüssel zur Verifizierung von Attestierungssignaturen</td>\n        </tr>\n    </tbody>\n</table>\n\n<h2>5. Endpunkte</h2>\n\n<h3>5.1 Agenten-Attestierungs-Endpunkt</h3>\n\n<p>Eine OAuth 2.0-geschützte Ressource, die Attestierungsinformationen über einen Agenten zurückgibt oder bei der Validierung bereitgestellter Nachweise unterstützt. URL wird über den <code>agent_attestation_endpoint</code>-Discovery-Parameter bekanntgegeben.</p>\n\n<h4>5.1.1 Anfrage-Beispiel (Info abrufen)</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 Antwort-Beispiel</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 Agenten-Fähigkeiten-Endpunkt</h3>\n\n<p>Stellt Informationen über die Fähigkeiten eines Agenten bereit. URL wird über den <code>agent_capabilities_endpoint</code>-Discovery-Parameter bekanntgegeben.</p>\n\n<h4>5.2.1 Anfrage-Beispiel</h4>\n\n<pre><code>GET /.well-known/agent-capabilities\n</code></pre>\n\n<h4>5.2.2 Antwort-Beispiel</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. Sicherheitsüberlegungen</h2>\n\n<h3>6.1 Agenten-Authentifizierung</h3>\n\n<p>Agenten SOLLTEN starke, asymmetrische Methoden verwenden (JWT Client Auth [RFC7523], mTLS [RFC8705]), potenziell kombiniert mit Attestierung. Gemeinsame Geheimnisse werden NICHT EMPFOHLEN.</p>\n\n<h3>6.2 Delegationssicherheit</h3>\n\n<p>Systeme MÜSSEN die gesamte Delegationskette validieren, Scope-Reduktion durchsetzen, Zustimmungsmechanismen implementieren und zeitliche Begrenzung in Betracht ziehen. Richtlinien können die Kettenlänge begrenzen. Robuste Widerrufsmechanismen sind erforderlich.</p>\n\n<h3>6.3 Attestierungssicherheit</h3>\n\n<p>Erfordert sichere Verwaltung von Signaturschlüsseln, robuste Nonce-Handhabung, vertrauenswürdige bekannte gute Messungen, sichere Endpunkte und Schutz vor Replay-Angriffen. Attestierungsnachweise können Datenschutzimplikationen haben.</p>\n\n<h3>6.4 Token-Sicherheit</h3>\n\n<p>ID Tokens mit Agenten-Claims SOLLTEN verschlüsselt werden. Access Tokens SOLLTEN begrenzte Lebensdauern haben. Refresh Tokens für Agenten erfordern sorgfältige Überlegung.</p>\n\n<h2>7. Datenschutzüberlegungen</h2>\n\n<p>Implementierungen MÜSSEN potenzielle Korrelation der Agentenidentität, Datenschutzimplikationen von Delegationsketten, Anforderungen an Benutzerzustimmung und Datenminimierung in Claims berücksichtigen.</p>\n\n<h2>8. Kompatibilität und Versionierung</h2>\n\n<p>OIDC-A 1.0 ist für Kompatibilität mit OAuth 2.0 [RFC6749], OIDC Core 1.0, JWT [RFC7519] und verwandten RFCs konzipiert. Zukünftige Versionen werden Abwärtskompatibilität anstreben.</p>\n\n<h2>9. Referenzen</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>Anhang A: Beispiel-ID-Token mit Agenten-Claims</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>Anhang B: Beispiel-Delegationskette (Mehrschrittig)</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; /* Add some space below tables */\n}\n\n.custom-table th, .custom-table td {\n    border: 1px solid #ddd;\n    padding: 8px;\n    text-align: left; /* Default alignment */\n}\n\n.custom-table th {\n    background-color: #f2f2f2;\n    font-weight: bold; /* Make headers bold */\n    text-align: center; /* Center align headers */\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; /* Darker text for better readability */\n    vertical-align: top; /* Align content top */\n}\n\n/* Center align specific columns */\n.custom-table td:nth-child(2) { /* Type column */\n    text-align: center;\n}\n.custom-table td:nth-child(4) { /* Requirement column */\n    text-align: center;\n}\n\n/* Style inline code within tables */\n.custom-table code {\n    background-color: #eef; /* Light background for code */\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:10.073711+00:00"
}