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: Two implementations produce the same JCS bytes. What can be concluded?

Multiple Choice

A. The JSON claims are authorized for every recipient B. Every string is semantically equivalent in all languages C. They agreed on the canonical representation of the same constrained JSON data

**Explanation:** A: Canonicalization does not grant authorization. B: JCS preserves code points and does not interpret natural-language meaning. C: JCS provides deterministic bytes but leaves claim meaning and trust to the application.

Q10: For a signed Agent Card, which boundary must the application profile still define?

Multiple Choice

A. Only the color used to display the card B. Field presence, signed-object construction, and verification policy C. A rule that canonical bytes remove the need for key validation

**Explanation:** A: Display styling does not determine cryptographic coverage. B: All parties must build the same logical object and apply the same acceptance rules around JCS. C: Deterministic bytes do not authenticate the signing key.

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: Two implementations produce the same JCS bytes. What can be concluded?

Q10: For a signed Agent Card, which boundary must the application profile still define?