RFC 8414 Quiz (EN)

**Judgment point:** Authorization server metadata tells clients where to find endpoints and capabilities. It does not decide whether a request is allowed. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Access decisions are made by authorization flows, tokens, resource servers, and policy. - B: Publishing endpoints and capabilities is the core function of the metadata document. - C: Discovery can support clients, but registration and local policy remain separate controls.

**Judgment point:** Metadata discovery is useful only when the client binds it to the intended issuer and transport trust. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: The issuer value prevents mixing metadata from one authorization server into another context. - B: A reachable document can be attacker-controlled or simply for another issuer. - C: HTTPS and the intended issuer path protect metadata retrieval before later endpoint use. - D: jwks_uri is one field in the document and does not validate every endpoint or issuer relationship.

**Judgment point:** The issuer value stops a client from using endpoints, keys, or capabilities from the wrong authorization server. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Display names are user interface concerns and are not the main security role. - B: Resource-server acceptance is a separate decision based on audience, token, and policy. - C: Issuer binding is the key check that prevents cross-issuer metadata confusion.

**Judgment point:** Signed metadata can protect content integrity, but it must be tied to the expected issuer and trusted signing key. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: This keeps the signature as validation input without skipping issuer and trust checks. - B: A signature proves only what the trusted key signed, not that every endpoint is policy-approved. - C: TLS and issuer comparison protect retrieval and binding boundaries that a signature alone does not erase.

**Judgment point:** The client should not let keys or endpoints choose the authorization server. Expected issuer identity comes first. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: A search result is not a trusted issuer anchor and can lead to mix-up. - B: This flow keeps issuer identity, metadata retrieval, and endpoint use in the intended order. - C: Keys are verifier inputs, not the authority for selecting which server the client intended.

**Judgment point:** The metadata format describes a server. The deployment still chooses what it trusts and what policy requires. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Field names are part of the metadata format and are within the RFC area. - B: Resource access is an authorization decision outside the discovery document. - C: Endpoint locations are exactly the kind of information metadata publishes. - D: A deployment profile can require fields and reject metadata that is insufficient for its threat model.

**Judgment point:** OAuth deployments must avoid confusing one authorization server with another. Metadata validation is one place to enforce that boundary. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Correct caching for the expected issuer supports stable operation. - B: Rejecting mismatched issuer values is the intended protection. - C: Combining fields from different issuers is exactly the confusion the issuer check is meant to prevent.

**Judgment point:** The key set location supports validation of authorization server objects. The verifier still applies issuer and algorithm policy. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: This treats jwks_uri as a scoped key source for the expected authorization server. - B: Trust is scoped and cannot be extended to all issuers just because a URL is reachable. - C: Issuer, audience, and algorithm validation protect boundaries beyond key retrieval.

**Judgment point:** Metadata supports automation, but automation should not make clients accept stale or inconsistent security state. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Defined refresh behavior lets clients update endpoints and keys without ad hoc behavior. - B: Authorization servers can rotate keys and endpoints, so forever caching is unsafe. - C: Ignoring issuer mismatch during outages is a fail-open behavior. - D: Failing closed avoids using metadata that no longer satisfies the deployment profile.

**Judgment point:** Metadata lets a client avoid guessing about capabilities. A strict profile should not turn missing data into support. **Related keywords:** - **issuer** : Authorization server identifier - **metadata** : JSON document describing endpoints and capabilities - **jwks_uri** : Location for keys used by the authorization server **Options:** - A: Endpoint existence does not imply support for every capability. - B: This preserves deterministic client behavior and avoids unsupported or unsafe flows. - C: Trying unsupported behavior can leak data and create confusing failure paths.