RFC 7800 Quiz (EN)

Q1: What does a cnf claim establish by itself?

Multiple Choice

A signed A2A task token contains a cnf claim with the presenter's public key. The request carries the token but no separate proof made with the corresponding private key.

A. It proves that the presenter controlled the private key for this request because the token is signed B. It identifies the expected key; the profile must supply and verify the possession proof C. It authorizes every request made by any presenter that can read the token D. It converts the JWT into an encrypted token whose claims are hidden from non-holders

A: The issuer's token signature authenticates the cnf claim; it does not demonstrate that the request presenter controls the referenced private key. B: RFC 7800 Sections 3 and 3.6 define the confirmation-key semantics but intentionally leave the actual proof protocol to the application. C: cnf is intended to constrain presentation, not grant bearer use or resource permission. D: A public confirmation key does not encrypt the JWT.

Q2: How may confirmation keys be carried in a JWT?

Multiple Choice

An A2A profile considers placing either an asymmetric public JWK or a symmetric MAC key directly in cnf of a signed but unencrypted JWT.

A. Either key may appear in plaintext because a JWT signature provides confidentiality for registered claims B. Neither key may appear in cnf; only a kid value is permitted C. A public JWK may be direct; a symmetric key needs confidentiality through an encrypted JWT or key value D. A symmetric key may be public if the JWT lifetime is shorter than the request timeout

A: A signature supplies integrity and origin authentication, not confidentiality. B: RFC 7800 defines both direct JWK and key-identifier representations. C: RFC 7800 Sections 3.2 and 3.3 distinguish public asymmetric JWK use from symmetric key material that must be encrypted from unauthorized parties. D: A short lifetime does not make disclosure of a live MAC key safe.

Q3: Is this holder proof sufficient for request-level sender constraint?

Multiple Choice

A presenter signs a fixed string with the cnf private key. The same signature is sent with every A2A request; it covers no method, URI, body digest, nonce, or time value. The profile requires proof bound to each request and resistant to replay.

A. Yes; verifying any signature under the cnf key automatically binds every request carrying the JWT B. Yes, if the JWT audience names the API, because audience also supplies proof freshness C. No; RFC 7800 mandates one universal nonce format that this implementation failed to include D. No. The profile verifies proof over request context and freshness; RFC 7800 defines key semantics, not proof format

A: A reusable fixed-string signature demonstrates key use but not integrity or freshness of a particular request. B: Audience restricts token recipients; it does not make a separate holder proof fresh. C: RFC 7800 Section 3.6 deliberately leaves nonce and proof details to the application protocol. D: The profile's stated request-binding and replay-resistance criteria make the reusable signature insufficient. Section 3.6 leaves the proof format to the application, while Section 4 describes distinct challenges or instance-specific sub-keys as possible replay defenses rather than one universal format.

Q4: How should an ambiguous cnf kid be resolved?

Multiple Choice

Two A2A tenants both use cnf kid "signing-key-1" for different keys. The verifier looks up kid in a single global table without first binding it to the trusted token issuer or tenant context.

A. Use the first global match because kid values are globally unique by definition B. Scope kid to an authenticated issuer, tenant, or other trusted namespace before selecting the key C. Try every matching key and accept if any proof verifies, without recording which tenant supplied it D. Hash the kid string and use the digest itself as the proof-of-possession key

A: RFC 7800 does not make kid globally unique. B: RFC 7800 Section 3.4 says kid content is application specific and works only when the recipient can obtain the identified key. The profile must prevent cross-namespace key confusion. C: Trying all keys discards the trusted identity context needed to interpret the identifier. D: An identifier digest is not key material and proves no possession.

Q5: May a cnf token fall back to bearer processing?

Multiple Choice

An A2A resource accepts a token with the correct audience and a cnf claim. If the request has no valid holder proof, the implementation ignores cnf and processes the token as a bearer token. The profile requires proof of possession.

A. Yes, because a correct audience makes presenter constraint unnecessary B. Yes, if the token signature is valid and the cnf key has not expired C. No. A PoP profile rejects missing or invalid proof even after token validation D. No, because a token containing cnf can never carry an aud claim

A: RFC 7800 Section 4 explains that proof of possession and audience provide different protections. B: Token validation authenticates the claim, not current possession by this presenter. C: This applies the profile's explicit acceptance criterion without inventing a universal bearer-fallback rule. Section 3.1 requires unknown confirmation members to be ignored only in the absence of application requirements to understand them. D: aud and cnf can coexist and address independent security properties.

Q6: How should a gateway delegate a verified cnf result?

Multiple Choice

A gateway validates a cnf token and holder proof for an incoming request, then forwards only X-Proof-Valid: true to a backend over another connection. The backend owns the resource and cannot inspect the original proof.

A. The backend verifies end-to-end proof, or trusts a protected request-bound gateway assertion; it then authorizes separately B. Keep the boolean header because successful proof verification remains self-authenticating after transport C. Forward only the cnf key because knowing a public key proves the gateway checked its private-key holder D. Treat gateway proof success as final backend authorization because sender constraint includes resource permission

A: RFC 7800 Sections 3.6 and 4 leave proof transport and replay controls to the application. This is therefore a system-design conclusion: either choice makes the verifier and trust boundary explicit and preserves request context; the resource owner still decides authorization. B: An ordinary boolean is not cryptographic evidence and is not bound to a request. C: A public key identifies what should be proven, not whether possession was verified. D: Proof of possession and resource authorization are independent.

Q7: How should the recipient process this cnf object?

Multiple Choice

To support rollover, an issuer puts both jwk and jku in one cnf object. The jku points to a backup key, and kid accompanies it. The recipient implements RFC 7800 without an extension that defines multiple confirmation keys.

A. Prefer jwk because a key passed by value always overrides a referenced key B. Try both keys and accept whichever proof verifies first C. Reject the token because one cnf value may represent only one proof-of-possession key D. Accept both because kid removes the one-key restriction

A: RFC 7800 defines no precedence between jwk and jku. B: Trying both would silently create semantics that the token format does not define. C: Section 3.1 says cnf MUST represent only one proof-of-possession key and therefore permits at most one of jwk, jwe, and jku. An application needing multiple keys must define another claim or extension. D: Section 3.5 allows kid to select a key in a referenced set; it does not permit a second key representation in cnf.

Q8: May the recipient accept the key obtained through this jku?

Multiple Choice

A cnf jku uses an http URL. The returned JWK Set contains three keys, but cnf has no kid. The recipient happens to recognize one key from an earlier response.

A. Yes, because prior recognition replaces transport and key-selection checks B. No; protected retrieval and a matching kid are both missing C. Yes, if the recipient tries all three keys and one proof verifies D. No, because RFC 7800 forbids every remote JWK Set

A: Cached recognition does not satisfy the requirements for this acquisition and selection. B: Section 3.5 requires integrity protection; an HTTP GET MUST use TLS and validate the server identity. When the set contains multiple keys, cnf and the selected JWK MUST carry the same kid. C: Trial verification bypasses the specified key-selection condition. D: jku is expressly defined; the problem is the unprotected URL and missing selector, not remote retrieval itself.

Q9: Can this implementation claim conformance to the A2A profile?

Multiple Choice

An A2A profile requires a registered cnf member named agent_proof. A JWT library does not understand that member, ignores it, and accepts the token after ordinary JWT validation.

A. Yes, because every unknown cnf member MUST always be ignored B. Yes, because ordinary JWT validation supplies the missing confirmation processing C. No, because RFC 7800 requires rejection of every unknown cnf member D. No. This profile requires agent_proof to be understood and processed

A: Section 3.1 limits the MUST-ignore rule to the absence of requirements to process the member. B: JWT validation protects the claim set but does not implement an application-specific confirmation method. C: RFC 7800 deliberately permits extension members and does not impose universal rejection. D: Section 3.1 says applications that require particular confirmation members must ensure implementations understand and process them. Acceptance here violates the stated profile, not a universal unknown-member rule.

Q10: What is the appropriate privacy review conclusion?

Multiple Choice

An agent reuses one long-lived confirmation key in JWTs sent to unrelated recipients. Each recipient logs the key identifier, and the logs are later combined. The protocol otherwise verifies possession correctly.

A. Possession is valid, but the stable key can correlate recipients; key scope and rotation are application choices B. Successful proof makes correlation impossible because private key bytes never leave the presenter C. RFC 7800 requires a new confirmation key for every individual request D. Removing aud is the RFC-defined way to prevent key correlation

A: Section 5 warns that a proof-of-possession key can be a correlation handle. It does not prescribe one universal lifetime, so key scope and rotation are application privacy decisions. B: Observers can correlate a stable public key or identifier without learning the private value. C: RFC 7800 states the privacy risk but does not mandate per-request keys. D: Audience restriction protects a different boundary and removing it would not erase the stable identifier.

Proof-of-Possession Key Semantics for JWTs

Primary reference

Q1: What does a cnf claim establish by itself?

Q2: How may confirmation keys be carried in a JWT?

Q3: Is this holder proof sufficient for request-level sender constraint?

Q4: How should an ambiguous cnf kid be resolved?

Q5: May a cnf token fall back to bearer processing?

Q6: How should a gateway delegate a verified cnf result?

Q7: How should the recipient process this cnf object?

Q8: May the recipient accept the key obtained through this jku?

Q9: Can this implementation claim conformance to the A2A profile?

Q10: What is the appropriate privacy review conclusion?