signal@humanjudgment.org https://github.com/hjs-spec

JEP conformance validation test vectors This document defines conformance classes, validation-result structure, schema requirements, test-vector categories, reference-validator behavior, and implementation testing guidance for the Judgment Event Protocol (JEP). It is a companion to . This document does not redefine JEP-Core semantics. Its purpose is to make JEP-Core 0.7 implementations testable and interoperable across languages, platforms, trust profiles, and deployment environments.

Introduction JEP-Core defines the signed event object, J/D/T/V event semantics, stable Event Identity, Event Hash semantics, validation modes, independent validation checks, and idempotent acceptance requirements. This document defines how implementations demonstrate conformance to those requirements. It replaces the level-oriented conformance model used by draft-wang-jep-conformance-00 with the independent-check model defined by JEP-Core 0.7. Conformance does not mean that an implementation has made a legal, policy, factual, authorization, causal, or external-target determination. It means that the implementation processes JEP events according to the declared JEP-Core version, validation mode, conformance class, and active profiles. Where this document and JEP-Core conflict, JEP-Core controls.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 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.

Conformance Model

Independent Checks JEP-Core 0.7 does not define cumulative validation levels. A conforming validator reports independent checks. Core-defined checks are:

• syntax
• cryptographic
• event_identity
• reference_integrity
• extension_processing

Trust- or acceptance-profile checks include:

• actor_binding
• freshness
• audience

Companion or external checks include:

• chain_integrity
• policy

A check status is one of:

• pass
• fail
• not_checked
• not_applicable
• unsupported
• indeterminate

An implementation MUST NOT report an unperformed check as pass.

Overall Status For the requested validation mode and profile, the overall status is one of:

• valid
• invalid
• indeterminate

valid means that all required checks passed or were not applicable. invalid means that at least one required check failed. indeterminate means that no required check failed but at least one required check is unsupported or indeterminate.

Validation Modes The initial validation modes are:

• archival
• acceptance
• chain
• policy

Archival validation is repeatable and MUST NOT consume acceptance state. Acceptance validation includes JEP-Core Event Identity and idempotent acceptance semantics plus any profile-required actor-binding, freshness, audience, or challenge checks. Chain and policy modes invoke companion or external semantics. A Core implementation MUST NOT present a chain or policy result as an intrinsic JEP-Core property.

Conformance Classes

JEP-Core-0.7 Producer A producer conforms to JEP-Core-0.7 Producer if it supports:

• I-JSON-compatible event construction as defined by RFC 7493 ;
• a stable id for each event instance;
• all required top-level Core members;
• J/D/T/V verb-specific Core requirements;
• JCS canonicalization of the unsigned event as defined by RFC 8785 ;
• signature generation under at least one declared signature conformance class;
• algorithm-tagged digest strings;
• ext and ext_crit semantics.

A conforming producer MUST NOT reuse one Event Identity (who,id) for different unsigned event content.

JEP-Core-0.7 Verifier A verifier conforms to JEP-Core-0.7 Verifier if it supports:

• duplicate JSON member rejection;
• Core field and verb-specific validation;
• Event Identity validation;
• JCS canonicalization as defined by RFC 8785 ;
• signature verification under at least one declared signature conformance class, using RFC 7515 where that class is JWS-based;
• Event Hash calculation;
• independent validation checks;
• structured validation-result objects;
• unknown critical-extension rejection;
• archival validation mode.

A Core verifier MUST NOT require an optional identity, credential, attestation, blockchain, AI-platform, agent-framework, challenge, transport, chain, or policy profile.

JEP-Core-0.7 Acceptance Processor An implementation claiming JEP-Core-0.7 Acceptance Processor conformance MUST additionally support:

• a stable acceptance-domain definition;
• detection of conflicting Event Identity reuse;
• sufficient acceptance state for the claimed acceptance lifetime;
• atomic or equivalent first-acceptance processing;
• accepted, already_accepted, rejected, and indeterminate outcomes;
• separation of repeated valid delivery from invalid event content.

The same Event Identity MUST NOT apply the same acceptance effect more than once within one acceptance domain.

JEP-Extension-0.7 Processor An extension processor conforms to JEP-Extension-0.7 Processor if it can:

• locate extension objects under ext;
• process identifiers named by ext_crit;
• fail extension_processing for unknown critical extensions;
• ignore unknown non-critical extensions where permitted;
• detect conflicting critical extensions;
• preserve JEP-Core member semantics.

JEP-Baseline-Ed25519-JWS-JCS-0.7 This document defines an interoperable baseline conformance class named JEP-Baseline-Ed25519-JWS-JCS-0.7. It requires:

• I-JSON-compatible JSON as defined by RFC 7493 ;
• RFC 8785 JCS canonicalization ;
• detached JWS Compact Serialization as defined by RFC 7515 ;
• the fully specified JOSE alg value Ed25519 defined by RFC 9864 ;
• Ed25519 signature processing as defined by RFC 8032 ;
• algorithm-tagged sha256 digest strings;
• Event Hash calculation over the full signed event object including sig.

For this baseline, the JWS Payload is exactly the JEP Signing Payload: the UTF-8 octets of the RFC 8785 JCS-canonicalized unsigned event. The protected JOSE header MUST contain: A kid parameter MAY be present. If present, kid MUST be carried in the protected header. Additional protected parameters MAY be present when allowed by the active trust profile. A verifier MUST process every critical JOSE header parameter that it is required to understand under RFC 7515. This baseline uses the ordinary base64url-encoded JWS Payload semantics of RFC 7515. Producers MUST NOT use b64:false for this conformance class. The JWS Signing Input is exactly: The top-level JEP sig member MUST contain the detached JWS Compact Serialization form: The middle payload segment is empty only in the transmitted detached serialization. During verification, the verifier reconstructs the signing input using the exact JEP Signing Payload. Base64url segments MUST use the RFC 7515 encoding rules, including omission of = padding and absence of whitespace. The JWS Compact Serialization has no unprotected JOSE header. This baseline therefore does not permit security-relevant signature parameters to be carried outside the protected header. Conformance vectors for this baseline MUST publish:

• the complete unsigned event;
• the exact JEP Signing Payload bytes, encoded in a transport-safe form;
• the protected-header JSON;
• the protected-header base64url segment;
• the detached sig string;
• the resulting full signed event;
• the Event Hash;
• the expected validation result.

A producer is not required to serialize semantically equivalent protected header JSON into identical bytes outside a vector that explicitly claims byte-for-byte reproduction. A verifier MUST verify the exact protected-header segment carried by the JWS. This baseline is a conformance-class requirement, not a restriction on JEP-Core algorithm agility.

Profile-Specific Conformance A profile MAY define additional conformance classes. Such classes MUST state:

• which validation checks are required;
• which checks are optional;
• which identifiers, credentials, or evidence are required;
• which algorithms are accepted or prohibited;
• whether freshness, audience, challenge-response, nonce, counter, sequence, ledger, or other replay-related mechanisms are required;
• how unsupported or indeterminate evidence is reported;
• any acceptance-domain requirements.

Profiles MUST NOT redefine JEP-Core Event Identity, Event Hash, J/D/T/V, signing-payload, or Core check semantics.

Historical Decoder Capability Support for pre--07 JEP draft encodings is OPTIONAL and is not part of JEP-Core-0.7 conformance. An implementation advertising a historical decoder MUST name that decoder explicitly. It MUST NOT select a historical decoder by first failing JEP-Core 0.7 validation and then inferring an older draft format solely from field presence. Historical signed events MUST NOT be rewritten or silently upgraded.

Validation Result Object A conforming verifier SHOULD return a structured validation result.

Valid Archival Example

Safe Retry Example

Signature Failure Example

Result Requirements A conformance result object MUST distinguish:

• overall status;
• requested mode;
• active profile;
• Event Identity when available;
• Event Hash when calculated;
• independent checks;
• acceptance outcome when acceptance mode is requested;
• warnings;
• errors.

The event_identity member reports the (who,id) values asserted by the parsed event. Its presence in a result does not by itself establish signature validity, actor binding, authority, freshness, or non-conflicting historical use of that Event Identity. The event_identity check reports only the JEP-Core Event Identity checks actually performed, including conflicting reuse detection when identity state is available. It MUST NOT be used as a substitute for cryptographic or actor_binding. Similarly, an event_hash member reports the digest calculated for an exact signed artifact. Its presence does not establish actor binding, substantive truth, authorization, policy acceptance, or external effect. An error object SHOULD contain a JEP failure code, the associated check when applicable, and an explanatory message. A result MUST NOT contain a cumulative validation level.

Acceptance Outcome Consistency When mode is acceptance, the result MUST contain an acceptance object once the acceptance processor has produced an outcome. The outcome and overall status MUST be consistent as follows:

Acceptance outcome	Overall status	effect_applied
accepted	valid	true
already_accepted	valid	false
rejected	invalid	false
indeterminate	indeterminate	false

accepted means all checks required by the active acceptance context passed or were not applicable and the acceptance effect is applied for the first time. already_accepted means the event is valid for the active acceptance context but the same Event Identity has already applied that effect in the same acceptance domain. rejected means at least one required validation check failed. indeterminate means no required validation check failed, but the acceptance processor could not complete a required determination because required evidence, implementation support, durable state, or atomicity guarantees were unavailable. effect_applied MUST be true only for accepted. A verifier MUST NOT report already_accepted as a cryptographic or syntax failure. For non-acceptance modes, the acceptance member SHOULD be absent unless a companion result format explicitly carries a separately labeled acceptance observation.

JSON Schema Requirements The conformance suite SHOULD provide:

• jep-event-0.7.schema.json
• jep-ref-0.7.schema.json
• jep-extension-0.7.schema.json
• jep-validation-result-0.7.schema.json
• schemas for any baseline signature or profile objects defined by the suite

JSON Schema validation does not prove cryptographic validity, actor binding, freshness, reference resolution, policy compliance, or external truth. Duplicate-member rejection occurs before ordinary parsed-object schema validation.

Minimal Event Schema Seed The following schema is a structural seed. It intentionally does not attempt to encode every JEP semantic rule. The schema does not make nonce a Core field. A nonce or equivalent mechanism MAY appear inside a registered extension or profile-defined object.

Typed JEP Event Reference Seed A logical JEP event reference SHOULD use Event Identity: An exact signed artifact MAY additionally be pinned: The value identifies the logical event. The optional hash identifies an exact signed artifact.

Reference Validation Flow A reference validator SHOULD process an event in the following order: An implementation MUST perform cryptographic validation before writing new authoritative Event Identity or acceptance state for untrusted input. When the active acceptance profile requires actor binding, an implementation MUST NOT commit authoritative Event Identity or acceptance state until actor_binding has passed. A verifier MUST NOT treat a transport retry as creation of a new event.

Test Vector Categories

Valid Core Event Vectors The suite SHOULD include:

• valid/J-basic.json
• valid/D-basic.json
• valid/T-basic.json
• valid/V-basic.json
• valid/event-reference-logical.json
• valid/event-reference-exact-artifact.json

Syntax and Core-Field Vectors The suite SHOULD include:

• invalid/invalid-json.json
• invalid/duplicate-member.json
• invalid/missing-id.json
• invalid/invalid-id.json
• invalid/missing-what.json
• invalid/unknown-verb.json
• invalid/invalid-timestamp.json
• invalid/D-missing-delegatee.json
• invalid/D-missing-scope.json
• invalid/T-missing-ref.json
• invalid/T-missing-termination-scope.json
• invalid/V-missing-ref.json
• invalid/V-missing-verification-scope.json
• invalid/V-missing-result.json

Cryptographic Vectors The suite SHOULD include:

• invalid/invalid-signature.json
• invalid/signature-over-wrong-payload.json
• invalid/unsupported-signature-alg.json
• invalid/prohibited-signature-alg.json
• invalid/alg-key-type-mismatch.json
• invalid/alg-profile-mismatch.json
• invalid/canonicalization-failed.json
• invalid/canonicalization-version-unsupported.json

Event Identity and Delivery Vectors Event Identity behavior is stateful. A single isolated JSON event cannot by itself demonstrate conflicting reuse or prior acceptance. The suite SHOULD therefore include stateful sequence manifests such as:

• stateful/event-identity-retransmission.json
• stateful/event-identity-resign-same-content.json
• stateful/event-id-conflict.json
• stateful/same-id-different-who.json

A stateful manifest SHOULD declare the identity or acceptance state visible to the harness, the ordered steps, and the expected result for each step. Example: The second event in the example uses the same (who,id) but different JCS-canonicalized unsigned event content. The suite SHOULD also verify:

• retransmission of byte-identical signed content;
• re-signing of identical unsigned content with the same Event Identity;
• use of the same id string under a different who;
• conflicting reuse of one Event Identity with different unsigned content.

Conflicting reuse MUST produce ERR_EVENT_ID_CONFLICT. A valid repeated event MUST NOT be reported as a cryptographic failure.

Acceptance Vectors Acceptance behavior is also stateful. The suite SHOULD include:

• stateful/accept-first.json
• stateful/accept-safe-retry.json
• stateful/accept-state-unavailable.json
• stateful/accept-atomicity-unavailable.json
• a concurrent first-delivery test

A safe-retry sequence SHOULD demonstrate that the first valid delivery yields accepted with effect_applied: true and a later valid delivery of the same Event Identity in the same acceptance domain yields already_accepted with effect_applied: false. If required acceptance state is unavailable, the result MUST NOT claim a fresh accepted outcome. It MUST be indeterminate or rejected when an active profile explicitly requires fail-closed rejection. If required atomicity cannot be provided, the implementation MUST NOT claim accepted. When represented as a JEP failure code, the suite SHOULD exercise ERR_ACCEPTANCE_ATOMICITY_UNAVAILABLE. The concurrent first-delivery test SHOULD submit multiple equivalent deliveries of the same Event Identity against one acceptance domain and assert that exactly one state-changing acceptance effect is applied. All other valid deliveries MUST be reported without a second effect, normally as already_accepted. Nonce, challenge, sequence-number, counter, ledger, or similar replay tests belong to the profile that requires that mechanism and MUST NOT be presented as universal JEP-Core requirements.

Reference Vectors The suite SHOULD include:

• logical Event Identity resolution;
• exact-artifact hash success;
• exact-artifact hash mismatch;
• Event Identity mismatch;
• unresolved references when a requested check requires resolution.

Extension Vectors The suite SHOULD include:

• known critical extension success;
• unknown critical extension failure;
• unknown non-critical extension tolerance;
• extension schema failure;
• conflicting critical extensions.

Canonicalization and Hash Vectors The suite SHOULD include:

• equivalent JSON inputs producing identical JCS bytes;
• UTF-16 property-order edge cases required by JCS;
• numeric serialization edge cases allowed by I-JSON/JCS;
• full signed Event Hash calculation;
• unsigned JEP Signing Payload calculation;
• proof that changing sig can change Event Hash without changing Event Identity.

Companion and External Check Vectors Chain and policy fixtures MAY be included for integration testing, but they MUST identify the companion profile or external evaluator that owns the semantics. They MUST NOT be labeled as Core-only conformance failures.

Historical Compatibility Vectors If a product advertises a historical pre--07 decoder, the suite SHOULD include:

• explicit historical decoder selection;
• historical signature verification without rewriting bytes;
• refusal to silently fall back from 0.7 based solely on field presence.

Seed J/D/T/V Event Shapes The following examples use placeholder signatures.

J-basic

D-basic

T-basic

V-basic

Conformance Test Assertions A stateless test assertion SHOULD name:

• input event;
• requested validation mode;
• active profile;
• expected overall status;
• expected independent checks;
• expected warnings and errors;
• expected Event Hash when applicable.

Example: A stateful test MUST declare the state scope and ordered operations required to obtain the expected result. It SHOULD use a steps array rather than imply state through a filename. Example safe retry: A concurrency assertion SHOULD additionally declare the number of concurrent deliveries and MUST assert the number of state-changing effects observed by the harness. Test assertions MUST NOT use expected_level for JEP-Core 0.7. A conformance harness MUST distinguish:

• validation output returned by the verifier;
• state supplied to the verifier;
• state committed by the acceptance processor;
• externally observed effect count used to test atomicity.

This distinction prevents a test harness from reporting at-most-once acceptance merely because it deduplicated test inputs before invoking the implementation under test.

Reference CLI Behavior A reference implementation SHOULD provide equivalent operations to: A chain-specific command MAY be provided by a JAC-like companion validator. Its result MUST remain distinguishable from JEP-Core validation. CLI output SHOULD use the structured result object defined in this document.

Implementation Disclosure and Interoperability Reports A conforming implementation SHOULD document:

• supported JEP-Core release;
• supported conformance classes;
• supported validation modes;
• supported independent checks;
• supported signature algorithms and canonicalization rules;
• supported hash algorithms;
• supported trust and acceptance profiles;
• supported extensions;
• acceptance-state durability and atomicity assumptions;
• historical decoder capabilities, if any;
• test-vector results.

An interoperability report MAY use: A report MUST NOT imply support for checks, profiles, or modes that were not actually exercised.

Security Considerations A conformance suite can detect specified classes of implementation divergence but cannot prove deployment security. Implementations MUST verify untrusted cryptographic input before committing authoritative Event Identity or acceptance state. When actor binding is required for acceptance, actor binding MUST pass before such state is committed. Acceptance processors MUST provide atomic or equivalent concurrency guarantees for first acceptance. A check-then-apply-then-mark sequence that can race is non-conforming. Acceptance-state retention MUST be sufficient for the period during which an event remains eligible to produce the protected effect. Event IDs are not secrets, bearer tokens, authorization grants, or freshness proofs. A valid signature does not prevent repeated delivery. Deployments requiring current liveness, strict ordering, server challenge freshness, or single-use authority SHOULD use an appropriate profile mechanism in addition to JEP-Core. Implementations MUST reject algorithms prohibited by the active profile and MUST NOT silently downgrade to weaker algorithms. Test keys and test credentials MUST NOT be used in production.

Privacy Considerations Test vectors SHOULD use synthetic identifiers and non-sensitive claims. Event IDs, Event Hashes, actor identifiers, references, and validation reports can enable correlation. Conformance fixtures SHOULD avoid unnecessary stable real-world identifiers. Exact-artifact hashes may permit correlation or confirmation attacks. Sensitive evidence SHOULD be represented using profile-appropriate privacy mechanisms rather than copied into public conformance vectors. Conformance reports SHOULD disclose only the implementation metadata required to establish interoperability claims.

Versioning and Historical Compatibility The conformance suite MAY version its executable artifacts independently from the Internet-Draft revision. Artifacts claiming JEP-Core 0.7 conformance MUST use the JEP-Core 0.7 event model and result model defined by this document and the companion Core draft. The wire major remains jep: "1" for JEP-Core 0.7. Pre--07 Internet-Draft encodings that also used jep: "1" are historical draft artifacts and MUST NOT be selected by heuristic fallback. A future Core revision that changes stable Event Identity, signing-input, canonicalization, or required Core-field semantics after real-world wire adoption may require a new wire major as specified by JEP-Core.

Changes from -00 Major changes from draft-wang-jep-conformance-00:

• aligned the companion specification with JEP-Core 0.7;
• added required Event ID and Event Identity conformance;
• removed Core nonce-generation and nonce-replay requirements;
• replaced cumulative validation levels with independent validation checks;
• replaced boolean-only validity with valid, invalid, and indeterminate;
• added accepted, already_accepted, rejected, and indeterminate acceptance outcomes;
• added acceptance-state lifetime and atomicity conformance;
• separated logical Event Identity from exact signed-artifact Event Hash;
• updated reference vectors to typed Event Identity references with optional artifact hashes;
• moved chain, cascade, cycle, and policy semantics out of Core conformance;
• tightened D/T/V minimum structural requirements;
• added Event Identity conflict vectors and safe-retry vectors;
• made nonce, challenge, sequence, counter, and ledger replay tests profile-specific;
• added explicit historical-decoder and no-heuristic-fallback tests;
• updated the baseline JOSE algorithm identifier to fully specified Ed25519;
• removed expected_level from test assertions and interoperability reports.
• fully specified the detached JWS Compact Serialization baseline, including protected-header, signing-input, base64url, and detached sig rules;
• clarified that reported Event Identity and Event Hash values are not by themselves validation conclusions;
• defined deterministic consistency rules between overall validation status and acceptance outcome;
• made Event Identity conflict, safe retry, and atomicity fixtures explicitly stateful or concurrent.

IANA Considerations This document requests no IANA actions.

Author's Address Yuqiang Wang Email: signal@humanjudgment.org URI: https://github.com/hjs-spec

References Normative References