RFC 8705 Quiz (EN)

Q1: Is this access token certificate-bound?

Multiple Choice

A confidential A2A client authenticates to the authorization server with the PKI mutual-TLS method. The issued access token contains no certificate association, and introspection returns no certificate thumbprint.

A. Yes; mutual-TLS client authentication at the token endpoint implicitly sender-constrains every token issued on that connection B. Yes; a PKI-validated client certificate lets the resource server reconstruct the missing token association from the client_id C. No binding is shown; Section 2 client authentication and Section 3 certificate-bound access tokens are complementary but distinct D. No OAuth client may use this token because RFC 8705 requires certificate-bound access tokens whenever mutual TLS is available

**Explanation:** A: Section 1 states that mutual-TLS client authentication and certificate-bound access tokens are distinct mechanisms and need not be used together. B: Section 3 requires an association accessible to the protected resource, such as x5t#S256 in the token or introspection metadata. C: Correct. Section 2 authenticates the client to authorization-server endpoints; Section 3 constrains token use at the protected resource. D: RFC 8705 defines both mechanisms but does not make certificate binding mandatory for every OAuth token.

Q2: Should the resource server reject this public client solely because its certificate is self-signed?

Multiple Choice

A public A2A client has a certificate-bound access token. It presents the same self-signed certificate on the mutual-TLS connection to the resource server, and the certificate thumbprint matches the token.

A. Not for that reason alone; in this use the resource server verifies possession and the token binding, not a PKI trust chain for the client certificate B. Reject it because certificate-bound tokens are available only to confidential clients authenticated with a CA-issued certificate C. Accept it without token validation because matching a self-signed certificate already proves the access token is active and authorized D. Require the authorization server to use the same certificate as its server certificate before comparing the token thumbprint

**Explanation:** A: Sections 4 and 6.2 describe certificate-bound tokens for public clients and explain that the resource server need not validate the client-certificate trust chain for this proof-of-possession use. B: Section 4 explicitly permits public clients to use certificate-bound tokens with self-signed certificates. C: Certificate possession is one input; the resource server still validates the access token and applies authorization policy. D: The authorization server's TLS server certificate is unrelated to the client's proof-of-possession certificate.

Q3: May the backend use the forwarded certificate header for RFC 8705 binding?

Multiple Choice

A reverse proxy terminates mutual TLS and appends X-Client-Cert before forwarding to the resource server. External clients can also send X-Client-Cert, and the proxy does not remove an existing value. The resource server must bind the token to the certificate authenticated on this connection.

A. Use the first header value because the proxy appends the certificate it observed after any client-supplied value B. Use either value whose thumbprint matches the token because a match proves which hop authenticated the certificate C. Treat the header as advisory and authorize when either the token or the forwarded certificate passes its separate validation D. Reject this channel; strip client values, authenticate proxy-to-backend certificate metadata, then compare that certificate to the token

**Explanation:** A: A client-controlled value can be selected as the supposed TLS certificate, defeating the binding to the proxy-authenticated connection. B: An attacker with a stolen bound token can inject its expected thumbprint without proving possession of the corresponding private key. C: Section 3 requires both token validation and a match with the certificate obtained from the TLS layer; the checks are not alternatives. D: Section 6.5 permits TLS termination but leaves secure certificate-metadata conveyance out of scope. The profile must secure that hop before Section 3's comparison is meaningful.

Q4: Can the client reuse the old access token after certificate rotation?

Multiple Choice

An A2A client rotates from certificate C1 to C2. C2 has the same subject name and public-key algorithm, but different DER bytes. Its access token contains x5t#S256 for C1. The resource server requires an RFC 8705 certificate match.

A. Reuse the token because the subject name represents the same OAuth client and is more stable than a certificate thumbprint B. Obtain a token bound to C2; the protected resource compares the presented certificate with the certificate associated with the token C. Reuse the token if C1 and C2 use the same signature algorithm, since x5t#S256 identifies an algorithm family D. Rewrite the token's x5t#S256 value at the resource server after validating that both certificates have the same subject

**Explanation:** A: Section 3.1 defines x5t#S256 as the SHA-256 hash of the certificate's DER encoding, not of its subject name. B: Section 6.3 notes that certificate updates invalidate access tokens bound to the previous certificate and can be handled by obtaining a new token. C: The confirmation value identifies a certificate thumbprint, not an algorithm family. D: Altering a protected token claim would invalidate its protection and replace the authorization server's binding decision.

Q5: Does the registration flag establish that this token is sender-constrained?

Multiple Choice

Client metadata sets tls_client_certificate_bound_access_tokens=true. The client then calls the token endpoint without mutual TLS, and the authorization server returns an access token with no x5t#S256 or equivalent introspection metadata. Resource policy accepts only certificate-bound tokens.

A. No; inspect the issued token's binding evidence and reject it under the stated resource policy if no certificate association exists B. Yes; the client metadata value converts every later token into a certificate-bound token even on a non-mutual-TLS request C. Yes; authorization-server capability metadata and client-intent metadata together replace the Section 3 certificate comparison D. No; RFC 8705 requires the authorization server to return an error for every non-mutual-TLS request from such a client

**Explanation:** A: Sections 3.3 and 3.4 define capability and intent metadata. The binding of a particular token still comes from the association described in Section 3. B: Section 3.4 says that, after a non-mutual-TLS request, issuing an error or an unbound token is at the authorization server's discretion. C: Metadata negotiation does not replace the protected resource's certificate-to-token comparison in Section 3. D: Section 3.4 deliberately leaves this authorization-server choice open; the resource server can still enforce its own bound-token policy.

Q6: How can the backend preserve the intended sender constraint?

Multiple Choice

An A2A agent presents a token bound to certificate C_agent on mutual TLS to a gateway. The gateway opens a separate mutual-TLS connection to the backend using C_gateway and forwards the original token. Backend policy requires proof that the caller of this backend operation possesses C_agent's private key.

A. Compare the token thumbprint with C_gateway because the gateway is the immediate TLS client and any valid upstream certificate binding transfers to that hop B. Skip the certificate comparison after the gateway reports success, while continuing to describe the backend check as direct RFC 8705 proof of C_agent possession C. Either terminate the RFC 8705 resource role at the trusted gateway and issue a protected downstream assertion, or securely convey C_agent evidence under an explicitly defined proxy profile D. Forward C_agent in an unprotected header and compare its thumbprint, since the token's signed x5t#S256 value authenticates the header source

**Explanation:** A: Section 3 binds the token to C_agent. C_gateway is a different certificate on a different TLS connection. B: Gateway trust can support a new architecture, but the backend must not mislabel a gateway assertion as direct proof from its own TLS layer. C: Sections 3 and 6.5 delimit the RFC mechanism and the unspecified proxy hop. Either design can be profiled, but the trust boundary and protected metadata must be explicit. D: A signed thumbprint in the token does not prove that an unprotected forwarded certificate value came from the TLS terminator.

OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

References (URLs)

Q1: Is this access token certificate-bound?

Q2: Should the resource server reject this public client solely because its certificate is self-signed?

Q3: May the backend use the forwarded certificate header for RFC 8705 binding?

Q4: Can the client reuse the old access token after certificate rotation?

Q5: Does the registration flag establish that this token is sender-constrained?

Q6: How can the backend preserve the intended sender constraint?