Q1: What does OAuth protected resource metadata describe?
Multiple Choice
RFC 9728 Sections 1 and 2 define configuration information that clients and authorization servers can use when interacting with a protected resource. The document can advertise relationships and capabilities, but it neither issues a grant or token nor performs the resource's credential validation and policy decision. Its contents are configuration claims that feed discovery and application trust decisions, not an authorization result.
Q2: Which statements about resource and authorization_servers are correct? Select all that apply.
Multi-Select
RFC 9728 Sections 1.2 and 2 require an HTTPS `resource` identifier and make `authorization_servers` optional and potentially non-exhaustive. Omitting that list does not mean that no authorization server is usable, while omitting `scopes_supported` does not imply an empty scope set. Signed metadata does not change the resource syntax, so consumers must anchor the document to one resource without treating optional lists as complete.
Q3: Where is metadata fetched for resource https://api.example/a2a using the default suffix?
Multiple Choice
RFC 9728 Section 3.1 inserts `/.well-known/oauth-protected-resource` between the authority and the resource path, producing `https://api.example/.well-known/oauth-protected-resource/a2a`. Appending the suffix after `/a2a` or absorbing the path into the suffix changes the registered construction. Preserving the exact path after the well-known component keeps distinct resources on one host separate.
Q4: A metadata document's resource value does not match the resource used for discovery. What should the client do?
Multiple Choice
RFC 9728 Section 3.3 requires exact equality between the returned `resource` and the identifier used for discovery, and prohibits using a mismatching response. Accepting a replacement value from inside the document would let the response redirect its own trust target; deleting only the bad member would still retain claims from that unbound response. A shared certificate authenticates the host connection but does not collapse distinct resource identifiers.
Q5: What does the resource_metadata parameter in WWW-Authenticate provide?
Multiple Choice
RFC 9728 Sections 5 and 5.1 define the `resource_metadata` authentication parameter as a URL pointing to the protected resource metadata document and allow it with schemes such as Bearer or DPoP. The parameter does not embed the document, carry an access token, or perform client registration. A client must retrieve the referenced document and then apply the normal metadata validation and trust checks.
Q6: Which interpretations of capability metadata are correct? Select all that apply.
Multi-Select
RFC 9728 Section 2 gives no default or negative implication to omitted `scopes_supported`, but defines omission of `dpop_bound_access_tokens_required` as false. It defines no default signing algorithm and excludes `none` from that algorithm list. Section 7.2 still directs clients to request only the minimum scope needed, so advertised capabilities and omission defaults do not replace least-privilege or algorithm policy.
Q7: Which client behavior is appropriate for this discovered authorization server?
Multiple Choice
A user-selected A2A endpoint returns protected resource metadata whose resource value exactly matches that endpoint. Its authorization_servers list contains https://169.254.169.254/internal-issuer, an issuer the client has never configured or trusted.
RFC 9728 Section 7.7 identifies fetching authorization-server metadata from an issuer named by resource metadata as an SSRF risk and recommends controls such as blocking internal IP ranges. Exact resource binding under Section 3.3 validates the document's resource identity, not the safety or authority of every embedded network destination. The client must apply outbound-request controls before any RFC 8414 fetch, withhold credentials, validate the issuer metadata, and separately establish the issuer-to-resource trust relationship described in Section 7.6.
Q8: May the client automatically trust this listed authorization server?
Multiple Choice
A valid protected resource document lists https://as.partner.example in authorization_servers. The client has no out-of-band trust rule, federation policy, or cross-check linking that issuer to the resource.
RFC 9728 Section 7.6 explicitly leaves secure determination of an appropriate authorization server out of scope and application dependent. The advertised list can support dynamic discovery, but it is not a universal trust-anchor set; HTTPS and RFC 8414 validation establish configuration for an issuer, not that issuer's authority over this resource. The client must validate both metadata documents and then apply a defined issuer-to-resource trust policy before authorization begins.
Q9: Which two actions are required when processing this signed metadata? Select all that apply.
Multi-Select
A client supports signed_metadata. Plain JSON lists AS1; the signed JWT lists AS2. The JWT signature is valid, but the client has not determined whether its iss is trusted for this resource.
RFC 9728 Section 3.3 requires validation of the signature, the issuer's key, and trust in that issuer; mathematical signature validity alone is insufficient. Once supported signed metadata is valid, Section 2.2 gives its corresponding claims precedence rather than permitting an unvalidated union with conflicting plain values. Section 7.9 explains that signed and unsigned metadata can have different trust bases, so signer authorization must be established before applying precedence.
Q10: Which end-to-end design correctly composes resource discovery with OAuth and A2A proof?
Multiple Choice
An A2A client follows resource_metadata, validates the resource value, selects a trusted listed issuer, validates RFC 8414 metadata, and obtains an audience-restricted DPoP-bound token. A gateway verifies the token and DPoP proof, then forwards an unsigned identity header to the policy-owning backend.
RFC 9728 Sections 3.3 and 5 bind discovery to the intended resource, Section 7.4 recommends audience-restricted tokens, and Section 7.6 preserves the separate issuer-trust decision. Metadata only configures the flow; it neither issues nor accepts access, and a newly created unsigned header is not bound to the DPoP key or request. Each association and credential must be verified at its intended endpoint, and any derived assertion must remain protected until the backend applies its own authorization policy.
