RFC 8705 Quiz (JA)

OAuth 2.0 mTLS Client AuthenticationとCertificate-Bound Token

0 / 0

参照(URL)

Q1: このaccess tokenはcertificate-boundか

Multiple Choice

confidential A2A clientはPKI mutual-TLS methodでauthorization serverへauthenticateします.発行されたaccess tokenにはcertificate associationがなく,introspectionにもcertificate thumbprintがありません.

**Explanation:** A: Section 1はmutual-TLS client authenticationとcertificate-bound access tokenを別mechanismとし,必ずしも併用しないと説明します. B: Section 3はx5t#S256をtokenへ埋める,またはintrospection metadataで返すなど,protected resourceが参照できるassociationを必要とします. C: 正解です.Section 2はauthorization-server endpointに対するclient認証,Section 3はprotected resourceでのtoken使用制約です. D: RFC 8705は両mechanismを定義しますが,すべてのOAuth tokenにcertificate bindingをmandatoryにはしていません.

Q2: resource serverはself-signed certificateであることだけを理由にこのpublic clientをrejectすべきか

Multiple Choice

public A2A clientがcertificate-bound access tokenを持ちます.resource serverへのmutual-TLS connectionで同じself-signed certificateを提示し,そのthumbprintはtokenと一致します.

**Explanation:** A: Sections 4 and 6.2はpublic clientのcertificate-bound tokenを説明し,このPoP用途ではresource serverがclient-certificate trust chainを検証する必要はないとします. B: Section 4はpublic clientがself-signed certificateでcertificate-bound tokenを使う構成を明示的に認めます. C: certificate possessionは一つの入力です.resource serverはaccess token自体もvalidateしauthorization policyを適用します. D: authorization serverのTLS server certificateはclientのproof-of-possession certificateとは無関係です.

Q3: backendはforwardされたcertificate headerをRFC 8705 bindingに使えるか

Multiple Choice

reverse proxyがmutual TLSをterminateし,resource serverへの転送時にX-Client-Certをappendします.external clientもX-Client-Certを送信でき,proxyは既存値を削除しません.resource serverはtokenをこのconnectionでauthenticateされたcertificateへbindする必要があります.

**Explanation:** A: client-controlled valueをTLS certificateとして選択でき,proxy-authenticated connectionとのbindingを破ります. B: stolen bound tokenを持つattackerは期待されるthumbprintをinjectできますが,対応private keyのpossessionは証明しません. C: Section 3はtoken validationとTLS layerから得たcertificateとのmatchの両方を要求し,alternative checkにはしていません. D: Section 6.5はTLS terminationを認めますが,secureなcertificate-metadata伝達をscope外にしています.Section 3の比較を有効にするにはprofile側でそのhopを保護します.

Q4: clientはcertificate rotation後も古いaccess tokenを再利用できるか

Multiple Choice

A2A clientはcertificate C1からC2へrotateします.C2は同じsubject nameとpublic-key algorithmを持ちますが,DER bytesは異なります.access tokenのx5t#S256はC1を示します.resource serverはRFC 8705 certificate matchを要求します.

**Explanation:** A: Section 3.1のx5t#S256はcertificate subjectではなくDER encodingのSHA-256 hashです. B: Section 6.3はcertificate updateにより以前のcertificateへbindされたaccess tokenがinvalidになり,新token取得で扱えると説明します. C: confirmation valueはcertificate thumbprintを示し,algorithm familyを示しません. D: protected token claimの変更はprotectionを壊し,authorization serverのbinding decisionを置き換えます.

Q5: registration flagはこのtokenがsender-constrainedであると証明するか

Multiple Choice

client metadataはtls_client_certificate_bound_access_tokens=trueです.clientはmutual TLSなしでtoken endpointを呼び,authorization serverはx5t#S256も同等のintrospection metadataもないaccess tokenを返します.resource policyはcertificate-bound tokenだけをacceptします.

**Explanation:** A: Sections 3.3 and 3.4はcapabilityとintent metadataを定義します.個別tokenのbindingはSection 3のassociationから得ます. B: Section 3.4はnon-mutual-TLS request後にerrorを返すかunbound tokenを発行するかをauthorization serverの裁量とします. C: Metadata negotiationはSection 3のprotected resourceによるcertificate-to-token comparisonを置き換えません. D: Section 3.4はこのauthorization-server choiceを意図的にopenにしています.resource serverは独自のbound-token policyを適用できます.

Q6: backendは意図したsender constraintをどう維持できるか

Multiple Choice

A2A agentはcertificate C_agentへbindされたtokenをmutual TLSでgatewayへ提示します.gatewayはC_gatewayを使ってbackendへ別のmutual-TLS connectionを作り,元tokenを転送します.backend policyはこのbackend operationのcallerがC_agentのprivate keyを持つproofを要求します.

**Explanation:** A: Section 3はtokenをC_agentへbindします.C_gatewayは別TLS connectionの別certificateです. B: Gateway trustで新しいarchitectureを構成できますが,backendはgateway assertionを自身のTLS layerから得たdirect proofと誤表示してはいけません. C: Sections 3 and 6.5がRFC mechanismと未規定のproxy hopを分けます.どちらの設計もprofile化できますが,trust boundaryとprotected metadataを明示します. D: token内のsigned thumbprintは,unprotectedなforwarded certificate valueがTLS terminatorから来たことを証明しません.