RFC 7519 Quiz (EN)

Q1: Which claims does RFC 7519 require in every JWT?

Multiple Choice

An A2A profile wants every task token to contain iss, sub, aud, exp, and jti. Its authors say RFC 7519 itself makes that claim set mandatory.

A. All registered claims in Section 4.1 are mandatory whenever a JWT is integrity-protected B. None universally; the A2A profile may require these claims and define validation and authorization C. Only iss and exp are universally mandatory, while the remaining claims are optional D. No claims may be required by an application profile because JWT claim use is always optional

**Explanation:** A: Registration does not make every registered claim mandatory. B: RFC 7519 Section 4 says required claims are context dependent and outside the specification's universal requirements. A profile can make selected claims mandatory and define their operational meaning. C: RFC 7519 does not define iss and exp as universally mandatory either. D: The base specification leaves requirements to applications; it does not prohibit a profile from imposing them.

Q2: How should an A2A recipient validate aud?

Multiple Choice

A JWT has aud equal to ["task-gateway", "billing-agent"]. The billing-agent processes the token; an unrelated inventory-agent receives a copied request.

A. Both agents accept because any non-empty aud array proves that a recipient was named B. Both agents accept if they share the same issuer and verification key C. billing-agent may pass; inventory-agent must reject because it is absent from aud D. Only task-gateway may accept because an aud array is interpreted using its first element

**Explanation:** A: A recipient must identify itself in the audience value; a non-empty array is not enough. B: Issuer and key validation do not substitute for recipient restriction. C: RFC 7519 Section 4.1.3 permits a string or array and requires a processor to reject when it does not identify itself in aud. Passing aud is necessary but not sufficient for overall acceptance. D: Array order does not limit acceptance to the first audience.

Q3: May an unverified iss claim select its own verification key?

Multiple Choice

Before verifying a JWT, an A2A service reads iss, fetches a key from a URL constructed solely from that value, and accepts any token whose signature verifies with the fetched key. It has no configured issuer-to-key trust relationship.

A. Yes, because successful signature verification makes the unverified issuer value trustworthy retroactively B. Yes, if the URL uses HTTPS, regardless of who controls the issuer namespace and key C. No JWT may use iss during key selection, even after applying a configured issuer policy D. No. Bind trusted issuer IDs to authorized key sources and algorithms, then validate the signature and claim profile

**Explanation:** A: This creates circular trust: the attacker can name an issuer and supply the key that validates it. B: HTTPS protects transport to a selected endpoint but does not authorize that endpoint as the claimed JWT issuer. C: Issuer-aware key selection can be safe when constrained by configured trust; RFC 7519 does not prohibit it. D: RFC 7519 Sections 7.2 and 11.1 require cryptographic validation in the necessary trust context. The issuer-to-key association and acceptable algorithms are application or profile policy.

Q4: Is this token currently within its time window?

Multiple Choice

At verifier time 12:00:30Z, a token has nbf 12:01:00Z and exp 12:10:00Z. The profile permits at most 10 seconds of clock-skew leeway.

A. Yes, because exp is still in the future and nbf is only advisory B. No. It is 30 seconds before nbf, beyond the permitted 10-second leeway C. Yes, because any positive leeway makes both nbf and exp optional D. No, because a token may not contain both nbf and exp

**Explanation:** A: RFC 7519 Section 4.1.5 requires current time not to be before nbf, subject to permitted leeway. B: The token is outside the stated acceptance window. Sections 4.1.4 and 4.1.5 define exp and nbf; a small leeway may account for skew, and the profile selected its bound. C: Leeway adjusts a boundary by a limited amount; it does not remove the claim checks. D: The claims may appear together to bound a validity interval.

Q5: Does jti alone prevent token replay?

Multiple Choice

Every A2A task token has a unique jti and a valid signature. A verifier keeps no replay state and accepts the same token repeatedly until exp. The profile claims that merely including jti provides one-time use.

A. Yes; uniqueness of the string causes JWT libraries to reject its second presentation automatically B. Yes, provided exp is present, because replay before expiration is excluded by jti semantics C. No. jti only indexes a replay check; the profile defines reuse detection, scope, and lifetime D. No; RFC 7519 requires every verifier to store every jti forever

**Explanation:** A: JWT processing does not create replay state merely because the claim is present. B: exp limits the acceptance interval but does not prevent reuse inside it. C: RFC 7519 Section 4.1.7 says jti can be used to prevent replay. The actual detection protocol, storage, scope, and retention are profile or deployment choices. D: RFC 7519 does not impose universal indefinite storage.

Q6: How should a gateway handle a JWT addressed only to itself?

Multiple Choice

A signed task JWT has aud "task-gateway" only. The gateway validates it, then calls a billing backend that owns the resource. The backend either can process the original JWT or can trust a gateway assertion, depending on the chosen profile.

A. The backend either rejects the JWT on aud, or trusts a protected request-bound gateway assertion and authorizes separately B. The backend may process the original JWT because sharing a deployment automatically adds it to aud C. The gateway may copy the JWT claims into ordinary headers because a valid signature continues to protect copied values D. The gateway's successful JWT validation authorizes every operation at the billing backend

**Explanation:** A: RFC 7519 Section 4.1.3 requires a JWT recipient to identify itself in aud. A protected gateway assertion is a different trust model and must authenticate the gateway, context, and downstream request; the resource owner still decides authorization. B: Deployment topology does not rewrite a signed audience claim. C: Copying claims removes the original signature's protection unless the new carrier is independently protected and interpreted as a gateway assertion. D: Token validation and resource authorization remain distinct decisions.

Q7: May different components choose different duplicate claim values?

Multiple Choice · L3

A JWT Claims Set contains two role names: first viewer, then admin. An upstream parser keeps the first occurrence, while the resource server keeps the last and authorizes as administrator.

A. Yes. Each component may select either occurrence because private claims have application-defined meaning B. Yes. The resource server should select whichever duplicate grants the broader permission C. No. Reject duplicates or keep only the lexically last value, as Section 4 permits; do not create conflicting interpretations D. No. RFC 7519 always requires keeping the first occurrence, so both components must authorize as viewer

**Explanation:** A: Application-defined claim meaning does not override the Claims Set parsing rule. B: Choosing the more privileged value is not an RFC rule and turns ambiguity into privilege escalation. C: Section 4 requires claim names to be unique. A parser must either reject duplicates or use a parser that returns only the lexically last duplicate. A profile should ensure every security-relevant component applies a consistent permitted behavior; the upstream's first-value interpretation is not one of them. D: RFC 7519 permits rejection or the lexically last value, not a first-value rule.

Q8: Does RFC support for an Unsecured JWT make it acceptable here?

Multiple Choice · L3

An A2A profile accepts only task JWTs signed by configured issuers. An external request supplies an otherwise well-formed Unsecured JWT with alg equal to none, an empty signature value, and plausible aud and exp claims.

A. Reject it because RFC 7519 declares every Unsecured JWT malformed in all application contexts B. Reject it under this signed-token profile: syntactic support for an Unsecured JWT supplies no issuer authentication C. Accept it because valid aud and exp claims compensate for the missing signature D. Replace none with an allowed algorithm locally and validate the unchanged empty signature

**Explanation:** A: Section 6 explicitly defines the Unsecured JWT form, so it is not universally malformed. B: The stated profile requires authentication by a configured issuer. Sections 7.2 and 11.1 leave algorithm acceptance and the trust context to the application and do not turn syntactic validity into trust. This input therefore fails the profile even though RFC 7519 can represent it. C: Audience and time claims are untrusted assertions when the required issuer protection is absent. D: Changing the JOSE Header changes the protected input and cannot create a valid signature.

JSON Web Token (JWT)

Primary reference

Q1: Which claims does RFC 7519 require in every JWT?

Q2: How should an A2A recipient validate aud?

Q3: May an unverified iss claim select its own verification key?

Q4: Is this token currently within its time window?

Q5: Does jti alone prevent token replay?

Q6: How should a gateway handle a JWT addressed only to itself?

Q7: May different components choose different duplicate claim values?

Q8: Does RFC support for an Unsecured JWT make it acceptable here?