These questions distinguish exchange syntax from authorization policy, actor history from access-control inputs, and delegated authority from token or channel binding. Section numbers refer to RFC 8693.
Q1: Which request input represents the party on whose behalf the new token is requested?
Multiple Choice
RFC 8693 Sections 1.1 and 2.1 define subject_token as the token representing the party on whose behalf the request is made, so B is correct. actor_token represents an optional acting party, while requested_token_type describes the desired output representation rather than a principal.
Q2: How must the authorization server handle this request?
Multiple Choice
A gateway authenticates to the token endpoint with mTLS. Its form body contains a valid subject_token and type plus an actor_token, but omits actor_token_type.
RFC 8693 Section 2.1 makes actor_token_type REQUIRED when actor_token is present and forbids it otherwise. Section 2.2.2 requires invalid_request for an invalid request, so C is correct. Client authentication does not supply the token's type, silently dropping the actor changes the request semantics, and invalid_target concerns resource or audience targets.
Q3: Which request design expresses the intended least privilege?
Multiple Choice
A gateway needs read at resource A and write at resource B, but must not have write at A. It proposes one exchange request with both resource values and scope=read write.
RFC 8693 Section 2.1.1 defines the requested rights as the Cartesian product of all scopes at all requested targets; there is no positional pairing. B avoids requesting write at A. A invents ordering semantics, C expands rather than partitions the target set, and D leaves the result to service policy without expressing the stated rights.
Q4: Which error is required for this failed exchange?
Multiple Choice
The requested backend audience is allowed, but signature validation of the supplied subject_token fails.
RFC 8693 Section 2.2.2 says an invalid or policy-unacceptable subject_token or actor_token MUST produce the OAuth invalid_request error, making A correct. invalid_target is for an unacceptable resource or audience. A validation failure is neither temporary nor a successful empty-token response.
Q5: Is this successful response structurally valid?
Multiple Choice
The response carries a SAML 2.0 assertion in access_token, sets issued_token_type to the SAML 2.0 token-type URI, and sets token_type to N_A because the assertion is not usable as an OAuth access token.
RFC 8693 Section 2.2.1 uses access_token as the historical response field for any issued security token. issued_token_type identifies its representation, while token_type describes how to use it as an OAuth access token; N_A is required when that notion does not apply. Thus C is correct. A and B conflate the two type concepts, and D discards the representation identifier the client needs.
Q6: Which response review is correct?
Multiple Choice
A client requests scope=read write. Policy issues a JWT limited to read, but the JSON token response omits the top-level scope member because the client could decode the JWT.
RFC 8693 Section 2.2.1 makes the response scope member optional only when the issued scope is identical to the requested scope; otherwise it is REQUIRED. B applies that condition. Token inspectability does not remove the response requirement, scope reduction is exactly the case that must be reported, and refresh-token issuance is unrelated.
Q7: Which lifecycle assumption must the design reject?
Multiple Choice
A gateway exchanges an input token for a backend token. It assumes the exchange consumes the input token, that later renewal of the input extends the backend token, and that revoking the input automatically revokes the backend token. No profile or deployment mechanism defines those effects.
RFC 8693 Section 2.1 says an exchange normally has no impact on input-token validity and creates no tight linkage between input and output. Input renewal is not expected to change the output; revocation propagation can be desirable but is implementation-, token-, or deployment-specific. D therefore identifies all three unsupported assumptions. A, B, and C each promote a non-guaranteed behavior into a protocol property.
Q8: Which authorization review is accurate?
Multiple Choice
A stolen subject JWT contains may_act.sub=gateway-7. An unauthenticated caller also presents an actor token naming gateway-7. The authorization server allows unidentified clients and plans to approve solely because the two names match.
RFC 8693 Sections 2.1 and 4.4 let may_act inform whether a party may become the actor, but the authorization server must still validate supplied tokens and apply authorization policy. Allowing unidentified clients is a deployment choice, not a requirement; Section 2.1 warns that it can let anyone leverage a compromised token through the STS. B states the missing controls. A confuses a claim with caller proof, C reverses the RFC, and D does not authenticate or authorize the exchange.
Q9: Which authorization and audit interpretation matches the issued token?
Multiple Choice
A gateway exchanges Alice's subject token together with its own actor token. The issued token has sub=alice, act.sub=gateway-7, a backend audience, and a reduced scope. The backend policy must preserve who performed the call on whose behalf.
RFC 8693 Section 1.1 distinguishes delegation, where the actor keeps its identity while acting for the subject, from impersonation. Section 4.1 defines the top-level act claim as the current actor and permits nested prior actors. C preserves that distinction and the token's target restrictions. A and D discard current-actor context; B converts a constrained delegation into broader impersonation.
Q10: May the backend treat the exchanged token as proof of the original client session?
Multiple Choice
A client sends a grant and a session-bound proof to a gateway. The gateway validates both, exchanges the grant for an audience-restricted bearer access token containing its act claim, and calls the backend over a different TLS connection. The backend receives no original proof, exporter value, or other binding to the client session.
RFC 8693 Section 1 limits the specification to a basic token-exchange protocol and leaves token security characteristics, proof of possession, and the deployment trust model to profiles or policy. A valid exchange can authorize the backend call under the issued token's audience, scope, subject, and actor semantics; it does not manufacture evidence of a different TLS session. C separates those guarantees. D is false: a resource server exchanging a received token for a backend token is an explicit use case.
Q11: Which access-control and audit treatment conforms to the act claim rules?
Multiple Choice
A token has top-level sub=alice, current actor act.sub=service-16, and nested prior actor act.act.sub=service-77. The resource server validates the token and wants to use all three identities.
RFC 8693 Section 4.1 requires access-control policy to consider only the token's top-level claims and the current actor in the outermost act. Nested prior actors are informational history and MUST NOT be used for access control, so B is correct. A and C use prior history normatively, while D also discards the current actor that the rule explicitly includes.
Q12: Which issuance policy meets the stated privacy requirement?
Multiple Choice
An authorization server issues tokens through TLS to a gateway client. Each token contains Alice's email, employee number, and full actor history. The backend needs only a pseudonymous subject and current actor, and policy says the gateway must not learn the direct identifiers.
RFC 8693 Section 6 requires encrypted channels, requires recipient encryption when information must be hidden from the client, and recommends including only the minimally necessary data. C meets all stated conditions. TLS still terminates at the gateway, Base64url is not encryption, and nesting changes claim structure rather than confidentiality; therefore A, B, and D fail.
