RFC 9728 Quiz (JA)

**Judgment point:** protected resource metadataはOAuth deploymentのresource server側を説明します. authorization server metadataを補完するものです. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: authorization server metadataは別subjectのdiscovery documentとして残ります. - B: protected resourceとOAuth関連signalがこのRFCの中心です. - C: このRFCはtokenを発行せず, authorization serverの必要性を消しません.

**Judgment point:** clientやauthorization serverは, attacker-selected metadata documentにaccess targetを再定義させてはいけません. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: resource identity validationにより, あるresource用metadataを別resourceへ使う事故を防げます. - B: error responseがmetadataを示すことはありますが, document validationは必要です. - C: HTTPS retrievalがpolicy check前のmetadata pathを守ります. - D: listed authorization serverはpolicy inputであり, 全clientへのuniversal approvalではありません.

**Judgment point:** resource identifierはclientとauthorization serverがwrong resourceへmetadataを適用することを防ぎます. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: human account identityはprotected resource metadata identifierの外側です. - B: consent screen designはresource identifierのsecurity roleではありません. - C: metadataをintended resourceへbindすることがidentifierのkey validation purposeです.

**Judgment point:** このfieldはresourceとauthorization server issuerを結び付けます. relying partyはtrustとpolicyを引き続き確認します. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: listをunconditional approvalではなくscoped discovery informationとして扱っています. - B: clientやdeploymentごとのtrust requirementとpolicy requirementは残ります. - C: issuer identifierはaccess tokenではなく, requestを単独でauthorizeできません.

**Judgment point:** protected resource metadataはclient, resource server, authorization serverの関係を合わせる助けになります. reachabilityはacceptanceではありません. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: 任意のauthorization serverから始めると, resourceが使わないserverを選ぶ可能性があります. - B: resource identity, metadata validation, authorization server compatibilityを分けています. - C: metadata endpointに到達できてもaccess token validationやrequest authorizationにはなりません.

**Judgment point:** metadataはsupportやexpectationをadvertiseできます. OAuth grant, token validation, proof validationは省略しません. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: supported scopeはclientへのautomatic grantではありません. - B: scope metadataはrequest constructionを導きますが, grantとacceptanceはpolicyに依存します. - C: sender constrainingにはactual proof validationが必要です. metadataだけでbearer tokenは安全になりません. - D: DPoPやmTLS supportは対応するproofとbinding checkにつなげる必要があります.

**Judgment point:** signatureはmetadata integrityを守れます. ただし誰のmetadataか, どのpolicyでacceptするかをverifierが知る必要があります. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: resource identity validationがないとwrong resourceへmetadataを適用してしまいます. - B: signatureはaccess-control grantではありません. - C: metadataに依存する前にsignature trust, resource identity, profile ruleが必要です.

**Judgment point:** metadataはtoken request先やresource addressingに影響するため, retrievalを保護する必要があります. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: HTTPS validationはmetadata retrieval boundaryとresource identityを守ります. - B: plain HTTPではattackerがpolicy-relevant discovery dataを書き換えられます. - C: signed tokenはtoken/resource decisionを導くmetadata documentを保護しません.

**Judgment point:** resource metadataはresource policy, authorization server, supported proof methodが変わると変わり得ます. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: validationを保つなら, advertised locationとrefresh behaviorは有用です. - B: resource policyやauthorization server relationshipは変わり得るため, forever cacheは危険です. - C: unrelated identifierへ同じdocumentを使うとresource bindingを壊します. - D: staleまたはinconsistent metadataでsecurity-sensitive choiceを進めるべきではありません.

**Judgment point:** missing metadataによってresourceがsupportすると仮定する範囲を黙って広げてはいけません. **Related keywords:** - **protected resource** : OAuth tokenでアクセスされるresource server - **resource metadata** : resource identityやpolicy signalを示すJSON document - **authorization_servers** : そのresourceで使うauthorization serverのissuer identifier **Options:** - A: resource existenceは全OAuth featureのsupportを意味しません. - B: guessを避け, profile behaviorをdeterministicに保てます. - C: automatic downgradeはintended resourceやproof requirementをbypassする可能性があります.