RFC 8414 Quiz (JA)

**Judgment point:** authorization server metadataはclientにendpointとcapabilityの場所を伝えます. requestを許可するかは決めません. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: access decisionはauthorization flow, token, resource server, policyで決まります. - B: endpointとcapabilityの公開がmetadata documentの中心的機能です. - C: discoveryはclientを助けますが, registrationとlocal policyは別controlとして残ります.

**Judgment point:** metadata discoveryは, clientがintended issuerとtransport trustに結び付けたときだけ有効です. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: issuer valueにより, あるauthorization serverのmetadataを別contextに混ぜる事故を防げます. - B: reachable documentはattacker-controlledかもしれず, 単に別issuer用かもしれません. - C: HTTPSとintended issuer pathが, 後続のendpoint利用前にmetadata retrievalを守ります. - D: jwks_uriはdocument内の1 fieldであり, endpointやissuer relationship全体を検証しません.

**Judgment point:** issuer valueはclientがwrong authorization serverのendpoint, key, capabilityを使うことを防ぎます. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: display nameはUI concernであり, ここでの主要なsecurity roleではありません. - B: resource-server acceptanceはaudience, token, policyに基づく別decisionです. - C: issuer bindingはcross-issuer metadata confusionを防ぐkey checkです.

**Judgment point:** signed metadataはcontent integrityを守れますが, expected issuerとtrusted signing keyに結び付ける必要があります. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: signatureをvalidation inputとして使いながら, issuerとtrust checkを省略していません. - B: signatureはtrusted keyがsignした内容を示すだけで, 全endpointのpolicy approvalではありません. - C: TLSとissuer comparisonはretrievalとbindingの境界を守ります. signatureだけでは消えません.

**Judgment point:** clientはkeyやendpointにauthorization serverを選ばせるべきではありません. expected issuer identityが先です. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: search resultはtrusted issuer anchorではなく, mix-upにつながります. - B: issuer identity, metadata retrieval, endpoint useを意図した順序で保っています. - C: keyはverifier inputであり, clientがどのserverを使うつもりだったかを選ぶauthorityではありません.

**Judgment point:** metadata formatはserverを説明します. 何をtrustし, 何をpolicy上必須にするかはdeploymentが選びます. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: field nameはmetadata formatの一部であり, RFCの範囲内です. - B: resource accessはdiscovery document外のauthorization decisionです. - C: endpoint locationはmetadataが公開する代表的な情報です. - D: deployment profileはfieldを必須にし, threat modelに不足するmetadataをrejectできます.

**Judgment point:** OAuth deploymentではauthorization serverの混同を避ける必要があります. metadata validationはその境界を強制する場所です. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: expected issuer向けの正しいcacheは安定運用を助けます. - B: mismatched issuer valueのrejectは意図されたprotectionです. - C: 異なるissuerのfieldを混ぜることが, issuer checkで防ぐべきconfusionです.

**Judgment point:** key set locationはauthorization server objectのvalidationを助けます. verifierはissuerとalgorithm policyを引き続き適用します. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: jwks_uriをexpected authorization serverにscopedなkey sourceとして扱っています. - B: trustはscopedです. URLに到達できるだけで全issuerへ拡張できません. - C: issuer, audience, algorithm validationはkey retrievalを超える境界を守ります.

**Judgment point:** metadataはautomationを支えます. ただしautomationでstaleまたはinconsistentなsecurity stateをacceptしてはいけません. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: 定義済みrefresh behaviorにより, clientはendpointやkey更新にad hocで対応しなくて済みます. - B: authorization serverはkeyやendpointをrotateし得るため, forever cacheは危険です. - C: outage中にissuer mismatchを無視するのはfail-open behaviorです. - D: fail closedにするとdeployment profileを満たさないmetadataを使わずに済みます.

**Judgment point:** metadataによりclientはcapabilityについてguessせずに済みます. strict profileではmissing dataをsupport扱いにしません. **Related keywords:** - **issuer** : authorization serverを識別する値 - **metadata** : endpointやcapabilityを示すJSON document - **jwks_uri** : authorization serverのkeyを取得する場所 **Options:** - A: endpoint existenceは全capabilityのsupportを意味しません. - B: deterministic client behaviorを保ち, unsupportedまたはunsafeなflowを避けられます. - C: unsupported behaviorを試すとdata leakや分かりにくいfailure pathを作ります.