RFC 8785 Quiz

Q1: Why is ordinary JSON serialization insufficient as a shared signature input?

Multiple Choice

A. Whitespace, property order, escapes, and number spelling can differ B. JSON has no string or number data types C. Every JSON parser automatically verifies signatures

**Explanation:** A: These legal variations can produce different byte sequences for the same parsed data. B: RFC 8259 defines both strings and numbers. C: Parsing and cryptographic verification are separate operations.

Q2: Which input must a JCS implementation reject before canonicalization?

Multiple Choice

A. An object whose properties arrive in reverse alphabetical order B. An object containing duplicate property names C. An array containing objects

**Explanation:** A: Canonicalization sorts properties, so input order need not already be canonical. B: JCS input objects must not contain duplicate property names. C: Arrays may contain objects and those objects are processed recursively.

Q3: What happens to whitespace between JSON tokens in JCS output?

Multiple Choice

A. It is normalized to one ASCII space B. It is copied exactly from the source text C. It is not emitted

**Explanation:** A: JCS does not emit separator spaces. B: JCS operates on parsed data and does not preserve source formatting. C: RFC 8785 requires no whitespace between JSON tokens.

Q4: How does JCS order JSON object properties?

Multiple Choice

A. Recursively by raw property names represented as UTF-16 code units B. By locale-aware alphabetical order on escaped source text C. By the order in which the sender inserted properties

**Explanation:** A: JCS uses unsigned UTF-16 code-unit comparisons and sorts every child object. B: Locale collation and escape spelling would not produce the specified common order. C: Insertion order is replaced by the JCS sorting rule.

Q5: What does JCS do with array element order?

Multiple Choice

A. It sorts all elements by their serialized bytes B. It preserves element order but canonicalizes any nested objects C. It rejects arrays because they are not deterministic

**Explanation:** A: Changing element order would change the JSON data model. B: Arrays are scanned recursively while their element positions remain unchanged. C: JCS supports arrays with a fixed element order.

Q6: May a JCS implementation apply Unicode normalization to strings before signing?

Multiple Choice

A. Yes, NFC is mandatory for every string B. Yes, when two strings look visually identical C. No, parsed Unicode string data must be preserved as is

**Explanation:** A: RFC 8785 deliberately does not apply Unicode normalization. B: Visual similarity is not a rule for changing the parsed string data. C: Changing string data would change the value being canonicalized and could break signatures.

Q7: How are JSON numbers serialized by JCS?

Multiple Choice

A. Using the specified ECMAScript double-precision number serialization B. By preserving every digit and exponent exactly as received C. By converting every number to a quoted decimal string

**Explanation:** A: JCS fixes number spelling through the ECMAScript serialization algorithm. B: JCS canonicalizes parsed numeric values and does not preserve source spelling. C: Applications may model large numbers as strings, but JCS does not silently change JSON types.

Q8: A parsed value contains a lone surrogate or Infinity. What must a compliant JCS implementation do?

Multiple Choice

A. Replace the value and continue silently B. Terminate with an appropriate error C. Serialize both values as null

**Explanation:** A: Silent replacement changes the data and would make signature behavior ambiguous. B: RFC 8785 requires errors for invalid Unicode and non-JSON numeric values. C: JCS does not define lossy conversion to null.

Q9: Which validation boundary prevents the parser differential?

Multiple Choice

A signed Agent Card arrives as JSON containing two endpoint property names. The signature component keeps the first value when parsing, while the request router later keeps the last value. The team proposes applying JCS independently in both components.

A. Accept the card when either parser can produce a valid JCS byte sequence B. Sort the duplicate properties lexicographically and let the router choose one C. Reject duplicate names at the input boundary and use one validated data model downstream D. Verify the signature before parsing, then permit each component to parse independently

**Explanation:** RFC 8785 Section 3.1 requires JCS input objects not to contain duplicate property names. Canonicalization operates on already constrained parsed data; it cannot make conflicting first-value and last-value interpretations equivalent. C removes the ambiguity before signature verification and routing diverge. A and B accept invalid JCS input, while D is impossible for JCS because constructing the signature input requires the parsed data model.

Q10: Does the valid signature preserve the amount intended by the issuer?

Multiple Choice

An A2A payment grant encodes amount=9007199254740993 as a JSON number. The issuer's implementation parses it as an IEEE 754 double, rounds it, applies JCS, and signs the result. A verifier reproduces the rounded JCS bytes, so the signature verifies, but the business layer displays the original decimal from a separately retained input buffer.

A. Yes; signature validity proves every retained representation has the same numeric value B. No; the profile must encode out-of-range integers safely and authorize the signed data model C. Yes; JCS restores integer precision that was lost before canonicalization D. No; RFC 8785 prohibits JSON numbers in every cryptographic application

**Explanation:** RFC 8785 Section 3.1 limits JCS number data to values expressible as IEEE 754 double precision and recommends strings for higher-precision values, with Appendix D describing such handling. JCS faithfully signs the parsed value; it cannot recover precision already lost or bind an unsigned side buffer. B fixes both boundaries. D is too broad because ordinary JSON numbers within the permitted model are supported.

Deterministic JSON bytes for cryptographic operations

References

Q1: Why is ordinary JSON serialization insufficient as a shared signature input?

Q2: Which input must a JCS implementation reject before canonicalization?

Q3: What happens to whitespace between JSON tokens in JCS output?

Q4: How does JCS order JSON object properties?

Q5: What does JCS do with array element order?

Q6: May a JCS implementation apply Unicode normalization to strings before signing?

Q7: How are JSON numbers serialized by JCS?

Q8: A parsed value contains a lone surrogate or Infinity. What must a compliant JCS implementation do?

Q9: Which validation boundary prevents the parser differential?

Q10: Does the valid signature preserve the amount intended by the issuer?