RFC 8949 Quiz (EN)

Q1: Is this CBOR item acceptable to the A2A operation?

Multiple Choice

A decoder accepts a well-formed and valid CBOR text string. The A2A operation schema requires a map containing integer keys 1 and 2.

A. Yes; once a generic decoder reports valid CBOR, every application schema must accept the resulting data item B. No for this operation; the item can be valid CBOR yet fail the application's expected-input rules C. No because text strings are not part of the CBOR generic data model and therefore cannot be well-formed D. Yes if the text is UTF-8, because application-level map requirements apply only to deterministic encodings

**Explanation:** A: Section 5 distinguishes valid CBOR from input expected by a particular application protocol. B: Correct. Sections 5 and 5.3 treat well-formedness, validity, and application expectations as successive checks. C: Text strings are a basic CBOR data type; the defect is a schema mismatch, not CBOR syntax. D: UTF-8 validity does not convert a text string into the map required by the operation.

Q2: Does RFC 8949 require every CBOR message to use core deterministic encoding?

Multiple Choice

An A2A telemetry message is decoded only to data-model values; it is not hashed, signed by encoded bytes, or compared byte-for-byte. Its profile has not selected a deterministic encoding.

A. Yes; preferred serialization and sorted map keys are mandatory for every well-formed CBOR item B. Yes; any two encodings of the same data-model value are invalid unless their bytes are identical C. No; deterministic encoding is prohibited unless the message is wrapped in a registered CBOR tag D. No; a profile selects Section 4.2 deterministic rules when the application needs stable bytes

**Explanation:** A: Section 4.1 explains that preferred serialization is not generally required; Section 4.2 defines deterministic variants for protocols that need them. B: CBOR normally permits multiple well-formed encodings of a data-model value. C: Deterministic encoding is independent of whether the item carries a tag. D: Correct. A profile can select the core requirements in Section 4.2.1 or a specified alternative such as Section 4.2.3.

Q3: How should the authorization parser handle this map?

Multiple Choice

An attacker sends a CBOR map containing role twice: role=reader followed by role=admin. The gateway library keeps the first entry; the backend library keeps the last. The profile requires one unambiguous role value for authorization.

A. Use the first value at both services because streaming decoders encounter it before the duplicate B. Use the last value at both services because later map entries act as explicit updates to earlier entries C. Reject before authorization using duplicate detection at the decoder or application boundary required by the profile D. Let each service use its native map behavior, then reconcile authorization differences in downstream logs

**Explanation:** A: Section 5.3.1 identifies duplicate map keys as a validity error and notes that decoder behaviors differ. B: CBOR maps are not update logs; the generic data model has unique keys. C: Correct. Sections 5 and 5.3.1 require the CBOR-based protocol to define handling, and this security profile needs a single interpretation. D: Divergent native behavior creates exactly the cross-component security failure in the premise.

Q4: Why do signatures fail between these implementations?

Multiple Choice

Two A2A implementations sign the CBOR-encoded request bytes after locally re-encoding the same map. One uses Section 4.2.1 core deterministic encoding; the other uses Section 4.2.3 length-first map ordering. The profile says only deterministic CBOR and requires identical signature inputs.

A. The profile is ambiguous; select one deterministic rule and the exact signing input rather than treating both byte orders as interchangeable B. Both signatures should verify because deterministic encodings always produce identical bytes for the same data-model value C. Prefer whichever signature was generated first, since timing resolves deterministic-encoding conflicts without changing the profile D. Decode both signatures into maps before verification, because a signature operation authenticates abstract CBOR values rather than bytes

**Explanation:** A: Sections 4.2.1 and 4.2.3 intentionally define different map ordering. A byte-signing profile must choose one and define its signing input. B: Each variant is deterministic within its own rules, but the two variants need not produce the same bytes. C: Message timing is not part of either deterministic encoding and cannot repair an interoperability rule. D: Cryptographic signatures operate on defined bytes; decoding a signature does not transform its signed input.

Q5: Which design meets the parser-availability criterion?

Multiple Choice

An unauthenticated A2A endpoint accepts well-formed CBOR. A 2 KB input can declare enormous lengths or deeply nest arrays until the decoder exhausts memory or stack. The requirement is bounded work before authentication.

A. Rely on well-formedness checks because syntactically valid lengths and nesting cannot be used for resource exhaustion B. Parse without limits over TLS because transport authentication makes the encoded length and nesting trustworthy C. Allocate the declared sizes first and reject only when the complete application object fails its schema checks D. Enforce profile and implementation limits on sizes, nesting, allocation, and numeric processing before constructing unbounded objects

**Explanation:** A: Section 10 describes hostile, well-formed inputs that use large sizes or deep nesting to exhaust resources. B: Section 10 says decoders must treat input as hostile even after TLS, signing, or other presumed-trusted sources. C: Early attacker-driven allocation violates the bounded-work criterion and can fail before schema validation. D: Section 10 calls for appropriate resource management against large data items, stack exhaustion, integer issues, and superlinear work. Exact limits are profile or implementation policy.

Q6: How should the A2A profile define its idempotency key?

Multiple Choice

An agent computes request_id=SHA-256(encoded CBOR). A gateway decodes and re-encodes the same data-model value using a different valid representation before sending it to the backend, which recomputes request_id. The profile requires semantically identical requests to have the same ID across this gateway.

A. Hash whichever valid encoding each hop receives because CBOR data-model equality guarantees byte-hash equality B. Select one deterministic hash input, or carry and protect the original ID without assuming re-encoding preserves it C. Require the backend to accept both IDs and choose the smaller hash value as the canonical request identity D. Add the self-described CBOR tag before hashing, since tag 55799 makes all encodings of the tagged value byte-identical

**Explanation:** A: Sections 4.1 and 4.2 distinguish data-model equality from deterministic byte representation. B: This meets the stated cross-gateway identity criterion. Sections 4.2 and 5.6 provide encoding and map-key choices that the A2A profile must make explicit. C: Treating two IDs as one after the fact creates ambiguity for replay and authorization checks. D: A tag identifies CBOR but does not normalize the encoding of its content.

Concise Binary Object Representation (CBOR)

References (URLs)

Q1: Is this CBOR item acceptable to the A2A operation?

Q2: Does RFC 8949 require every CBOR message to use core deterministic encoding?

Q3: How should the authorization parser handle this map?

Q4: Why do signatures fail between these implementations?

Q5: Which design meets the parser-availability criterion?

Q6: How should the A2A profile define its idempotency key?