JSON Canonicalization Scheme (RFC 8785)

The JSON Canonicalization Scheme (JCS), published as RFC 8785 in June 2020, defines one deterministic way to serialize JSON data so that hashing and signing give repeatable results.

Why it exists. Two JSON texts can carry the same data and still differ byte for byte. Property order, whitespace, number formats such as 4.50 and 4.5, and string escapes all vary between libraries. A signature covers bytes, so the signer and the verifier need the same bytes.

The rules. Input must fit the I-JSON subset (RFC 7493): no duplicate property names, and numbers that fit in an IEEE 754 double. The RFC recommends sending larger integers as strings. JCS then:

• emits no whitespace between tokens;
• serializes strings, numbers and literals the way ECMAScript’s JSON serializer does;
• sorts object properties recursively by their UTF-16 code units, while array order stays unchanged;
• encodes the result as UTF-8.

JCS does not apply Unicode normalization, so string data must pass through unchanged. RFC 8785 is an Informational RFC from the Independent Submission stream. It is not an IETF Standards Track document.

In A2A. Section 8.4.1 of the A2A specification requires JCS before an Agent Card is signed or verified. First the card is prepared under Protocol Buffer field-presence rules: the signatures field is removed, and fields holding default values are dropped unless they are required or were explicitly set. The specification’s own example starts with this fragment:

{
  "name": "Example Agent",
  "description": "",
  "capabilities": {"streaming": false, "pushNotifications": false, "extensions": []},
  "skills": []
}

and produces this canonical payload:

{"capabilities":{"pushNotifications":false,"streaming":false},"description":"","name":"Example Agent","skills":[]}

The empty extensions array is dropped because it is an empty, non-required repeated field. The two false values stay because they are optional fields that were explicitly set. The empty description and skills stay because they are required. Keys come out in sorted order with no spaces.

Neighbouring terms. The canonical bytes become the payload of a JWS, and the verifier gets the matching public key from a JWKS.