RFC 7515 Quiz

Q1: Does the valid signature cover the routing decision?

Multiple Choice · L3

An A2A gateway receives an envelope containing a compact JWS and a separate target member. The signed payload names agent A, while the outer member names agent B. The JWS validates, and the gateway routes by the outer member.

A. No. The outer member is outside the compact JWS signing input and must be bound into signed content if it controls routing B. Yes. A valid JWS also authenticates adjacent members when the JWS and those members arrived in the same JSON envelope C. Yes, if the gateway serializes the complete envelope after validation and stores the resulting bytes with the request

**Explanation:** A is correct. Sections 5.1 and 5.2 define the signing input from the encoded protected header and payload. An enclosing application member is not added merely by being adjacent to the JWS. If target controls routing, the application profile should place that decision value in protected content before signing and check it after validation. B invents protection for bytes that were never part of the signing input. C records the received envelope but cannot retroactively change what the signer signed. The issue is the boundary of cryptographic coverage, not whether the outer object is valid JSON.

Q2: How should a verifier handle conflicting protected and unprotected parameters?

Multiple Choice · L3

A flattened JWS JSON object has alg: ES256 in its protected header and alg: HS256 in its unprotected header. A library offers to prefer the protected value and continue.

A. Continue with ES256 because integrity protection gives the protected occurrence precedence over the duplicate B. Continue with HS256 because the unprotected header is easier for an application to inspect before verification C. Treat the signature as invalid because the protected and unprotected header parameter names must be disjoint

**Explanation:** C is correct. Sections 5.2 step 4 and 7.2 require the parameter names in the protected and unprotected header objects to be disjoint. A duplicate alg is therefore a malformed JOSE Header for this signature; precedence is not a repair rule. A would conceal a prohibited collision, even though protecting alg is a sound design. B is worse because the unprotected value can be altered without invalidating the signature. The verifier should fail this signature rather than select either occurrence.

Q3: May an unknown critical extension be ignored after the signature verifies?

Multiple Choice · L3

A protected header contains crit: ["session-bind"] and a session-bind value. The signature verifies cryptographically, but this verifier has no implementation of that extension.

A. Accept it because successful signature verification proves that the unknown extension was not modified B. Reject it because a parameter named by crit must be understood and processed by the recipient C. Remove the extension and crit, then verify the remaining protected header against the original signature

**Explanation:** B is correct. Section 4.1.11 says that an extension listed in crit must be understood and processed; otherwise the JWS is invalid. Integrity of unknown semantics is not enough. A confuses protection from alteration with the ability to apply the sender's required processing. C changes the protected header and therefore changes the signing input; it cannot preserve the original validation result. The safe outcome mandated by the critical-extension mechanism is rejection.

Q4: Is mathematical verification enough when the profile disallows the algorithm?

Multiple Choice · L3

An Agent Card profile permits only EdDSA. A legacy card uses ES256 with a trusted key, and the cryptographic library reports a valid signature. The verifier supports both algorithms.

A. Accept it because a trusted key makes the profile's algorithm restriction advisory after verification succeeds B. Accept it because support in the cryptographic library makes every implemented algorithm acceptable to the application C. Reject it because cryptographic success and application algorithm acceptance are separate conditions

**Explanation:** C is correct. Section 5.2 makes acceptable algorithms an application decision and says a successfully validated JWS using an unacceptable algorithm should be considered invalid. Section 10.6 also requires implementations to check that algorithm information in the signature corresponds to the alg header. A confuses key trust with algorithm policy. B confuses implementation capability with authorization to use that capability in this profile. Because the stated profile accepts only EdDSA, ES256 fails the application's acceptance rule even though the mathematical check succeeds.

Q5: What follows from a successful TLS fetch of a header-selected JWK Set?

Multiple Choice · L3

A verifier follows a protected jku supplied by an untrusted sender. HTTPS and server-identity validation succeed, the returned set contains the named kid, and that key validates the JWS. The URL's host is not an issuer configured by the application.

A. Accept it because RFC 7515's TLS requirement makes any successfully authenticated HTTPS host an authorized signing authority B. Do not infer signer authority from those checks; apply application policy for trusted key origins and for whether sender-selected retrieval is allowed C. Accept it because matching kid proves that the returned key belongs to the agent named in the payload

**Explanation:** B is correct. Section 4.1.2 requires integrity-protected retrieval and TLS server-identity validation for an HTTP jku fetch. Those checks authenticate the contacted service; they do not establish that the application authorizes that service to supply keys for the claimed signer. Section 10.3 separately requires the key-management technique to authenticate key origin. A turns a transport requirement into an application trust grant. C overstates kid, which Section 4.1.4 defines only as a key-selection hint. Restricting acceptable key sources and deciding whether to dereference sender-controlled URLs are application security policies, not guarantees supplied by JWS validation.

Q6: Does one valid signature satisfy a two-signer acceptance policy?

Multiple Choice · L3

A general JWS JSON object carries signatures from an issuer, an auditor, and an unrelated service. The application requires both the issuer and auditor. Only the issuer and unrelated-service signatures validate.

A. Reject it: process the signatures and enforce the application's requirement that both designated signers validate B. Accept it: RFC 7515's at-least-one rule prevents an application from requiring more than one valid signature C. Accept it: two signatures validated, so signer identity and the application's designated roles no longer matter

**Explanation:** A is correct. Section 5.2 requires validation processing for each signature and makes it an application decision which signatures must succeed. At least one valid signature is the RFC-level floor, not a ceiling on the application's policy. B reverses that relationship. C counts successes without checking whether the required auditor signed. A verifier must return or retain which signatures succeeded so that the application can enforce the issuer-plus-auditor rule.

Q7: Can semantically equivalent JSON replace a detached JWS payload?

Multiple Choice · L3

A detached JWS was created over UTF-8 JSON bytes containing a particular member order and whitespace. The receiver parses a stored copy, emits semantically equivalent JSON with different bytes, and wants to insert that serialization before validation.

A. Yes, because JWS signs the abstract JSON data model rather than a byte representation of the payload B. Yes, provided the receiver compares the parsed objects before it performs signature validation C. No. It must reconstruct the exact signed payload unless a separate profile applied canonicalization before signing

**Explanation:** C is correct. Appendix F's detached-content method assumes that the recipient can reconstruct the exact payload used in the JWS. Sections 5.1 and 5.2 operate on the payload's encoded octets, not on semantic equality between parsed JSON objects. A describes a canonical data-model signature that RFC 7515 does not provide. B may be useful as an application comparison, but it cannot make different bytes satisfy the original signature. A separate profile could prescribe canonicalization, but both signer and verifier would have to apply that rule to the signed representation.

Q8: Which conclusion correctly composes JWS validation with A2A authorization?

Multiple Choice · L4

A cached Agent Card JWS validly signs an agent identifier and endpoint. The verifier trusts the signing key and accepts the algorithm. The card has no signed audience, expiry, or unique identifier. A separate grant is valid for workflow X. An attacker replays the same card and request in workflow Y.

A. Accept it because a valid card signature carries the separate grant's workflow scope and supplies replay protection for every request using the card B. Treat signed fields as intact, but evaluate grant scope, audience, freshness, and replay separately under the application profile C. Reject all cached signed cards because RFC 7515 requires every JWS to contain standardized audience, expiry, and nonce claims

**Explanation:** B is correct. The valid signature establishes integrity for the protected header and signed payload under the selected trusted key. It does not copy the separate grant's scope into the card or create audience, freshness, and replay semantics that were never signed. A conflates independent evidence and acceptance checks. C invents mandatory JWS claims: RFC 7515 defines the signature format, not a universal Agent Card claim set. Section 10.10 explicitly treats replay protection as an application concern and gives an integrity-protected unique identifier plus prior-use checking as one possible design. An A2A profile must define the decision fields, their protected placement, and the checks that connect the card, grant, request, and workflow.

JWS protection, serialization, and validation boundaries

References

Q1: Does the valid signature cover the routing decision?

Q2: How should a verifier handle conflicting protected and unprotected parameters?

Q3: May an unknown critical extension be ignored after the signature verifies?

Q4: Is mathematical verification enough when the profile disallows the algorithm?

Q5: What follows from a successful TLS fetch of a header-selected JWK Set?

Q6: Does one valid signature satisfy a two-signer acceptance policy?

Q7: Can semantically equivalent JSON replace a detached JWS payload?

Q8: Which conclusion correctly composes JWS validation with A2A authorization?