Network Working Group Y. Wang Internet-Draft Independent Intended status: Experimental Expires: November 5, 2026 May 4, 2026 JEP Conformance and Test Suite draft-wang-jep-conformance-00 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 5, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1 Introduction 2 Conformance Classes 3 Validation Result Schema 4 JSON Schema Requirements 5 Reference Validation Flow 6 Test Vector Categories 7 Seed Event Examples 8 Conformance Test Assertions 9 Reference CLI Behavior 10 Implementation Requirements 11 Interoperability Report Format 12 Security Considerations 13 Privacy Considerations 14 Versioning 15 Initial Repository Layout 16 Author's Address 17 Engineering-Complete Seed Package 18 Local CI and Test Harness 19 Expanded Validation Artifacts JEP Conformance and Test Suite Schemas, Validation Results, Test Vectors, and Reference Validator Behavior draft-wang-jep-conformance-00 Author: Yuqiang Wang Intended status: Experimental Companion draft: draft-wang-jep-judgment-event-protocol-06 --- Abstract 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 draft-wang-jep-judgment-event-protocol-06. The purpose of this document is to make JEP implementations testable, interoperable, and auditable across languages, platforms, identity systems, and deployment profiles. --- 1. Introduction JEP-Core defines event semantics and validation rules. Profiles define optional interoperability bindings. This document defines how implementations demonstrate conformance. Conformance does not mean that an implementation has made any legal, policy, factual, or external-target determination. Conformance means that the implementation processes JEP events according to the declared JEP-Core version, conformance class, validation mode, and profile set. --- 2. Conformance Classes 2.1 JEP-Core-0.6 Producer A producer conforms to JEP-Core-0.6 Producer if it can generate: - I-JSON-compatible JEP events; - required top-level fields; - valid J/D/T/V verb-specific structures; - UUIDv4 or profile-accepted nonce values; - algorithm-tagged digest strings; - detached signatures over JCS-canonicalized unsigned payloads; - ext and ext_crit according to extension rules. 2.2 JEP-Core-0.6 Verifier A verifier conforms to JEP-Core-0.6 Verifier if it can perform: - duplicate member rejection; - field-shape validation; - JCS canonicalization; - detached JWS verification under the required conformance algorithm set; - event hash calculation; - validation-level reporting; - failure-code reporting; - critical extension processing; - acceptance validation; - archival validation. 2.3 JEP-Core-0.6 Archive Verifier An archive verifier supports archival validation and MUST NOT reject events solely because when is outside the current freshness window. 2.4 JEP-Chain-0.6 Verifier A chain verifier supports reference resolution, event-hash checks, termination effects, cycle detection, and observed-log assumption reporting. 2.5 JEP-Extension-0.6 Processor An extension processor can process registered extensions, reject unknown critical extensions, and detect critical extension conflicts. 2.6 JEP-Baseline-Ed25519-JWS-JCS-0.6 For compatibility with the -05 interoperability baseline, this conformance class requires support for: - I-JSON-compatible JSON; - JCS canonicalization; - detached JWS Compact Serialization for single signatures; - JOSE alg value Ed25519; - algorithm-tagged sha256 digest strings; - UUIDv4 nonce syntax; - event hash calculation over the full signed event object. This conformance class does not make Ed25519 the only algorithm allowed by JEP-Core semantics. It defines one interoperable baseline. 2.7 Profile-Specific Conformance Profile-specific conformance is defined by the relevant profile draft, for example DID/VC, X.509, OAuth/OIDC, RATS, HJS Archive, or JAC Chain. --- 3. Validation Result Schema A validation result object SHOULD include: { "valid": true, "level": 3, "mode": "archival", "profile": "jep-core-0.6", "conformance_class": "JEP-Core-0.6 Verifier", "scopes": ["syntax", "cryptographic", "actor_binding", "chain_integrity"], "event_hash": "sha256:...", "warnings": [], "errors": [] } 3.1 Required Fields - valid: boolean - level: integer from 0 to 4 - mode: string - profile: string - warnings: array - errors: array 3.2 Error Object { "code": "ERR_REF_HASH_MISMATCH", "message": "The referenced event hash does not match the canonical payload.", "level": 3, "recoverable": false, "evidence": ["event_003", "event_007"] } 3.3 Warning Object { "code": "WARN_ARCHIVAL_ONLY_ALGORITHM", "message": "The signature algorithm is acceptable for archival validation but prohibited for new events.", "level": 1 } --- 4. JSON Schema Requirements The conformance suite SHOULD provide schemas for: - jep-event.schema.json - jep-ref.schema.json - jep-extension.schema.json - jep-signature.schema.json - jep-profile.schema.json - jep-validation-result.schema.json Schemas MUST NOT attempt to prove cryptographic validity. Schemas only validate structural and data-shape requirements. 4.1 Minimal jep-event.schema.json Seed The following minimal schema is a seed schema for structural validation. It is not a substitute for cryptographic verification, trust-profile evaluation, extension processing, or policy validation. { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://jep.org/schemas/jep-event-0.6.schema.json", "title": "JEP Event", "type": "object", "additionalProperties": false, "required": ["jep", "verb", "who", "when", "nonce", "sig"], "properties": { "jep": { "type": "string", "const": "1" }, "verb": { "type": "string", "enum": ["J", "D", "T", "V"] }, "who": { "type": "string", "minLength": 1 }, "when": { "type": "integer" }, "what": { "oneOf": [ { "type": "string", "pattern": "^[a-z0-9-]+:[0-9a-f]+$" }, { "type": "object" }, { "type": "null" } ] }, "nonce": { "type": "string", "format": "uuid" }, "aud": { "type": "string" }, "ref": { "oneOf": [ { "type": "string", "pattern": "^[a-z0-9-]+:[0-9a-f]+$" }, { "type": "object" }, { "type": "null" } ] }, "ext": { "type": "object" }, "ext_crit": { "type": "array", "items": { "type": "string" }, "uniqueItems": true }, "sig": { "oneOf": [ { "type": "string" }, { "type": "object" } ] } } } --- 5. Reference Validation Flow A reference validator SHOULD implement the following pseudo-code: validate_event(event, mode, trust_profile, expected_audience=None): parse JSON reject duplicate member names validate core field presence and types validate verb-specific requirements unsigned = event without sig canonical = JCS(unsigned) verify detached signature over canonical event_hash = hash(JCS(event including sig)) resolve actor/key using trust_profile verify key bound to who if mode == acceptance: verify nonce freshness and replay cache verify timestamp window verify audience if expected validate ref syntax and resolve if available process all ext_crit extensions apply chain rules if requested apply policy rules if requested return validation_result A validator MUST NOT return Level 4 unless an applicable policy profile has actually been evaluated. --- 6. Test Vector Categories 6.1 Valid Core Vectors The conformance suite SHOULD include: - valid/J-basic.json - valid/D-basic.json - valid/T-basic.json - valid/V-basic.json - valid/delegation-chain-valid.jsonl - valid/verification-scope-valid.json - valid/archive-validation-valid.json 6.2 Invalid Syntax Vectors - invalid/invalid-json.json - invalid/duplicate-member.json - invalid/missing-required-field.json - invalid/unknown-verb.json - invalid/invalid-timestamp.json 6.3 Invalid Cryptographic Vectors - invalid/invalid-signature.json - invalid/signature-over-wrong-payload.json - invalid/ref-hash-mismatch.json - invalid/unsupported-signature-alg.json - invalid/prohibited-signature-alg.json - invalid/alg-key-type-mismatch.json - invalid/canonicalization-version-unsupported.json 6.4 Invalid Replay and Freshness Vectors - invalid/nonce-replay.json - invalid/timestamp-out-of-window.json - invalid/event-expired.json 6.5 Invalid Chain Vectors - invalid/chain-broken.json - invalid/cycle-detected.json - invalid/terminated-delegation-reused.json - invalid/delegation-scope-exceeded.json - invalid/complete-log-assumption-unsatisfied.json 6.6 Invalid Extension Vectors - invalid/unknown-critical-extension.json - invalid/extension-schema-invalid.json - invalid/extension-conflict.json - invalid/verification-scope-overclaim.json 6.7 Canonicalization Vectors - canonicalization/jcs-equivalent-payloads.json - canonicalization/jcs-invalid-normalization.json - canonicalization/full-signed-event-hash.json - canonicalization/unsigned-signing-payload.json 6.8 Profile Vectors - profiles/did-vc-valid.json - profiles/did-vc-expired-credential.json - profiles/x509-valid.json - profiles/oauth-context-valid.json - profiles/rats-attestation-valid.json - profiles/hjs-archive-reference-valid.json - profiles/jac-chain-valid.json 6.9 Signed Baseline Vectors The repository form of this conformance suite SHOULD include signed Ed25519/JWS/JCS baseline vectors: - valid/J-basic-signed.json - valid/D-basic-signed.json - valid/T-basic-signed.json - valid/V-basic-signed.json - valid/delegation-verification-termination-chain.jsonl - valid/public-keys.json Each signed vector SHOULD include: - full signed event; - canonical unsigned payload; - event hash; - expected validation result. --- 7. Seed Event Examples 7.1 Unsigned Judgment Event { "jep": "1", "verb": "J", "who": "did:example:agent-789", "when": 1742345678, "what": "sha256:aa55ad4393538f14e6b4961de1a29216eed93517cb6c2631a56a5ee75edb3b7a", "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "aud": "https://platform.example.com", "ref": null } 7.2 Validation Result for Signature Failure { "valid": false, "level": 0, "mode": "acceptance", "profile": "jep-core-0.6", "scopes": ["syntax"], "event_hash": null, "warnings": [], "errors": [ { "code": "ERR_SIGNATURE_INVALID", "message": "The detached JWS signature does not verify over the JCS-canonicalized unsigned payload.", "level": 1, "recoverable": false } ] } 7.3 Validation Result for Policy Failure { "valid": false, "level": 3, "mode": "policy", "profile": "jep-core-0.6+local-policy", "scopes": ["syntax", "cryptographic", "actor_binding", "chain_integrity"], "event_hash": "sha256:...", "warnings": [], "errors": [ { "code": "ERR_POLICY_REJECTED", "message": "The event is cryptographically and chain-valid but rejected by local policy.", "level": 4, "recoverable": true } ] } 7.4 Seed J/D/T/V Event Shapes The following seed vectors define minimal event shapes. Signatures are placeholder values and are not intended to be cryptographically valid unless replaced by generated detached JWS values in a conformance suite. 7.4.1 J-basic { "jep": "1", "verb": "J", "who": "did:example:agent-789", "when": 1742345678, "what": "sha256:aa55ad4393538f14e6b4961de1a29216eed93517cb6c2631a56a5ee75edb3b7a", "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "aud": "https://platform.example.com", "ref": null, "sig": "PLACEHOLDER_DETACHED_JWS" } 7.4.2 D-basic { "jep": "1", "verb": "D", "who": "did:example:human-123", "when": 1742345681, "what": { "claim": "delegate", "delegatee": "did:example:agent-789", "scope": "summarize-document", "constraints": ["no-external-send"], "context": "sha256:1111111111111111111111111111111111111111111111111111111111111111" }, "nonce": "2b8c7d6e-1111-4abc-9def-123456789abc", "aud": "https://platform.example.com", "ref": "sha256:2222222222222222222222222222222222222222222222222222222222222222", "sig": "PLACEHOLDER_DETACHED_JWS" } 7.4.3 T-basic { "jep": "1", "verb": "T", "who": "did:example:human-123", "when": 1742345690, "what": { "claim": "terminate", "target": "sha256:3333333333333333333333333333333333333333333333333333333333333333", "termination_scope": "delegation" }, "nonce": "3c9d8e7f-2222-4abc-9def-123456789abc", "aud": "https://platform.example.com", "ref": "sha256:3333333333333333333333333333333333333333333333333333333333333333", "sig": "PLACEHOLDER_DETACHED_JWS" } 7.4.4 V-basic { "jep": "1", "verb": "V", "who": "did:example:verifier-123", "when": 1742345700, "what": { "claim": "verified", "verification_scope": ["syntax", "cryptographic", "actor_binding"], "result": "pass" }, "nonce": "4d0e9f80-3333-4abc-9def-123456789abc", "aud": "https://platform.example.com", "ref": "sha256:4444444444444444444444444444444444444444444444444444444444444444", "sig": "PLACEHOLDER_DETACHED_JWS" } --- 8. Conformance Test Assertions Each test vector SHOULD include: { "name": "ref-hash-mismatch", "input": "invalid/ref-hash-mismatch.json", "mode": "archival", "profile": "jep-core-0.6", "expected_valid": false, "expected_level": 2, "expected_error": "ERR_REF_HASH_MISMATCH" } Test assertions SHOULD specify: - input path; - validation mode; - trust profile; - expected validity; - expected highest completed level; - expected warning codes; - expected error codes; - expected event hash, if applicable. --- 9. Reference CLI Behavior A reference validator CLI SHOULD provide: jep-validate event.json jep-validate event.json --mode archival jep-validate-chain chain.jsonl jep-explain-failure event.json jep-check-profile event.json --profile did-vc jep-run-tests test-vectors/ CLI output SHOULD be a validation result object. --- 10. Implementation Requirements A conforming implementation SHOULD document: - supported JEP-Core version; - supported conformance classes; - supported signature algorithms; - supported canonicalization versions; - supported hash algorithms; - supported profiles; - supported extensions; - failure-code coverage; - test-vector pass report. --- 11. Interoperability Report Format An implementation MAY publish an interoperability report: { "implementation": "example-jep-validator", "version": "0.1.0", "jep_core": "0.6", "conformance_classes": [ "JEP-Core-0.6 Verifier", "JEP-Core-0.6 Archive Verifier" ], "profiles": ["jep-profile:did-vc:0"], "tests_passed": 142, "tests_failed": 0, "date": "2026-05-04" } --- 12. Security Considerations A conformance suite can detect implementation divergence but cannot prove deployment security. Implementations remain responsible for secure key storage, algorithm policy, trust-profile correctness, replay-cache operation, and secure evidence storage. Test keys MUST NOT be used in production. --- 13. Privacy Considerations Test vectors SHOULD avoid real personal data. Profile test vectors that exercise identity, credential, or evidence features SHOULD use synthetic identifiers and non-sensitive sample claims. --- 14. Versioning The conformance suite SHOULD version test vectors independently from JEP-Core. JEP-Core-0.6 can remain stable while conformance tests evolve as 0.6.1, 0.6.2, and so on. Changes that alter JEP-Core validation semantics require a JEP-Core revision, not only a conformance-suite update. --- 15. Initial Repository Layout Recommended repository layout: jep-conformance/ schemas/ jep-event.schema.json jep-ref.schema.json jep-extension.schema.json jep-signature.schema.json jep-profile.schema.json jep-validation-result.schema.json test-vectors/ valid/ invalid/ canonicalization/ profiles/ reference-validator/ README.md pseudo-code.md validation-flow.md examples/ basic-judgment-event.json delegation-termination-chain.jsonl verification-scope-example.json vc-backed-jep-event.json reports/ interoperability-report.schema.json --- 16. Author's Address Yuqiang Wang Email: signal@humanjudgment.org URI: https://github.com/hjs-spec 17. Engineering-Complete Seed Package The repository version of this draft set includes: - seed JSON Schemas under schemas/; - signed Ed25519/JWS/JCS baseline vectors under test-vectors/valid/; - invalid examples under test-vectors/invalid/; - canonicalization fixtures under test-vectors/canonicalization/; - a minimal Python reference validator under reference-validator/. These materials are intended to make JEP-Core-0.6 implementation-seeded. They are not a substitute for independent review, security audit, or production conformance testing. 18. Local CI and Test Harness The repository version of this draft set includes a local test harness: - Makefile - pyproject.toml - tests/test_reference_validator.py - .github/workflows/conformance.yml - test-manifest.json - reports/local-validation-report.json A conforming project MAY use these files as a bootstrap for continuous integration. Passing the seed suite does not imply production security or full profile conformance; it demonstrates baseline processing of signed JEP-Core-0.6 vectors and selected invalid cases. 19. Expanded Validation Artifacts The repository version of this draft set includes: - rendered Internet-Draft style .txt and seed RFCXML .xml files under ietf-rendered/; - profile-specific test vectors under test-vectors/profiles/; - additional invalid vectors for duplicate JSON members, nonce replay, terminated delegation reuse, extension conflict, algorithm downgrade, and expired credentials; - TypeScript validator seed under typescript-validator/; - verb-specific structural constraints in schemas/jep-event.schema.json. v0.6 Direct Upgrade Note This document is part of the JEP v0.6 draft set. The v0.6 set directly incorporates standardization structure, interoperability profiles, conformance artifacts, schemas, signed test vectors, invalid cases, and multi-language validator seeds without changing the JEP-Core narrow-waist semantics. draft-wang-jep-conformance-00 Expires November 5, 2026 [Page 1]