Implementation name and version: action_ref / Mycelium Trails (argentum-core) — independent Ed25519 implementation (pynacl), cross-checking against your conformance/vectors/signed-proof.json
Compliance level claimed: L1 subset only (signature verification over your JCS-canonicalized payloads) — not claiming full L1, since we verified signatures over already-decoded payloads rather than independently re-deriving RFC 8785 canonicalization from scratch. Happy to close that gap if useful.
Test results:
- Your own
conformance/verify.py, run unmodified: 10/10 PASS.
- Our independent cross-check (pynacl, different Ed25519 implementation than your reference adapter) against
signed-proof.json (5 vectors): 4/5 exact match against expected (valid-basic pass; tampered-signature, wrong-key, timestamp-skew-exceeded fail, as expected).
- 1/5 finding worth flagging:
tampered-meta. The JWS itself is byte-identical to valid-basic (same decoded payload) — what differs is a mirrored meta.requestHash field outside the JWS. A verifier that only checks JWS signature validity (which is cryptographically correct here) passes this vector; catching it requires cross-validating meta against the signed payload as an application-level check, not a signature-level one. Might be worth calling out explicitly in CONFORMANCE.md if it isn't already — it's a subtle distinction between "signature valid" and "meta consistent with signed content."
Implementation repo/package: https://github.com/giskard09/argentum-core, spec: draft-etcheverry-action-ref (IETF)
Notes: delegation-chain.json uses Ed25519Signature2020 (VC linked-data proof), different canonicalization than plain JCS — not independently re-verified yet, leaving that open rather than claiming it. Separately, our own JCS module currently only covers flat string dicts (our action-ref.md profile), not the full RFC 8785 surface your vectors exercise (nested objects, numbers, non-BMP keys) — noting for full transparency of what was and wasn't checked on our end.
Implementation name and version: action_ref / Mycelium Trails (argentum-core) — independent Ed25519 implementation (pynacl), cross-checking against your
conformance/vectors/signed-proof.jsonCompliance level claimed: L1 subset only (signature verification over your JCS-canonicalized payloads) — not claiming full L1, since we verified signatures over already-decoded payloads rather than independently re-deriving RFC 8785 canonicalization from scratch. Happy to close that gap if useful.
Test results:
conformance/verify.py, run unmodified: 10/10 PASS.signed-proof.json(5 vectors): 4/5 exact match against expected (valid-basic pass; tampered-signature, wrong-key, timestamp-skew-exceeded fail, as expected).tampered-meta. The JWS itself is byte-identical tovalid-basic(same decoded payload) — what differs is a mirroredmeta.requestHashfield outside the JWS. A verifier that only checks JWS signature validity (which is cryptographically correct here) passes this vector; catching it requires cross-validatingmetaagainst the signed payload as an application-level check, not a signature-level one. Might be worth calling out explicitly in CONFORMANCE.md if it isn't already — it's a subtle distinction between "signature valid" and "meta consistent with signed content."Implementation repo/package: https://github.com/giskard09/argentum-core, spec: draft-etcheverry-action-ref (IETF)
Notes:
delegation-chain.jsonusesEd25519Signature2020(VC linked-data proof), different canonicalization than plain JCS — not independently re-verified yet, leaving that open rather than claiming it. Separately, our own JCS module currently only covers flat string dicts (our action-ref.md profile), not the full RFC 8785 surface your vectors exercise (nested objects, numbers, non-BMP keys) — noting for full transparency of what was and wasn't checked on our end.