Agent2Agent仕様の認証と認可の翻訳

Agent2Agentの仕様の認証と認可に関する章だけ翻訳したので、メモとして残しておく。

認証の方法はAgent2Agentでは定義されていません。OAuth 2.0で認可がおこなってそのトークンを使うか、APIキーを使うかなどの指定はありません。 AgentCardを使ってエージェントの能力や認証した方法など様々な情報がわかるようになっています。

翻訳

A2Aは、エージェントを標準的なエンタープライズアプリケーションとして扱い、確立されたWebセキュリティプラクティスに準拠します。アイデンティティ情報はA2A JSON-RPCペイロード内では送信 されず 、HTTPトランスポート層で処理されます。

エンタープライズセキュリティの側面に関する包括的なガイドについては、エンタープライズ対応機能を参照してください。

セクション3.1に記載されているように、本番環境ではHTTPSを使用しなければなりません（MUST）。実装では、強力な暗号スイートを備えた最新のTLS構成（TLS 1.2以上を推奨）を使用すべきです（SHOULD）。

A2Aクライアントは、TLSハンドシェイク中に信頼できる証明機関（CA）に対してTLS証明書を検証することにより、A2Aサーバーのアイデンティティを確認すべきです（SHOULD）。

要件の検出：クライアントは、AgentCardの authentication フィールドを介してサーバーが必要とする認証スキームを検出します。スキーム名は、多くの場合、OpenAPI認証方法と一致します（例、OAuth 2.0トークンの場合は「Bearer」、Basic認証の場合は「Basic」、APIキーの場合は「ApiKey」）。
資格情報の取得（帯域外）：クライアントは、必要な認証スキームとアイデンティティプロバイダに固有の 帯域外プロセス を通じて、必要な資格情報（例、APIキー、OAuthトークン、JWT）を取得します。このプロセスはA2Aプロトコル自体の範囲外です。
資格情報の送信:クライアントは、サーバーに送信するすべてのA2Aリクエストの適切なHTTPヘッダー(例、 Authorization: Bearer <token> 、 X-API-Key: <value>) ）にこれらの資格情報を含めます。

A2Aサーバーは：

提供されたHTTP資格情報とAgentCardで宣言された認証要件に基づいて、すべての受信リクエストを認証しなければなりません（MUST）。
認証チャレンジまたは拒否には、401 Unauthorizedまたは403 Forbiddenのようなの標準のHTTPステータスコードを使用すべきです（SHOULD）。
必要な認証スキームを示してクライアントを誘導するため、 401 Unauthorized レスポンスに関連するHTTPヘッダー（例、WWW-Authenticate）を含めるべきです（SHOULD）。

エージェントがタスクの実行中に、別のシステムまたはリソースに対する追加の資格情報を必要とする場合（例、独自の認証を必要とするユーザーに代わって特定のツールにアクセスする場合）は：

A2Aタスクを auth-required 状態（TaskState参照）に遷移させるべきです（SHOULD）。
付随する TaskStatus.message （多くの場合DataPart）は、PushNotificationAuthenticationInfoのような構造を利用して必要性を記述するなど、必要な二次認証に関する詳細を提供すべきです（SHOULD）。
A2Aクライアントは、これらの新しい認証情報を帯域外で取得し、後続のmessage/sendまたはmessage/streamリクエストで提供します。これらの資格情報の使用方法（例、エージェントがプロキシ接続している場合はA2Aメッセージ内のデータとして渡されるか、クライアントが二時システムと直接やり取りするために使用されるか）は、具体的なシナリオによって異なります。

クライアントが認証されると、A2Aサーバーは認証されたクライアント/ユーザーのアイデンティティと自身のポリシーに基づいてリクエストを認可する責任を負います。認可ロジックは実装依存であり、以下の基準に基づいて適用されることがあります（MAY）。

サーバーは最小権限の原則を実装すべきです。