A2A・API設計 5問診断

解説: Agent Cardは、serverが何を提供すると宣言し、どの方法で接続するかを示す発見情報です。機密性のある依頼を送る前には、endpoint、認証方式、認可境界、deploymentのtrust policyを別途確認します。 A: 到達できることだけでは、文書内のidentity、skill、権限を独立に証明できません。 B: 発見とsecurity確認を分けるため、dataの開示や機能の実行前に必要な判断を行えます。 C: HTTPSは認証したserver名との通信を保護しますが、掲載された全操作を許可するものではありません。 D: 署名は存在する場合にintegrityの根拠を追加できますが、A2Aでは署名のないpublic Cardが常に利用不可とは限りません。

解説: authenticationとtokenの有効性は認可判断の材料であり、認可そのものではありません。A2A operationではserver側の認可確認が必要で、OAuthのscopeとresource境界はtokenを何に使えるかを制限します。 A: skillの掲載は機能の説明であり、すべてのcallerへ実行権限を与えるものではありません。 B: 有効期限はtoken確認の一部にすぎず、requested resourceやactionへのaccessを証明しません。 C: credentialを、具体的なcaller、operation、resource、server policyの組み合わせで評価できます。 D: 検証していないclient側の申告は、server側の認可確認を置き換えません。

解説: 応答を失うと、serverがtaskを受理したか分からない状態になります。RFC 9110は、operationがidempotentだと分かる場合や、元のrequestが適用されていないと確認できる場合を除き、non-idempotent requestの自動retryに注意を求めています。 A: 無条件の繰り返しは、購入、送信、外部操作などの副作用を重複させます。 B: 新しいtaskも受理済みの処理を重複させる可能性があり、最初の依頼との関連も失います。 C: methodやapplication契約に安全な回復規則があれば、retryは可能です。 D: 状態確認、安定したoperation ID、重複排除を使うと、不明な結果を安全に扱えます。

解説: task、request、error、時刻のidentifierがあれば、多くの障害はeventを関連付けて調べられます。OAuth credentialは機密に保つ必要があり、privacyの観点でも目的に必要なdataだけを保持し、期間とaccessを制限します。 A: tokenとprompt全文は、通常の関連付けには不要なcredentialや個人dataの漏えい面を作ります。 B: 運用上の追跡可能性を保ちながら、logから取得できるsensitive dataを減らせます。 C: 復号可能なcontentは依然として機密dataで、applicationやkeyの侵害時に露出します。 D: 短期間でも、保持中のaccess controlとdata minimizationは必要です。

解説: TLS 1.3は、認証され、機密性とintegrityを備えたchannelを提供するためのprotocolです。その上でapplicationは、endpoint、caller、requested action、data、現在のpolicyが合うかを別途判断します。 A: channel authenticationは、任意のbusiness actionを行うauthorityを与えません。 B: TLSはnamed serverへのtransportを保護しますが、application claimの正しさやfreshnessまでは検証しません。 C: TLSの保証範囲を、上位のidentity、capability、authorizationへ広げずに説明しています。 D: application-levelの重複処理やreplayの影響には、別のprotocol ruleが必要です。