RFC 9728 Quiz (EN)

**Judgment point:** Protected resource metadata describes the resource server side of an OAuth deployment. It complements authorization server metadata. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Authorization server metadata remains a separate discovery document with a different subject. - B: The protected resource and its OAuth-related signals are the center of this RFC. - C: The RFC does not issue tokens and does not remove the need for an authorization server.

**Judgment point:** The client or authorization server must not let an attacker-selected metadata document redefine the resource being accessed. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Resource identity validation prevents metadata for one resource from being used with another. - B: An error response can point to metadata, but the document still needs validation. - C: HTTPS retrieval protects the metadata path before policy checks are applied. - D: Listed authorization servers are inputs for policy, not universal approval for all clients.

**Judgment point:** The resource identifier prevents clients and authorization servers from applying metadata to the wrong resource. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Human account identity is outside the protected resource metadata identifier. - B: Consent screen design is not the security role of the resource identifier. - C: Binding metadata to the intended resource is the key validation purpose of the identifier.

**Judgment point:** The field can connect a resource to authorization server issuers. The relying party still checks trust and policy. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: This treats the list as scoped discovery information rather than unconditional approval. - B: Every client and deployment still has its own trust and policy requirements. - C: Issuer identifiers are not access tokens and cannot authorize a request by themselves.

**Judgment point:** Protected resource metadata helps align the client, resource server, and authorization server relationship. Reachability is not acceptance. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Starting from any authorization server can select a server the resource does not use. - B: This sequence keeps resource identity, metadata validation, and authorization server compatibility distinct. - C: A reachable metadata endpoint does not validate an access token or authorize a request.

**Judgment point:** The metadata can advertise support or expectations. It does not skip OAuth grants, token validation, or proof validation. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Supported scopes are not automatic grants to a client. - B: Scope metadata can guide request construction, but grant and acceptance depend on policy. - C: Sender constraining requires actual proof validation; metadata alone cannot make a bearer token safe. - D: DPoP or mTLS support must be followed by the corresponding proof and binding checks.

**Judgment point:** A signature can protect metadata integrity, but the verifier still has to know whose metadata it is and what policy accepts. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Without resource identity validation, metadata can be applied to the wrong resource. - B: A signature is not an access-control grant. - C: Signature trust, resource identity, and profile rules are all needed before relying on the metadata.

**Judgment point:** Metadata can influence where tokens are requested and how resources are addressed, so retrieval must be protected. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: HTTPS validation protects the metadata retrieval boundary and resource identity. - B: Plain HTTP lets attackers rewrite policy-relevant discovery data. - C: Signed tokens do not protect the metadata document that guides token and resource decisions.

**Judgment point:** Resource metadata can change when resource policy, authorization servers, or supported proof methods change. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Advertised locations and refresh behavior can be useful when validation remains in place. - B: Resource policy and authorization server relationships can change, so forever caching is unsafe. - C: Reusing one document across unrelated identifiers breaks the resource binding. - D: Stale or inconsistent metadata should not drive security-sensitive choices.

**Judgment point:** Missing metadata should not silently expand what the resource is assumed to support. **Related keywords:** - **protected resource** : Resource server being accessed with OAuth tokens - **resource metadata** : JSON document describing resource identity and policy signals - **authorization_servers** : Issuer identifiers for authorization servers used with the resource **Options:** - A: Resource existence does not imply support for every OAuth feature. - B: This prevents guessing and keeps profile behavior deterministic. - C: Automatic downgrades can bypass the intended resource or proof requirements.