RFC 8725 Quiz (EN)

Q1: Which algorithm-selection behavior follows RFC 8725?

Multiple Choice

An A2A verifier supports RS256 and ES256 in its library. This token profile permits only ES256, but an incoming token declares alg=RS256 and has a valid RS256 signature.

A. Accept because a valid signature with any algorithm implemented by the library satisfies algorithm verification B. Reject because the caller selects an allowed set and the cryptographic operation must use the algorithm allowed for this profile and key C. Accept after recording the algorithm difference, since signature validity takes precedence over a profile allowlist D. Retry verification with ES256 while retaining the RS256 signature bytes, so the local profile controls the algorithm name

**Explanation:** A: Section 3.1 requires libraries to let callers specify the supported set and forbids using other algorithms for the operation. B: Correct. Section 3.1 also requires the header algorithm, the operation performed, and the algorithm associated with the key to agree. C: A successful operation outside the selected profile is not a successful validation for that profile. D: Verification must use the algorithm that actually produced the signature; relabeling inputs cannot repair a profile mismatch.

Q2: Which profile change addresses cross-JWT confusion?

Multiple Choice

One issuer signs both A2A access tokens and Agent Card attestations with the same key. Both currently use the same audience and optional claims, so either token passes the other's validator.

A. Keep one validation rule and ask callers to remember whether they fetched the JWT from the token or Agent Card endpoint B. Add a human-readable purpose claim but leave it optional and continue accepting a token when that claim is absent C. Use the same typ value for both classes and rely on different documentation to distinguish their authorization effects D. Define mutually exclusive validation rules, using distinct typing, claims, audiences, keys, or issuers so a token of the other class is rejected

**Explanation:** A: Endpoint provenance can be lost or confused and does not make the token classes cryptographically or semantically exclusive. B: An optional discriminator does not force the wrong validator to reject the token. C: Section 3.11 recommends explicit typing for new JWT uses, and reusing a type defeats that discriminator. D: Section 3.12 requires mutually exclusive validation rules when different JWT kinds could be confused; it lists these separation strategies.

Q3: Should the gateway accept the Agent Card attestation as an access token?

Multiple Choice

The attestation is correctly signed by trusted issuer I, has aud=gateway, and is unexpired. The access-token endpoint also trusts I. The access-token profile requires typ=a2a-access+jwt and scope=task.write; the attestation has typ=a2a-card+jwt and no scope. Authorization requires the access-token profile.

A. Accept because issuer, audience, lifetime, and signature are valid, which are sufficient shared properties for both token classes B. Accept after adding scope=task.write to the decoded claims because the trusted issuer could have issued that value C. Reject under the access-token rules; valid protection for one JWT kind does not satisfy the mutually exclusive type and claim rules of another D. Reject all JWTs from issuer I because one issuer cannot safely issue more than one kind of JWT under RFC 8725

**Explanation:** A: Sections 2.8 and 3.12 address exactly this substitution risk; shared valid properties do not erase class-specific rules. B: A verifier cannot invent an authorization claim after signature verification and attribute it to the issuer. C: Correct. Sections 3.11 and 3.12 support explicit typing and mutually exclusive rules; the stated access-token profile supplies the decision criterion. D: Section 3.12 permits one issuer to issue different kinds when validation rules reliably segregate them.

Q4: Is signature verification enough before dereferencing the jku URL?

Multiple Choice

A multi-issuer A2A gateway reads jku from a signed JWT and fetches that URL to obtain verification keys. Trusted issuers are configured, but the gateway permits any HTTPS host in jku. The security requirement forbids attacker-directed requests to internal services.

A. No; bind acceptable key locations to the validated issuer or an allowlist and validate lookup inputs before any network access B. Yes; once a JWT carries a signature value, every Header Parameter used to find its verification key is already trustworthy C. Yes if the URL uses HTTPS, because WebPKI prevents a JWT author from choosing an internal or unintended destination D. Fetch the URL first and validate issuer after key retrieval, because issuer-key binding can only be evaluated after the request

**Explanation:** A: Section 3.10 requires validation or sanitization of claims and headers used for lookups and gives allowlisting as a mitigation for injection and SSRF. B: The key lookup occurs before signature authenticity has been established; attacker-controlled lookup inputs cannot inherit trust from an unverified signature. C: HTTPS authenticates the selected server but does not establish that the selected destination is allowed by this application. D: A configured issuer-to-key-location binding can be checked before an attacker-controlled network request.

Q5: How should the verifier handle this HS256 token?

Multiple Choice

An A2A profile accepts only RS256 with issuer I's RSA public key. A library also implements HS256. An attacker submits alg=HS256 and computes an HMAC using the published RSA public-key bytes as the HMAC secret. The verifier's criterion is the profile's RS256 issuer authentication.

A. Verify HS256 with the supplied RSA bytes because the same key material is already trusted for issuer I B. Reject before that reinterpretation; restrict algorithms to RS256 and ensure the configured RSA key is used only with its assigned algorithm C. Verify both HS256 and RS256 and accept whichever operation succeeds, preserving compatibility with library capabilities D. Accept if iss=I and aud matches, since claim validation can compensate for a different signature algorithm

**Explanation:** A: Section 2.1 describes this algorithm confusion class; a public key must not be reinterpreted as an attacker-usable symmetric secret. B: Section 3.1 requires a caller-selected algorithm set and exactly one algorithm per key, checked during the cryptographic operation. C: Trying every library algorithm lets the token choose a validation mode outside the profile. D: Claim validation is necessary but cannot replace successful issuer authentication under the selected algorithm and key.

Q6: Which gateway-to-backend design meets the stated authorization criterion?

Multiple Choice

A gateway accepts access JWTs and session-binding JWTs from the same issuer. It verifies signatures with one generic rule and forwards only sub in X-Agent. The backend authorizes task.write from that header. Backend policy requires an access token for itself and an independently valid session-binding proof for this request.

A. Keep X-Agent because a shared issuer and valid signature allow the backend to infer both token kinds from one subject value B. Add both original typ strings to X-Agent without protecting the header, since explicit typing alone transfers the gateway result C. Validate either JWT kind and let the backend choose which guarantee it represents, because local authorization can repair generic validation D. Use mutually exclusive validators, enforce issuer and audience per kind, and convey both results in a protected assertion or let the backend validate the original proofs

**Explanation:** A: A subject value does not carry token class, audience, scope, or session-binding evidence. B: Section 3.11 typing helps prevent confusion at validation; an unprotected downstream header does not preserve the validated result. C: Section 3.12 requires wrong-kind JWTs to be rejected by mutually exclusive rules before authorization policy consumes them. D: Sections 3.8, 3.9, 3.11, and 3.12 supply the JWT checks. The protected downstream assertion and final authorization rule are A2A trust-boundary choices, not guarantees created by RFC 8725.

JSON Web Token Best Current Practices

References (URLs)

Q1: Which algorithm-selection behavior follows RFC 8725?

Q2: Which profile change addresses cross-JWT confusion?

Q3: Should the gateway accept the Agent Card attestation as an access token?

Q4: Is signature verification enough before dereferencing the jku URL?

Q5: How should the verifier handle this HS256 token?

Q6: Which gateway-to-backend design meets the stated authorization criterion?