ToppyMicroServices

RFC 9728 Quiz (JA)

OAuth 2.0 Protected Resource Metadata

ENJA
0 / 0

参考URL

Q1: OAuth protected resource metadataは何を記述するか？

Multiple Choice
RFC 9728 Section 1と2は,clientとauthorization serverがprotected resourceとinteractionするためのconfiguration情報を定義します.documentはrelationshipやcapabilityをadvertiseできますが,grantやtokenを発行せず,resourceによるcredential validationやpolicy判断も実行しません.内容はdiscoveryとapplication trust decisionへのinputであり,authorization結果ではありません.

Q2: resourceとauthorization_serversについて正しい記述はどれか.該当するものをすべて選べ.

Multi-Select
RFC 9728 Section 1.2と2はHTTPS `resource` identifierをrequiredとし,`authorization_servers`はoptionalかつ非exhaustiveになり得るとします.list省略は利用可能serverなしを意味せず,`scopes_supported`省略もempty scope setを意味しません.signed metadataもresource syntaxを変えないため,documentを1 resourceへanchorしながらoptional listをcompleteとは推定しません.

Q3: default suffixを使うresource https://api.example/a2a のmetadata取得先はどれか？

Multiple Choice
RFC 9728 Section 3.1はauthorityとresource pathの間へ`/.well-known/oauth-protected-resource`を挿入するため,取得先は`https://api.example/.well-known/oauth-protected-resource/a2a`です.`/a2a`の後ろへsuffixを追加したり,pathをsuffixへ含めたりするとregistered constructionが変わります.同じhost上のresourceを区別するには,well-known componentの後ろへ正確なpathを保ちます.

Q4: metadata documentのresource値がdiscoveryに使ったresourceと一致しない.clientはどうすべきか？

Multiple Choice
RFC 9728 Section 3.3は,返された`resource`とdiscoveryに使ったidentifierのexact equalityを要求し,不一致responseの使用を禁止します.document内のreplacementへ従えば,response自身にtrust targetをredirectさせ,bad memberだけを削除してもunboundなclaimが残ります.shared certificateはhost connectionを認証しても,異なるresource identifierを同じ意味にはしません.

Q5: WWW-Authenticateのresource_metadata parameterは何を提供するか？

Multiple Choice
RFC 9728 Section 5と5.1は,`resource_metadata` authentication parameterをprotected resource metadata documentへのURLと定義し,BearerやDPoPなどのschemeで利用可能とします.parameterへdocumentやaccess tokenが埋め込まれるわけではなく,client registrationも行いません.clientは参照documentを取得し,通常のmetadata validationとtrust checkを適用します.

Q6: capability metadataの解釈として正しいものはどれか.該当するものをすべて選べ.

Multi-Select
RFC 9728 Section 2は`scopes_supported`省略へdefaultやnegative implicationを与えませんが,`dpop_bound_access_tokens_required`省略時はfalseと定義します.default signing algorithmはなく,そのalgorithm listで`none`は禁止されます.Section 7.2は必要最小scopeだけをrequestするよう述べるため,advertised capabilityや省略defaultもleast privilegeとalgorithm policyを置き換えません.

Q7: discoveryされたauthorization serverに対する適切なclient動作はどれか？

Multiple Choice

userが選んだA2A endpointは,resource値がそのendpointと完全一致するprotected resource metadataを返す.authorization_serversにはhttps://169.254.169.254/internal-issuerがあり,clientはそのissuerを設定もtrustもしていない.

RFC 9728 Section 7.7は,resource metadataに記載されたissuerからauthorization-server metadataを取得する処理をSSRF riskとし,internal IP rangeのblockなどを勧めます.Section 3.3のexact resource bindingが検証するのはdocumentのresource identityであり,埋め込まれた全network destinationの安全性やauthorityではありません.clientはRFC 8414 fetch前にoutbound-request controlを適用し,credentialを送らず,issuer metadataを検証した上で,Section 7.6のissuer-to-resource trustを別に確立します.

Q8: clientは列挙されたauthorization serverを自動的にtrustしてよいか？

Multiple Choice

validなprotected resource documentはauthorization_serversにhttps://as.partner.exampleを列挙する.clientにはissuerとresourceを結ぶout-of-band trust rule,federation policy,cross-checkがない.

RFC 9728 Section 7.6は,適切なauthorization serverを安全に決める方法をscope外かつapplication dependentとします.advertised listはdynamic discoveryに使えますがuniversal trust-anchor setではなく,HTTPSとRFC 8414 validationもissuerのconfigurationを認証するだけで,このresourceへのauthorityは証明しません.両metadataを検証した後,authorization開始前に定義済みissuer-to-resource trust policyを適用します.

Q9: このsigned metadataを処理するとき必要なactionはどれか.2つ選べ.

Multi-Select

clientはsigned_metadataへ対応する.plain JSONはAS1を,signed JWTはAS2を列挙する.JWT signatureはvalidだが,clientはそのissをresourceに対してtrustするか未決定である.

RFC 9728 Section 3.3はsignature,issuer key,そのissuerへのtrustを検証するよう求め,数学的なsignature validityだけでは不十分です.validなsigned metadataへ対応する場合,Section 2.2はconflicting plain valueとのunvalidated unionではなくsigned claimのprecedenceを定義します.Section 7.9が説明する異なるtrust basisを踏まえ,signerのauthorityを確立してからprecedenceを適用します.

Q10: resource discoveryとOAuth,A2A proofを正しく合成するend-to-end設計はどれか？

Multiple Choice

A2A clientはresource_metadataを追跡してresource値を検証し,trustedな列挙issuerを選び,RFC 8414 metadataを検証してaudience-restricted DPoP-bound tokenを得る.gatewayはtokenとDPoP proofを検証し,policy担当backendへunsigned identity headerを送る.

RFC 9728 Section 3.3と5はdiscoveryをintended resourceへbindし,Section 7.4はaudience-restricted tokenを勧め,Section 7.6はissuer trustを別の判断として残します.metadataはflowを設定するだけでaccessを発行・受理せず,新しく作ったunsigned headerもDPoP keyやrequestへbindされません.各associationとcredentialをintended endpointで検証し,derived assertionをbackendの最終authorizationまで保護する必要があります.