RFC 8747 Quiz (EN)

Q1: Which cnf profile rule is consistent with RFC 8747?

Multiple Choice

An A2A profile requires proof of possession and supports the COSE_Key, Encrypted_COSE_Key, and kid confirmation members.

A. Put COSE_Key and Encrypted_COSE_Key together in cnf so the recipient can select whichever representation it prefers B. Put several presenter keys in one cnf map because each registered member represents an independent proof-of-possession key C. Represent one proof-of-possession key in cnf and define which confirmation member the A2A application requires and understands D. Require recipients to reject every unknown cnf member even when the application has not made that member required

**Explanation:** A: Section 3.1 permits at most one of COSE_Key and Encrypted_COSE_Key in the cnf value. B: Section 3.1 says the cnf value represents only a single proof-of-possession key; applications needing additional keys use separately defined claims. C: Correct. Section 3.1 defines the one-key structure and leaves the required confirmation-member set context dependent. D: In the absence of application requirements, Section 3.1 says unrecognized confirmation members are ignored.

Q2: What does cnf containing only kid establish?

Multiple Choice

A CWT contains cnf={kid:h'01ab'}. The recipient has not yet looked up a key or run the A2A proof protocol.

A. It identifies the proof-of-possession key in an application-specific way; the recipient still obtains that key and verifies a protocol-defined proof B. It proves possession because a kid can be produced only by a party that knows the corresponding private or symmetric key C. It carries the complete public key in compact form, so the recipient reconstructs a COSE_Key directly from the kid bytes D. It authenticates the CWT issuer and presenter as the same entity without any application-specific key lookup

**Explanation:** A: Section 3.4 defines kid as an application-specific identifier and requires the recipient to be able to obtain the identified key and confirm possession. B: An identifier can be copied; possession is established by a separate cryptographic protocol. C: Section 3.4 does not define an internal key encoding for kid. D: The issuer's protection of the CWT and the presenter's proof of the confirmation key are distinct operations.

Q3: May the resource server treat this CWT as a bearer token?

Multiple Choice

The CWT is valid and contains a COSE_Key in cnf. The A2A profile says access is sender-constrained and requires a fresh proof over the request nonce. The resource server validates the CWT but receives no signature, MAC, or other proof made with the confirmation key.

A. Accept because placing a COSE_Key in a protected cnf claim proves that the current presenter controls its private key B. Accept after comparing the COSE_Key to the issuer's signing key, since the issuer signature can double as presenter proof C. Reject the CWT as malformed because RFC 8747 defines the complete nonce exchange inside the cnf claim itself D. Do not authorize yet; run the profile's fresh proof and verify it with the cnf key before treating the request as sender-constrained

**Explanation:** A: The cnf value conveys the issuer's confirmation-key statement; it is not the presenter's proof for this request. B: Token-issuer authentication and possession of the confirmation key are separate unless a profile explicitly and safely makes them the same key and proof. C: Section 3.5 intentionally leaves nonce communication and proof transport to the using protocol. D: Sections 3.5 and 4 require the surrounding protocol to provide current, replay-resistant proof for the claimed key. The stated A2A profile supplies that criterion.

Q4: How should the validator handle this cnf value?

Multiple Choice

A protected CWT contains both COSE_Key and Encrypted_COSE_Key members in the same cnf map. They decrypt or decode to different public keys. The profile requires a single unambiguous presenter key.

A. Prefer Encrypted_COSE_Key because confidentiality gives that member precedence over a plaintext COSE_Key B. Reject the token under the cnf structure rule rather than selecting either key for the profile's proof C. Try proof verification with both keys and accept if either succeeds, treating cnf as an alternative-key list D. Select the first member in CBOR map order because encoding order defines the issuer's preferred key

**Explanation:** A: Section 3.1 defines no precedence rule between these members. B: Section 3.1 permits at most one of COSE_Key and Encrypted_COSE_Key and says cnf represents one proof-of-possession key. C: Treating the map as alternatives changes the defined semantics and can let implementations select different keys. D: CBOR map order is not a confirmation-method preference signal.

Q5: Is the signed-only CWT adequate for this symmetric confirmation key?

Multiple Choice

The issuer puts a symmetric COSE_Key, including its key value, in cnf and signs the CWT but does not encrypt it. Intermediaries can read the token. The profile relies on exclusive possession of that symmetric key.

A. No; add confidentiality for the symmetric key while retaining integrity, using an appropriate encrypted confirmation-key profile B. Yes; a valid issuer signature prevents readers from learning the symmetric key even when the CWT remains plaintext C. Yes if the kid is also present, because a key identifier converts visible symmetric key bytes into non-secret metadata D. No; symmetric confirmation keys are prohibited, so the profile must replace the key with an asymmetric COSE_Key

**Explanation:** A: Section 4 says symmetric keys carried in a CWT require confidentiality protection as well as origin authentication and integrity protection. B: A signature detects modification but does not conceal the signed payload. C: Adding an identifier does not remove or hide the exposed key value. D: RFC 8747 permits symmetric proof-of-possession keys when they are protected appropriately.

Q6: What must the backend require before calling this end-to-end proof of possession?

Multiple Choice

An A2A agent proves possession of the CWT cnf key by signing a gateway nonce. The gateway then forwards the CWT and a boolean pop_ok=true to a backend on a separate request. Backend policy requires a current proof bound to the backend operation and rejects replay of a gateway exchange.

A. Accept pop_ok because any fresh proof to a trusted gateway remains fresh and party-bound for every downstream operation B. Verify only the CWT again; the protected cnf claim supplies the missing backend nonce and request binding C. Require a backend-bound proof, or define the gateway as a trusted verifier that issues a protected assertion carrying nonce, parties, operation, and freshness semantics D. Forward the original gateway signature and accept it unchanged because proof transport, challenge content, and participating-party binding are fixed by RFC 8747

**Explanation:** A: Section 4 requires current, replay-resistant proof and notes that protocols link the proof key to participating parties; a new hop changes that context. B: The cnf claim identifies the key but does not contain the backend's challenge or proof for this request. C: Sections 3.5 and 4 leave the proof protocol to the application. Either composition can meet the stated criterion if its trust boundary and protected assertion semantics are explicit. D: RFC 8747 intentionally does not define nonce communication, signed-nonce transport, or a universal party-binding method.

Proof-of-Possession Key Semantics for CWTs

References (URLs)

Q1: Which cnf profile rule is consistent with RFC 8747?

Q2: What does cnf containing only kid establish?

Q3: May the resource server treat this CWT as a bearer token?

Q4: How should the validator handle this cnf value?

Q5: Is the signed-only CWT adequate for this symmetric confirmation key?

Q6: What must the backend require before calling this end-to-end proof of possession?