[pavancharak]

Two fixes to integrations/parmana-server/README.md:

• The Parmana link on line 3 now points to pavancharak/parmana-core. It previously pointed to pavancharak/parmana.
• The canonical-form sentence said Parmana signs "not RFC 8785". For plain JSON values Parmana's serializer matches RFC 8785, and the parmana-core tests in pavancharak/parmana-core#317 pin that. The two non-JSON differences (undefined values dropped, Date values as ISO strings) are now stated.

This is documentation only. It does not change the verified fixture path or the tier.

Supersedes #414, which changes the same line 3 but with a broken link.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[pavancharak]

docs(parmana-server): fix typo on line 8

[pavancharak]

@carloshvp @imran-siddique when you have a moment, could you review this? It's a README-only change: it fixes the Parmana link, replaces the "not RFC 8785" wording with a checked statement, and fixes a typo on line 7. The conformance tests are in pavancharak/parmana-core#317.
)_

[drk-ram]

Reviewed commit c7626d6. The README-only update fixes the repository target and sentence typo, and accurately scopes canonicalization compatibility to plain JSON while documenting the two non-JSON input behaviors. The linked conformance coverage is merged and passing. Approved.

[carloshvp]

Reviewed commit c7626d676e9d281900f0233e43ed2aa46516c46a.

The replacement repository link is public and valid. The new statement that the canonical form matches RFC 8785 for all plain JSON is too broad.

I ran the actual CanonicalSerializer.ts from parmana-core 3bbd4c992a1552b1268b5132aaa7d3213a4ddf97 against an independent RFC 8785 serializer. For the plain-JSON object {"10":1,"2":2}, Parmana emits {"2":2,"10":1}, while RFC 8785 emits {"10":1,"2":2}. Sorting into a JavaScript object does not preserve lexical order for integer-index property names when JSON.stringify enumerates it. The linked conformance tests do not cover this case.

The Python serializer consumed by parmana_evidence.py also documents number-format and Unicode-order limitations. I reproduced {"n":1e-7} becoming {"n":1e-07} in that serializer. Therefore undefined and Date are not the only differences relevant to this integration.

Please scope the paragraph to the tested values and the actual SDK used here, preserving the distinction between Parmana signature bytes and RFC 8785 reference digests. A safe replacement is: "Parmana signs its own canonical representation. This integration verifies those signatures using the Parmana Python SDK and computes TRACE reference digests separately with RFC 8785; equivalence for arbitrary JSON is not claimed." This is a documentation correction, not a claim about a deployed exploit.