ATP Core Test Vectors

Introduction specifies a deterministic identity and signature model for agent-action nodes. Two independent implementations presented with the same node content are required to compute byte-identical canonical forms, byte-identical nodeId values, and to verify each other's Ed25519 signatures. This document publishes a starter set of test vectors so that interoperability claims can be substantiated mechanically rather than by inspection. Each vector is computed and recorded in this document; an implementation passes a vector if and only if it produces the exact byte sequence and hex value recorded for that vector. The vectors in this -00 release cover the minimum required for ATP Core conformance: canonicalization fixtures, nodeId computation across representative node shapes, and one Ed25519 sign/verify vector with deterministic key material. Future revisions will add fixtures for validation modes, the Section 13.6 validation result format, profile-field canonicalization (strict and permissive), parent-state handling, and adversarial cases (large numbers, surrogate pairs, deeply nested structures).

Conventions The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. All canonical byte sequences in this document are presented as UTF-8 text. All hash and signature outputs are presented in lowercase hexadecimal unless explicitly stated otherwise.

Canonicalization Vectors (RFC 8785 JCS) These vectors verify that an implementation's canonicalizer matches RFC 8785 JSON Canonicalization Scheme . They are intentionally minimal so that any conformant JCS implementation produces identical output.

Vector C1 -- empty object Input: Canonical bytes (UTF-8): Length: 2 bytes.

Vector C2 -- object with key reordering Input: Canonical bytes (UTF-8): Length: 13 bytes.

Vector C3 -- null-valued field omission per ATP Section 9 Input: Canonical bytes (UTF-8) per ATP Section 9 (null fields omitted): Length: 7 bytes. Note: Strict RFC 8785 JCS would preserve "b":null. ATP Section 9 modifies this rule and requires null-valued fields to be omitted. Profiles MAY override the omission rule per Section 9.

Vector C4 -- array order preservation Input: Canonical bytes (UTF-8): Array order MUST be preserved as declared.

Vector C5 -- nested object key sorting Input: Canonical bytes (UTF-8): Both top-level and nested keys MUST be sorted.

nodeId Computation Vectors These vectors verify the full nodeId formula: Each vector presents a node, the exact canonical bytes produced by ATP Section 9 + RFC 8785 JCS, and the resulting SHA-256 hash in lowercase hex. The signature field is intentionally absent from the input -- implementations MUST exclude it from canonicalization per Section 10.1.

Vector V1 -- minimum-viable request node Input node (no actor, no profile, no outputHash, empty parents -- represents an autonomous root request): Canonical bytes (UTF-8): Expected nodeId:

Vector V2 -- completion node with actor and parent reference Input node (completion of V1, actor present, references V1 as parent): Canonical bytes (UTF-8): Expected nodeId:

Vector V3 -- same content as V1 with mis-ordered keys This vector verifies that canonicalization produces identical output regardless of input key order. Implementations MUST produce the same canonical bytes and the same nodeId for V3 as for V1. Input node (logically equivalent to V1, all keys in reverse-ish order): Canonical bytes (UTF-8): Expected nodeId: (Identical to V1; this is the conformance signal.)

Vector V4 -- fan-in decision with two parents Input node (decision synthesis with parents=[V1, V2], signed by a different issuer): Canonical bytes (UTF-8): Expected nodeId: Parent array order is canonicalization-significant per Section 8: V1 before V2 produces a different nodeId than V2 before V1 would. Implementations MUST preserve declared parent order.

Vector V5 -- node with profile field This vector verifies that the profile field participates in canonicalization and nodeId computation per Section 10.1 and Section 20.4. Input node: Canonical bytes (UTF-8): Expected nodeId: If an implementation produces a different nodeId for V5, the most likely cause is that the profile field has been excluded from canonicalization. ATP Section 10.1 requires it to be included whenever present.

Ed25519 Signature Vector This section publishes one Ed25519 sign/verify vector using deterministic key material. ATP Section 10.3 requires that the signature be computed over the nodeId, which is a 32-byte SHA-256 output.

Test Key Material The vectors in this document use a fixed Ed25519 keypair derived from a deterministic 32-byte seed. Implementations MUST use the same seed to reproduce these vectors. This key material is for test use only and MUST NOT be used in production deployments.

Field	Value
Seed (32 bytes, hex)	`aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa`
Public key (raw, 32 bytes, hex)	`e734ea6c2b6257de72355e472aa05a4c487e6b463c029ed306df2f01b5636b58`
Public key (raw, 32 bytes, base64)	`5zTqbCtiV95yNV5HKqBaTEh+a0Y8Ap7TBt8vAbVja1g=`

The seed is the Ed25519 private-key seed per . Implementations using PKCS#8 or other encodings MUST derive the equivalent raw seed before applying the test.

Vector S1 -- sign V1's nodeId Sign the V1 nodeId (Section 4.1) as the message. ATP Section 10.3 specifies that the signature input is the nodeId value treated as 32 bytes -- that is, bytes.fromhex(nodeId), not the hex string itself.

Field	Value
Message (hex, 32 bytes)	`77d803c2d67e6cbe893172e5676e52b8f1bb80910bcbe1ca4c9aa5273f46ce70`
Signature (hex, 64 bytes)	`3f4d9fb756aba9bca11cfac15d65d82441dbf6f69adc9ba527b506c3379855500a2ef1a4e471323f2e8c8d190868e4f5ef303bef1e3e57e1988b1b46d83d5509`
Signature (base64)	`P02ft1arqbyhHPrBXWXYJEHb9vaa3JulJ7UGwzeYVVAKLvGk5HEyPy6MjRkIaOT17zA77x4+V+GYixtG2D1VCQ==`

A conformant implementation MUST:

Reproduce the public key bytes from the seed.
Reproduce the signature bytes from the seed and message.
Verify the signature against the public key and message and return success.
Reject the signature if any byte of the message, signature, or public key is altered.

Ed25519 is deterministic per Section 5.1.6: signing the same message under the same key MUST produce the same signature bytes. Implementations that produce different signature bytes for this vector are not interoperable with .

Implementation Notes

Canonicalization Edge Cases Not Covered in -00 This release deliberately uses simple JSON values (strings, integers, arrays of strings, plain objects) that all conformant RFC 8785 implementations handle identically. The following edge cases are not covered in -00 and will be added in subsequent revisions:

Floating-point and exponent-form numbers (RFC 8785's ECMAScript number serialization rules).
Unicode surrogate-pair handling and codepoints in the supplementary planes.
Strings containing escapes for control characters not in the basic ASCII range.
Very large nested structures (depth > 16, breadth > 256 keys).
Empty arrays and empty strings as values.

Implementations passing the -00 vectors satisfy the floor for ATP Core conformance per Section 13.7. Implementations claiming broader RFC 8785 conformance SHOULD additionally pass the test data published by .

Canonicalization Library Choices Implementations MAY use any RFC 8785 conformant canonicalization library. The reference implementation by the RFC 8785 author is available in multiple languages at and provides additional test data covering the edge cases listed above. ATP Core does not endorse a specific implementation. The deterministic-output guarantee of Section 9 makes the choice immaterial provided the chosen library is RFC 8785 conformant.

Reproducing the Vectors The vectors in this document are reproducible from the inputs shown. A conformant implementation given the same input MUST produce the canonical bytes and nodeId exactly as recorded. The Python script that generated these vectors is available alongside the published draft for cross-checking.

Security Considerations The test key material in Section 5.1 is deterministic and public. It MUST NOT be used to sign production ATP nodes. Doing so would expose those nodes to forgery by anyone who has read this document. These vectors are integrity tests, not security tests. Passing them confirms that an implementation produces correct deterministic output for the inputs shown. It does not, by itself, establish that the implementation is free of cryptographic implementation bugs that would only manifest on different inputs (timing side channels in Ed25519 signing, malleability in canonicalizer parsing, hash-truncation bugs in nodeId computation, and similar). Implementations SHOULD additionally adopt the security practices recommended by the underlying primitive specifications .

IANA Considerations This document has no IANA actions.