ToppyMicroServices

RFC 8615 クイズ

発見locationとorigin境界

🇺🇸🇯🇵
0 / 0

一次資料

登録されたパスの規約と、アプリケーションが定めるホスト名の選択、メタデータの適用範囲、ブラウザ対策、運用方針を区別します。Section番号はRFC 8615を指します。

Q1: agent-cardが登録済みであるとして、対応スキームでwell-known URIとなるパスはどれ？

単一選択
RFC 8615 Section 3は、/.well-known/で始まり、その後に登録名が続くパスをwell-known URIと定義するため、Aが該当する。Bは接頭辞を別のパス要素の下に置いている。Cは予約された接頭辞にすぎず、RFCはそこに表現形式を定義しておらず、クライアントもリソースの存在を期待すべきではない。

Q2: 登録審査として正しい指摘はどれ？

単一選択

A2Aの提案では/.well-known/metadata/agentsを使うため、登録するURI suffixをmetadata/agentsとして申請している。仕様には、登録名に続くパス要素の構文が定義されていない。

RFC 8615 Section 3では、登録名はsegment-nzに適合し、/を含んではならない。一方、登録仕様は後続のパス要素、query、fragmentの構文を定義できる。Bは両方の境界を守る。Aは複数segmentを一つの名前として扱い、Cは別々の登録に合成の意味を勝手に与え、Dはqueryの前に必要な登録suffixを消してしまう。

Q3: この登録提案に不足しているものはどれ？

単一選択

提案にはsuffix、変更管理者、仕様文書、provisional statusが記載されている。しかし仕様はリソースを「agent metadata」と呼ぶだけで、表現形式と対応するmedia typeを定義していない。通常のHTTPとHTTPSで使う予定である。

RFC 8615 Section 3は、参照する仕様に取得形式と対応するmedia typeの定義を求めるため、不足しているのはCである。RFCは固定ホスト名、専用CA、共通redirect先を要求しない。Dも誤りで、schemeを明記しない場合はHTTPとHTTPSが仮定される。別のschemeを使うなら、その対応を明示する必要がある。

Q4: クライアント間の相互運用に必要な修正はどれ？

単一選択

A2A profileはsuffix a2aを登録した。識別子alice@example.comを受け取った一方のクライアントはexample.comを、別のクライアントはagents.example.comを探索し、どちらもRFC 8615準拠だと主張する。profileにはホスト名の選択規則がない。

RFC 8615 Section 3はホスト名の決め方を定義せず、アプリケーションに委ねている。Bは不足する相互運用規則とauthorityの境界を補う。AはRFCにない命名規則を作り、Cはtransport認証と接続先選択を混同し、Dは互換性のない危険な推測を残す。

Q5: redirect先のmetadataをauthoritativeとして受理してよい？

単一選択

profileはtenant.exampleを選び、https://tenant.example/.well-known/a2aへ接続する。serverはhttps://metadata.example.net/a2a/tenantへredirectする。両方のホストでTLS検証は成功するが、profileはredirectとoriginをまたぐauthorityを定義していない。

RFC 8615 Section 3は発見方法とmetadataのscopeをアプリケーションに委ね、Section 4.3はorigin間の管理関係を勝手に仮定する危険を警告する。したがってCはprofileに不足する規則を特定している。AとBは、二つのTLS channelからは得られない委任を推測している。Dも強すぎる断定であり、RFCはredirectを一律禁止していない。

Q6: profileとRFC 8615に合うクライアント動作はどれ？

単一選択

A2A profileは探索先をhttps://host.example:9443/.well-known/a2aと明示している。deploymentもこのportを使い、登録suffixは単にa2aである。

RFC 8615 Section 3によれば、通常はschemeのdefault portを使うが、applicationが明示すれば代替portも利用できる。したがってCが正しい。Aは通常の選択を禁止事項に変え、BはRFCにないport scanningを導入し、Dは登録するパスsuffixとURI authorityを混同する。

Q7: 既定のtrust boundaryを最もよく保つ配備変更はどれ？

単一選択

platform.exampleには無関係な複数tenantが同居している。各tenantは自分のパスへfileを公開できるが、reverse proxyの規則により、どのtenantも/.well-known/a2aへ書き込める。クライアントはそのresourceをplatform全体のmetadataとして解釈する。

RFC 8615 Section 4.1は、well-known locationが実質的にorigin全体を代表するため、とくに複数entityが同居する場合はwrite accessを適切に制御すべきだとする。Bは所有権限とscopeを一致させる。AはfilesystemやUIの慣習を保護機構と誤認し、Cは悪意ある内容の公開を防げず、Dはauthorityを直さないまま安定した探索を壊す。

Q8: 最も正確なsecurity reviewはどれ？

単一選択

状態を変更するwell-known endpointは、HttpOnly; Secure; Path=/.well-known/a2aを付けたcookieで認証する。同じoriginの無関係なapplicationにはXSS脆弱性がある。設計者は、この属性によりscriptから認証済みrequestを発生させられないと考えている。

RFC 8615 Section 4.2は、同一originへ注入されたcontentがwell-known resourceへ任意のrequestを送れる可能性を警告する。HttpOnlyはscriptからcookie値を読めなくし、Pathはbrowserが送るパスを絞るが、別originを作らず、状態変更をauthorizeするものでもない。Dはこれらの緩和策とapplication側のrequest検証を分けている。AとBはcookie属性を過大評価し、Cは名前衝突しか扱わない。

Q9: 機密性の要件に対する設計レビューとして、最も適切なのはどれ？

単一選択

あるoriginは/.well-known/agent-cardでAgent Cardを公開している。Cardには公開endpointと、再利用可能なbootstrap用bearer tokenが含まれる。同じorigin上の無関係なWeb applicationはbrowser scriptを実行できるが、tokenは機密でなければならない。

RFC 8615 Section 4.2は、well-known resourceもbrowserからaccessでき、同一originの他contentと相互作用することを警告している。このprefixは機密領域を作らない。Cは公開発見とtoken機密性の両方を満たす。Aは場所を隠すだけ、BはRFCにない隔離を仮定し、DはcredentialをURLやlogへ露出させる。

Q10: 発見したpolicyを二つのsibling hostへ適用してよい？

単一選択

userがbilling.exampleを選び、clientはbilling.example/.well-known/a2aからHTTPS documentを取得した。documentはscopeを*.exampleと宣言し、admin.exampleをendpointとして示す。certificateとdocument signatureは有効だが、A2A profileにはhostname選択やoriginをまたぐscopeの規則がない。

RFC 8615 Section 3は、hostnameの決定とmetadataのscopeをapplicationに委ねる。Section 4.3は、あるoriginのmetadataを別hostへ適用すると、実在しない管理関係を仮定する危険があると警告する。HTTPSとdocument signatureはchannelとsignerをそれぞれ認証しても、欠けているA2Aのauthority規則は補わない。Cが必要なprofile設計を示す。Dは強すぎる断定であり、RFCは別endpointへの参照を一律禁止していない。

Q11: RFC 8615が指摘する配備リスクに対応するprofile変更はどれ？

単一選択

企業が20万件のpartner domainをimportする。クライアントは全domainのhttps://domain/.well-known/a2aを直ちにprobeし、失敗時も無制限にretryする。大半のdomainはA2Aを導入しておらず、Web運用者から予期しない大量requestが報告された。

RFC 8615 Section 4.3は、特定hostnameへのbootstrapにより、未対応serverへ大量の不要requestが送られ、DoS attackに見える危険を警告する。RFCは単一のalgorithmを規定しないが、与えられたworkloadにはBのapplication profile対策が妥当である。Aは登録を配備側の同意と誤認し、CとDは適用条件を定めず、負荷や観測性をさらに悪化させる。

Q12: deploymentを止めるべきfindingはどれ？

単一選択

hosting control panelは、dotで始まるdirectoryを表示しない。content upload用accountからpanel上の.well-knownは見えないが、authorization testでは配信中の/.well-known/a2aへ直接書き込めた。管理者は隠しdirectoryなので保護されると考えている。

RFC 8615 Section 4.4は、管理者が隠し.well-known directoryの存在に気付かない一方、write accessを持つ攻撃者が内容を支配できる危険を警告する。CはUIではなく観測済みのpermissionに基づく。AとBは非表示とaccess controlを混同し、Dは実行可能contentでなくても偽のdiscovery metadataが害を生む点を見落としている。