Internet-Draft JEP September 2026
Wang Expires 30 March 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-wang-jep-judgment-event-protocol-07
Published:
Intended Status:
Experimental
Expires:
Author:
Y. Wang

Judgment Event Protocol (JEP)

Abstract

This document defines the Judgment Event Protocol (JEP), a verifiable event format for judgment-related statements in human, organizational, software, and autonomous agent systems.

JEP specifies four Core event verbs: Judgment (J), Delegation (D), Termination (T), and Verification (V). It defines a signed JSON event structure, stable event identity, signature verification over JSON Canonicalization Scheme (JCS) canonicalized payloads, a detached JSON Web Signature (JWS) baseline profile, signed-artifact hash and reference semantics, independent validation checks, idempotent acceptance semantics, structured validation results, extension handling, trust-profile interfaces, and determinability boundaries.

JEP-Core does not mandate a replay-protection mechanism. An acceptance processor MUST apply the acceptance effect of a given Event Identity at most once within an acceptance domain. Profiles MAY impose additional freshness or replay requirements.

JEP-Core does not determine the substantive truth, authority, legality, policy consequence, causality, or external effect of the statements it carries. It also does not require any specific credential, identity, AI platform, agent framework, transport, or blockchain system.

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 30 March 2027.

▲

Table of Contents

1. Introduction

Autonomous and semi-autonomous systems increasingly make, assist with, delegate, terminate, verify, or record judgments across organizational, platform, model, and jurisdictional boundaries. These systems need a minimal and interoperable way to record judgment-related acts so that later verifiers can determine whether a particular event existed, whether it was signed under an applicable trust profile, whether its signed content changed, which event instance it represents, what it references, and which verification checks were actually performed.

JEP addresses this need by defining a compact signed JSON event format. The format is intentionally narrow. It records an event identifier, verb, actor identifier, declared event time, claim or digest, optional audience, optional references, extensions, and signature.

JEP separates event identity from signed-artifact identity:

JEP also separates event validity from acceptance effects. The same valid event MAY be delivered repeatedly. Repeated delivery MUST NOT be treated as a new event or cause the same acceptance effect to be applied again within one acceptance domain.

More complex identity, credential, policy, archival, challenge-response, causal-chain, and lifecycle semantics are externalized to profiles, extensions, HJS-like archival layers, JAC-like chain-composition layers, or application-specific systems.

JEP is neutral with respect to substantive truth, authority, legality, policy outcome, causality, and external consequence. JEP-Core defines structured signed statements and the protocol-observable properties by which those statements can be verified. It does not endorse a statement merely because that statement is well-formed or cryptographically valid. JEP is not semantics-free: J/D/T/V and the Core fields have defined protocol semantics. Neutrality concerns the substantive validity and consequences of the statements, not their protocol meaning.

In partially observed systems, a signed event log can support audit and accountability workflows without guaranteeing complete or zero-error determination of external facts.

1.1. Companion Specifications

This draft defines JEP-Core. Optional identity, credential, attestation, chain, archival, mandate, and domain bindings are defined by companion profiles and extensions.

Existing companion drafts written against JEP-Core 0.6 remain historical documents until revised for JEP-Core 0.7. Where an earlier companion draft conflicts with this document, this document controls JEP-Core 0.7 semantics.

Schemas, test vectors, validation-result structure, and reference validator behavior for JEP-Core 0.7 are expected to be defined by a matching conformance revision.

2. Protocol Objective and Non-Goals

2.1. Objective

JEP-Core defines a neutral event layer for verifiable judgment-related statements. Subject to the applicable validation mode and trust profile, a conforming implementation can support determination that:

  1. a specific Event Identity was carried in the signed statement;

  2. an event payload existed;

  3. the event payload was signed as specified;

  4. the signed payload was not modified without invalidating the signature;

  5. the signer was or was not bound to the claimed actor under an applicable trust profile;

  6. references, exact-artifact hashes, and critical extensions were processed according to the checks actually requested;

  7. the verifier reports which checks passed, failed, were not performed, were unsupported, were not applicable, or were indeterminate;

  8. an acceptance processor does not apply acceptance effects more than once for the same event identity within one acceptance domain.

2.2. Non-Goals

JEP-Core does not define:

  • legal liability;

  • moral responsibility;

  • regulatory compliance;

  • global truth determination;

  • external target-fact determinability;

  • authorization delegation validity;

  • permission-chain enforcement;

  • lifecycle state-machine enforcement;

  • termination cascade policy;

  • a global identity framework;

  • a global credential framework;

  • a global trust framework;

  • mandatory DID, VC, X.509, OAuth, RATS, blockchain, or AI-platform support;

  • confidentiality for event content;

  • long-term storage, redaction, retention, or disclosure policy;

  • causal-chain or responsibility-graph computation;

  • exactly-once network delivery;

  • a mandatory challenge, nonce, counter, ledger, or transport mechanism.

A JEP event records claims about judgment-related acts. It MUST NOT be presented as proof that an underlying real-world assertion is true unless an applicable external profile and evidence policy makes that determination.

3. Design Principles

JEP-Core follows these principles:

  1. Core minimality: JEP-Core defines the stable narrow-waist event layer.

  2. Substantive neutrality: JEP-Core records structured signed statements without deciding their substantive truth, authority, legality, causality, policy consequence, or external effect.

  3. Property over mechanism: JEP-Core defines required protocol properties without mandating a single replay, transport, storage, or challenge mechanism.

  4. Stable event identity: event identity is a first-class protocol concept and is separate from signed-artifact hashing.

  5. Idempotent acceptance: repeated delivery of the same event does not create a new event and MUST NOT repeatedly apply acceptance effects within one acceptance domain.

  6. Identity-system neutrality: JEP-Core MUST NOT require a specific identity system.

  7. Credential-system neutrality: JEP-Core MUST NOT require VC or any other credential model.

  8. Platform neutrality: JEP-Core MUST NOT require an AI platform, agent framework, cloud provider, transport, or blockchain network.

  9. Profile-based interoperability: identity, credentials, attestation, authorization, challenge-response, and archival policy are handled by optional profiles.

  10. Orthogonal verification: syntax, cryptographic validity, actor-binding, freshness, audience, event identity, references, extensions, chain analysis, and policy evaluation are independent checks rather than cumulative quality levels.

  11. Explicit determinability boundary: protocol validity is not the same as external truth.

  12. Privacy by minimization: sensitive evidence SHOULD be referenced by digest or controlled evidence mechanisms rather than embedded in event payloads.

  13. Extension without semantic capture: extensions MUST NOT redefine JEP-Core semantics.

  14. Algorithm agility: cryptographic algorithms are selected by JOSE headers, conformance profiles, and trust profiles rather than by event verbs.

  15. Historical immutability: historical signed events are verified under the rules that produced them and MUST NOT be silently rewritten into newer JEP representations.

4. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

5. Terminology

Actor: The entity identified by who that is claimed by the event. An actor MAY be a human, organization, model, agent, tool, service, device, workflow, committee, session, swarm, human-agent composite, or organization-agent composite.

Signer: The key holder that produces the event signature. The signer is not necessarily identical to the actor. The binding between signer and actor is defined by a trust profile.

Subject: The entity or object about which a judgment, delegation, termination, or verification is made. A subject is distinct from the actor.

Event: A single immutable signed JSON object carrying one judgment-related protocol statement.

Event ID: The value of the top-level id member. An Event ID is an opaque identifier chosen by the producer for one event instance.

Event Identity: The pair (who, id). A producer MUST NOT reuse the same Event Identity for different unsigned event content.

Unsigned Event: A JEP event object with the sig member omitted.

JEP Signing Payload: The UTF-8 octets of the JCS-canonicalized unsigned event.

Event Hash: An algorithm-tagged digest over the full signed event, including sig. The Event Hash identifies an exact signed artifact; it is not the Event Identity.

Acceptance Domain: The local application, trust, or processing context within which an event can produce a state-changing acceptance effect. Independent systems MAY accept the same event independently.

Acceptance Processor: A component that, after applicable validation, decides whether an event may apply an acceptance effect in an acceptance domain.

Idempotent Acceptance: The requirement that the same Event Identity MUST NOT apply acceptance effects more than once within one acceptance domain.

Claim: Semantic content carried by what or by an extension.

Reference: A typed or cryptographic pointer to another event, digest, credential, policy, evidence, context, archive receipt, or external object.

Exact Artifact Pin: A reference that includes an Event Hash or other digest in order to bind to an exact signed representation in addition to logical identity.

Trust Profile: A profile that defines actor identifier forms, signing-key resolution, actor/key binding, revocation, historical validity, acceptable algorithms, and related evidence policy.

Validation Check: An independently reported verification operation, for example syntax, cryptographic, actor_binding, freshness, audience, event_identity, reference_integrity, extension_processing, chain_integrity, or policy.

Validation Mode: The context in which validation is performed, such as archival, acceptance, chain, or policy.

Verification Scope: The declared scope of a V event, such as syntax, cryptographic, actor-binding, chain-integrity, credential-status, policy compliance, human review, external evidence, factual claim, or archival integrity.

6. Core Event Object

A JEP event is a JSON object [RFC8259]. Producers MUST emit I-JSON-compatible JSON [RFC7493] and MUST NOT emit duplicate JSON member names. Verifiers MUST reject events containing duplicate JSON member names.

The top-level members are:

Table 1
Member Status Description
jep REQUIRED Wire-format major version. For this draft, "1".
id REQUIRED Opaque event identifier. Event Identity is (who,id).
verb REQUIRED One of "J", "D", "T", "V".
who REQUIRED Actor identifier claimed by the event.
when REQUIRED Actor-declared event time, Unix seconds.
what REQUIRED Verb-specific claim, descriptor, or permitted digest.
aud OPTIONAL Intended audience or validation context.
ref Conditional Typed reference or exact-artifact reference.
ext OPTIONAL Extension object.
ext_crit OPTIONAL Critical extension identifier list.
sig REQUIRED Signature container defined by the applicable signature profile.

JEP-Core 0.7 has no required top-level nonce member.

The top-level extensibility mechanism is ext. Producers SHOULD NOT add new top-level members outside this specification unless defined by a future JEP revision.

7. Field Semantics

7.1. jep

The jep member identifies the wire-format major version. For this draft, the value is "1".

JEP-Core-0.7 identifies the specification release version. It is not the wire-format version.

The -06 and earlier Internet-Draft encodings were pre-stable development artifacts and do not create a permanent wire-compatibility contract for jep: "1".

A verifier MUST NOT infer Internet-Draft revision number or release maturity solely from jep.

7.2. id

id identifies one event instance within the namespace of who. Event Identity is the pair (who, id).

The id value:

  • MUST be a non-empty ASCII string;

  • MUST be stable for the lifetime of the event;

  • MUST be included in the signed payload;

  • MUST NOT be reused by the same who for different unsigned event content;

  • SHOULD be collision-resistant across independently generated events;

  • MUST NOT be treated as a secret, bearer token, authorization grant, or proof of freshness.

UUID URNs [RFC9562], other collision-resistant URIs, or equivalent opaque identifiers are suitable choices. JEP-Core does not require a specific identifier-generation algorithm.

A producer SHOULD NOT derive id solely from the event's semantic content when doing so could collapse two distinct event emissions with identical content into one Event Identity.

If a verifier observes the same Event Identity with different JCS-canonicalized unsigned event content, it MUST report ERR_EVENT_ID_CONFLICT.

Re-signing an otherwise identical unsigned event MAY produce a different Event Hash while retaining the same Event Identity.

7.3. verb

The verb member identifies the event verb. It MUST be one of J, D, T, or V.

Event verbs do not determine cryptographic algorithms, storage policy, privacy mode, identity method, transport, or legal effect.

7.4. who

who identifies the actor claimed by the event.

who is not necessarily:

  • the signer;

  • a legal person;

  • the controller of the key;

  • a real-world identity;

  • the subject of the judgment.

The binding between who and the signing key is determined by the applicable trust profile.

Because Event Identity includes who, two different actors MAY use the same id string without creating the same Event Identity.

7.5. when

when is an actor-declared event time in Unix seconds.

when does not by itself prove trusted wall-clock time, liveness, or freshness. Stronger time evidence requires a timestamping, receipt, archival, transparency, challenge-response, transport, or storage profile.

Implementations SHOULD distinguish:

  • declared event time;

  • signature time;

  • receipt time;

  • archive time;

  • verification time;

  • acceptance time;

  • policy-evaluation time.

An acceptance profile MAY define a permitted time window using when, but such a window is a profile or deployment rule rather than proof that when is externally accurate.

7.6. what

what carries the event claim, digest, descriptor, or report. It records what the actor asserted, judged, delegated, terminated, or verified. It does not by itself prove external truth.

A J event MUST contain what.

A D event MUST contain an object-valued what with the Core members delegatee and scope.

A T event MUST contain an object-valued what with the Core member termination_scope. The target of termination is identified by ref. JEP-Core does not require duplication of the target inside what.

A V event MUST contain an object-valued what with the Core members verification_scope and result.

Additional domain semantics belong to profiles or extensions.

When what is represented as a digest where permitted, the digest MUST be an algorithm-tagged digest string.

7.7. aud

aud indicates an intended audience or validation context.

aud is OPTIONAL in JEP-Core. A profile MAY require it, including for interactive acceptance or cross-domain replay isolation.

aud does not by itself enforce access control. Access control, retention, redaction, and disclosure policy are outside JEP-Core.

7.8. ref

ref is a reference field. A reference does not by itself imply endorsement, truth, authorization validity, legal effect, or causality.

References MAY identify:

  • a JEP event;

  • a digest;

  • a credential;

  • a policy;

  • evidence;

  • a context;

  • an archive receipt;

  • an external object.

A logical reference to another JEP event SHOULD use a typed reference:

json { "type": "jep:event", "value": { "who": "did:example:actor-123", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" } }

An exact signed artifact MAY additionally be pinned:

json { "type": "jep:event", "value": { "who": "did:example:actor-123", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" }, "hash": "sha256:..." }

The value identifies the event. The optional hash identifies one exact signed artifact for that event.

A bare Event Hash MAY be used when an application intentionally refers only to an exact signed artifact, but it MUST NOT be described as the stable Event Identity.

7.9. ext and ext_crit

ext contains named extension objects. ext_crit contains the identifiers of critical extensions.

Unknown critical extensions MUST cause the applicable extension_processing check to fail. Unknown non-critical extensions MAY be ignored.

Profiles that require a nonce, challenge, sequence number, transaction identifier, ledger position, or similar mechanism SHOULD carry that mechanism in a registered extension or transport/profile layer rather than redefining JEP-Core fields.

7.10. sig

sig carries the detached signature container. JEP-Core defines the JEP Signing Payload. The applicable signature or conformance profile defines the exact signature serialization, protected headers, algorithm identifiers, key identifiers, and sig representation.

The baseline profile uses detached JWS over the JCS-canonicalized unsigned event. Other registered signature profiles MAY define an alternative container without changing J/D/T/V semantics.

8. Event Verb Semantics

JEP verb semantics define the type of statement carried by an event. They describe what the event claims; they do not independently establish that the claimed act occurred, was authorized, was correct, or produced an external effect.

The following table defines the minimum Core distinction among the four verbs. Profiles and extensions MAY add domain-specific members but MUST NOT replace these Core requirements with differently named equivalents.

Table 2
Verb what requirement ref requirement Core distinction
J REQUIRED claim, object, or permitted digest OPTIONAL expresses or adopts a judgment
D REQUIRED object with delegatee and scope OPTIONAL declares a scoped delegation
T REQUIRED object with termination_scope REQUIRED declares termination of future reliance on a target
V REQUIRED object with verification_scope and result REQUIRED records a scoped evaluation result over a target

8.1. J - Judgment

A Judgment event represents the signed statement that the actor identified by who expressed or adopted a judgment about a claim, choice, classification, recommendation, or proposed result.

The claim represented by J is the judgment itself. A J event MUST NOT be interpreted as proof that the judged claim is true, authorized, or externally effective.

Typical uses include:

  • approval or rejection of a proposed result;

  • risk classification;

  • selection among alternatives;

  • recommendation acceptance;

  • policy or operational judgment;

  • assessment expressed as a judgment rather than as a scoped verification result.

8.2. D - Delegation

A Delegation event represents the signed statement that the actor identified by who declared a delegation to a delegatee within an explicit scope.

A D event MUST contain what.delegatee and what.scope. It MAY identify:

  • constraints;

  • expiry;

  • context;

  • termination conditions;

  • related evidence or policy references.

A D event records a delegation claim. It does not by itself prove legal, organizational, or technical authority to delegate.

Permission-chain enforcement and downstream authorization are outside JEP-Core.

8.3. T - Termination

A Termination event represents the signed statement that the actor identified by who declared a referenced target no longer eligible for future reliance within a stated termination scope.

A T event MUST identify its target through ref and MUST contain what.termination_scope.

A T event does not delete historical events, erase past facts, retroactively invalidate an event, or by itself prove that all downstream systems stopped relying on the target.

Cascade semantics, downstream effects, authority consequences, and lifecycle enforcement are defined by chain, mandate, domain, or policy profiles.

8.4. V - Verification

A Verification event represents the signed statement that the actor identified by who evaluated a referenced target under an explicitly declared verification scope and recorded the result of that evaluation.

A V event MUST identify its verification target through ref, MUST contain what.verification_scope, and MUST contain what.result. A V event MUST NOT imply verification beyond its declared scope.

Use V when the statement is the result of evaluating a referenced target under an explicit verification scope. Use J when an actor expresses or adopts a judgment without asserting that scoped verification relation. For example, "I reject proposal X" is a J statement; "I evaluated artifact X under integrity check S and obtained result FAIL" is a V statement.

Initial verification scopes include:

  • syntax;

  • cryptographic;

  • actor_binding;

  • freshness;

  • audience;

  • event_identity;

  • reference_integrity;

  • extension_processing;

  • chain_integrity;

  • credential_status;

  • policy_compliance;

  • human_review;

  • external_evidence;

  • factual_claim;

  • archival_integrity.

9. Event Identity, Delivery, and Acceptance

9.1. Event Identity

The Event Identity is (who, id).

The same Event Identity represents the same JEP event instance across retransmission, storage, export, and re-verification.

The same Event Identity MUST NOT identify different unsigned event content.

A verifier that maintains identity state SHOULD retain, for each observed Event Identity, a digest of the JEP Signing Payload or an equivalent collision-resistant representation sufficient to detect conflicting reuse.

9.2. Delivery Is Not Event Creation

Network delivery, queue delivery, storage import, export, retry, or replication of an existing signed event does not create a new JEP event.

A sender MAY retransmit the same event when delivery outcome is unknown.

A receiver MUST NOT require a new JEP Event Identity merely because a transport retry occurs.

9.3. Idempotent Acceptance

An acceptance processor MUST NOT apply acceptance effects more than once for the same Event Identity within one acceptance domain.

A conforming acceptance processor MUST distinguish at least:

  • accepted: the event is valid for the requested acceptance context and its acceptance effect is being applied for the first time;

  • already_accepted: the event is valid for the requested acceptance context but the same Event Identity has already applied its acceptance effect;

  • rejected: one or more required validation checks failed;

  • indeterminate: a required acceptance determination could not be completed.

already_accepted is not a cryptographic validation failure.

If the same Event Identity is presented with different unsigned event content, the event MUST be rejected with ERR_EVENT_ID_CONFLICT.

9.4. Atomicity

The operation that records first acceptance and the operation that applies its state-changing acceptance effect MUST be atomic or provide an equivalent concurrency guarantee.

An implementation MUST NOT perform:

text check unseen apply effect mark seen

as independent raceable operations.

Database uniqueness constraints, transactional insertion, durable compare-and-set, ledger consumption, or equivalent mechanisms are suitable approaches.

9.5. Acceptance-State Lifetime

An implementation claiming at-most-once acceptance MUST preserve enough acceptance state to prevent reapplication for as long as the event remains eligible to produce that acceptance effect.

A profile MAY define a bounded acceptance window. If no bounded window exists, acceptance state may need to persist for the lifetime of the effect or dependent state.

Archival verification MUST NOT consume acceptance state.

9.6. Optional Challenge and Replay Profiles

JEP-Core does not require a nonce.

Profiles MAY additionally require:

  • receiver-issued nonces;

  • sender-generated nonces;

  • challenge-response;

  • sequence numbers;

  • transaction identifiers;

  • trusted timestamps;

  • short-lived audience-bound tokens;

  • monotonic counters;

  • ledger positions;

  • previous-event commitments.

Such mechanisms MAY establish properties that stable Event Identity alone does not establish, including current liveness, server challenge freshness, total order, or single-use authority.

10. References and Chain Boundaries

A cryptographically validated JEP event can establish that its signed content referenced another object. That reference does not by itself establish causality, endorsement, truth, authorization, completeness, or legal consequence.

A typed event reference identifies an event through Event Identity. An optional artifact hash additionally pins a particular signed representation.

If an exact-artifact hash is present, a verifier performing reference_integrity MUST verify the hash against the resolved signed artifact.

Chain reconstruction, delegation-scope enforcement, termination cascade, cycle analysis, complete-log assumptions, responsibility graphs, and causal interpretation are outside JEP-Core and belong to JAC-like chain profiles or application-specific systems.

A chain system MUST NOT reinterpret a JEP Event Hash as the stable Event Identity.

11. Algorithm-Tagged Digest Strings

JEP uses algorithm-tagged digest strings for Event Hashes, content digests, exact-artifact pins, and other digest references.

Syntax: <hash-algorithm>:<lowercase-hex-digest>

The hash algorithm identifier MUST be lower-case ASCII. The digest value MUST be lower-case hexadecimal.

Implementations conforming to the JEP-Core 0.7 baseline MUST support sha256 as specified for SHA-256 in [RFC6234].

A SHA-256 digest string therefore begins with sha256: followed by 64 lower-case hexadecimal digits.

Additional digest algorithms MAY be defined by conformance profiles, trust profiles, or registered extensions.

12. Signing Input and Event Hash

The JEP Signing Payload is the unsigned event object with sig omitted, canonicalized using JCS [RFC8785] and encoded as UTF-8 octets.

The Event Hash identifies the full signed event object, including sig.

For the default hash profile:

text event_hash = sha256(UTF8(JCS(full_signed_event)))

The Event Identity, signing payload, and Event Hash are intentionally different:

A different valid signature representation over otherwise identical unsigned event content MAY result in a different Event Hash without creating a different Event Identity.

13. Signature, Hash, and Algorithm Agility

JEP-Core preserves algorithm agility.

Under the baseline signature profile, a JEP event is protected by a detached JWS signature [RFC7515] over a JCS-canonicalized unsigned event payload.

JEP-Core does not assign cryptographic algorithms to event verbs. J, D, T, and V share the same cryptographic processing model.

The concrete signature algorithm, key type, hash algorithm, and algorithm acceptability policy are determined by JOSE headers, conformance profiles, and trust profiles.

A baseline conformance class MAY define a required-to-implement algorithm set for interoperability. Ed25519 [RFC8032] is one possible baseline signature algorithm. Such a conformance class does not make one algorithm the only algorithm allowed by JEP-Core semantics.

A trust profile MUST define which algorithms are acceptable for its deployment context.

A verifier MUST reject an event if the declared algorithm is unsupported, prohibited by the applicable profile, inconsistent with the resolved key type, inconsistent with the signature container, or inconsistent with a critical cryptographic extension.

A verifier SHOULD distinguish real-time acceptance validation from archival validation. An algorithm MAY be acceptable for historical verification while being prohibited for newly produced events.

14. Trust Profile Interface

JEP-Core does not define a global identity or trust framework.

A trust profile MUST define, where applicable:

Support for DID, VC, X.509, OAuth, RATS, blockchain anchoring, or any specific identity system is OPTIONAL and MUST NOT be required for JEP-Core conformance.

15. Validation Model

15.1. Independent Validation Checks

JEP-Core does not define cumulative validation levels.

A verifier reports independent checks. Their ownership is intentionally separated:

JEP-Core-defined checks:

  • syntax;

  • cryptographic;

  • event_identity;

  • reference_integrity;

  • extension_processing.

Trust- or acceptance-profile checks:

  • actor_binding;

  • freshness;

  • audience.

Companion or external checks:

  • chain_integrity;

  • policy.

Listing a companion or external check in a JEP validation result does not make its semantics part of JEP-Core.

A check status is one of:

  • pass;

  • fail;

  • not_checked;

  • not_applicable;

  • unsupported;

  • indeterminate.

unsupported means the verifier does not implement the requested check or profile.

indeterminate means the verifier implements the check but cannot complete it from the available evidence or state.

A verifier MUST NOT report an unperformed check as pass.

15.2. Overall Validation Status

The overall validation status is one of:

  • valid;

  • invalid;

  • indeterminate.

For a requested mode and profile:

  • valid means all required checks passed or were not applicable;

  • invalid means at least one required check failed;

  • indeterminate means no required check failed, but at least one required check is unsupported or indeterminate.

Checks not required by the requested mode or profile MAY be not_checked.

15.3. Validation Modes

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 checks and idempotent acceptance semantics plus any freshness, audience, actor-binding, or challenge requirements declared by the applicable profile.

Chain mode invokes a companion chain profile or chain system. JEP-Core does not define chain-integrity semantics.

Policy mode invokes a domain, organizational, legal, regulatory, or deployment policy. Policy results MUST NOT be presented as intrinsic properties of JEP-Core.

15.4. Deterministic Core Validation Order

A JEP-Core verifier SHOULD process an event in this order:

  1. parse JSON;

  2. reject duplicate JSON member names;

  3. check required top-level fields;

  4. validate jep, id, verb, who, and when;

  5. check verb-specific core field requirements;

  6. remove sig to construct the unsigned event;

  7. canonicalize the unsigned event using JCS;

  8. verify the detached signature;

  9. compute the Event Hash if needed;

  10. evaluate Event Identity consistency provisionally if identity state is available;

  11. resolve actor/key and actor binding if required;

  12. validate audience if required by the requested profile;

  13. evaluate freshness if required by the requested profile;

  14. validate reference syntax and exact-artifact pins if requested;

  15. process critical extensions;

  16. invoke optional chain checks if requested;

  17. invoke optional policy checks if requested;

  18. if acceptance mode is requested, atomically determine and record the acceptance outcome;

  19. return a structured validation result.

An implementation MUST perform cryptographic validation before writing new authoritative Event Identity or acceptance state for an untrusted input. When the requested acceptance profile requires actor binding, the implementation MUST NOT commit authoritative Event Identity or acceptance state until actor binding has passed.

Deployments SHOULD bound acceptance-state resource use according to their trust, audience, retention, and abuse-control policy.

16. Validation Result Object

A verifier SHOULD return a structured validation result.

Example for first acceptance:

json { "status": "valid", "mode": "acceptance", "profile": "jep-core-0.7", "event_identity": { "who": "did:example:agent-789", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" }, "event_hash": "sha256:...", "checks": { "syntax": "pass", "cryptographic": "pass", "actor_binding": "not_checked", "freshness": "pass", "audience": "pass", "event_identity": "pass", "reference_integrity": "not_applicable", "extension_processing": "pass", "chain_integrity": "not_checked", "policy": "not_checked" }, "acceptance": { "outcome": "accepted", "effect_applied": true }, "warnings": [], "errors": [] }

Example for safe retry:

json { "status": "valid", "mode": "acceptance", "profile": "jep-core-0.7", "event_identity": { "who": "did:example:agent-789", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" }, "event_hash": "sha256:...", "checks": { "syntax": "pass", "cryptographic": "pass", "event_identity": "pass" }, "acceptance": { "outcome": "already_accepted", "effect_applied": false }, "warnings": [], "errors": [] }

A validation result MUST distinguish:

17. Failure Codes

A conforming validator SHOULD return structured failure codes.

17.1. Syntax and Identity Errors

  • ERR_INVALID_JSON

  • ERR_DUPLICATE_MEMBER

  • ERR_UNSUPPORTED_JEP_VERSION

  • ERR_UNKNOWN_VERB

  • ERR_MISSING_REQUIRED_FIELD

  • ERR_INVALID_FIELD_TYPE

  • ERR_INVALID_TIMESTAMP

  • ERR_EVENT_ID_INVALID

  • ERR_EVENT_ID_CONFLICT

17.2. Cryptographic Errors

  • ERR_CANONICALIZATION_FAILED

  • ERR_CANONICALIZATION_VERSION_UNSUPPORTED

  • ERR_INVALID_EVENT_HASH

  • ERR_UNSUPPORTED_SIGNATURE_ALG

  • ERR_PROHIBITED_SIGNATURE_ALG

  • ERR_ALG_KEY_TYPE_MISMATCH

  • ERR_ALG_PROFILE_MISMATCH

  • ERR_HASH_ALG_UNSUPPORTED

  • ERR_SIGNATURE_CONTAINER_INVALID

  • ERR_SIGNATURE_MISSING

  • ERR_SIGNATURE_INVALID

  • ERR_DIGEST_MISMATCH

  • ERR_ARCHIVAL_ALG_STATUS_UNKNOWN

  • ERR_ALG_DEPRECATED_FOR_NEW_EVENTS

17.3. Actor and Trust Errors

  • ERR_ACTOR_UNRESOLVED

  • ERR_KEY_UNRESOLVED

  • ERR_KEY_NOT_BOUND_TO_ACTOR

  • ERR_KEY_REVOKED

  • ERR_KEY_NOT_VALID_AT_EVENT_TIME

  • ERR_TRUST_PROFILE_UNSUPPORTED

17.4. Freshness and Acceptance Errors

  • ERR_EVENT_EXPIRED

  • ERR_TIMESTAMP_OUT_OF_WINDOW

  • ERR_ACCEPTANCE_STATE_UNAVAILABLE

  • ERR_ACCEPTANCE_ATOMICITY_UNAVAILABLE

already_accepted is an acceptance outcome, not an error code.

17.5. Reference Errors

  • ERR_REF_UNRESOLVED

  • ERR_REF_HASH_MISMATCH

  • ERR_REF_IDENTITY_MISMATCH

Chain-specific failure codes, including delegation-scope, termination cascade, cycle, and complete-log failures, belong to the applicable chain profile rather than JEP-Core.

17.6. Extension Errors

  • ERR_UNKNOWN_CRITICAL_EXTENSION

  • ERR_EXTENSION_SCHEMA_INVALID

  • ERR_EXTENSION_VALIDATION_FAILED

  • ERR_EXTENSION_CONFLICT

17.7. Policy Errors

  • ERR_POLICY_REJECTED

  • ERR_AUTHORIZATION_CONTEXT_MISSING

  • ERR_DOMAIN_REQUIREMENT_UNSATISFIED

18. Extension Rules and Conflict Handling

An extension MUST declare:

  1. extension identifier;

  2. extension version;

  3. JSON schema or equivalent data model;

  4. whether it may be critical;

  5. validation requirements;

  6. security considerations;

  7. privacy considerations;

  8. interaction with Event Identity, Event Hashes, and signatures;

  9. interaction with other known extensions, if applicable.

Extensions MUST NOT redefine the semantics of core JEP members.

Unknown critical extensions MUST cause the extension_processing check to fail. Unknown non-critical extensions MAY be ignored.

If two critical extensions impose inconsistent requirements, validation MUST fail with ERR_EXTENSION_CONFLICT.

Extension identifiers SHOULD be collision-resistant. Supported forms include:

19. Conformance Requirements

19.1. Producer Conformance

A JEP-Core-0.7 producer MUST support:

  • I-JSON-compatible event construction;

  • generation or assignment of a stable id;

  • required top-level fields;

  • JCS canonicalization of unsigned payloads;

  • signature generation under at least one conformance class;

  • algorithm-tagged digest strings;

  • ext and ext_crit semantics.

A producer MUST NOT reuse one Event Identity for different unsigned event content.

19.2. Verifier Conformance

A JEP-Core-0.7 verifier MUST support:

  • duplicate-member rejection;

  • core field validation;

  • Event Identity validation;

  • JCS canonicalization;

  • signature verification under at least one conformance class;

  • Event Hash calculation;

  • independent validation checks;

  • structured validation result objects;

  • unknown critical extension rejection;

  • archival validation mode.

A verifier MUST NOT require support for any optional identity, credential, attestation, blockchain, AI platform, agent framework, challenge, transport, or chain profile.

19.3. Acceptance-Processor Conformance

An implementation claiming JEP-Core-0.7 acceptance-processor conformance MUST additionally support:

  • stable acceptance-domain definition;

  • detection of conflicting Event Identity reuse;

  • durable or otherwise sufficient acceptance state;

  • atomic or equivalent first-acceptance processing;

  • accepted, already_accepted, rejected, and indeterminate outcomes;

  • separation between repeated valid delivery and invalid event content.

A profile MAY add freshness, audience, challenge-response, authorization, or single-use-authority requirements.

19.4. Baseline Algorithm Conformance

A baseline conformance class MAY require detached JWS using JCS canonicalization, sha256 algorithm-tagged digest strings, and Ed25519 verification.

This baseline is a conformance-class requirement, not a JEP-Core semantic requirement. Other profiles MAY define additional or alternative algorithm suites, including regional, enterprise, COSE/CBOR, composite, or post-quantum profiles, provided that their identifiers, key representations, downgrade policies, and validation behavior are specified.

20. Determinability Boundary

JEP distinguishes protocol-observable properties of signed statements from substantive facts about the external world. This distinction is the basis of JEP-Core's substantive neutrality.

20.1. Observable Protocol Properties

Subject to the checks actually performed, JEP can support determination of protocol-level properties such as:

  • whether an Event Identity was asserted in a signed event;

  • whether an unsigned payload was signed by a key;

  • whether a key is acceptable under a trust profile;

  • whether an Event Hash matches an exact signed artifact;

  • whether an event references another Event Identity;

  • whether an exact-artifact pin matches the resolved artifact;

  • whether the same Event Identity was already accepted in one acceptance domain;

  • whether a critical extension was processed;

  • which validation checks were actually performed.

20.2. External Target Facts

JEP alone does not determine external target facts such as:

  • whether a real-world statement is true;

  • whether a model internally understood a request;

  • whether an actor is legally liable;

  • whether a delegation is legally enforceable;

  • whether a human actually read a document;

  • whether a physical-world action occurred outside the logged system;

  • whether all downstream systems honored a Termination event;

  • whether an observed event log is complete.

A profile MAY define evidence rules for external target facts. Such rules are outside JEP-Core. A JEP-Core-valid event MUST NOT be presented as JEP endorsing the actor's claim, authority, policy position, legal status, or requested consequence.

21. Observed Log Assumptions

An observed JEP log is not necessarily a complete log.

Absence of an event in an observed log MUST NOT be interpreted as proof that the event did not occur unless a complete-log assumption is explicitly declared by a deployment or chain profile.

Profiles MAY define:

A chain reconstruction result MUST declare whether it relies on complete or partial log assumptions.

JEP-Core does not itself compute chain completeness, termination cascade, or responsibility lineage.

22. Relationship to HJS and JAC

JEP defines atomic signed judgment-related events.

HJS-like systems manage storage, receipt, archival context, retention, redaction, selective disclosure, privacy policy, and evidence lifecycle for JEP events. Such systems MUST NOT redefine JEP-Core Event Identity, signature semantics, Event Hash semantics, or validation-check meanings.

JAC-like systems compose JEP events into causality chains, responsibility chains, delegation paths, verification paths, and workflow accountability graphs. Such systems MUST NOT redefine JEP-Core event format, Event Identity, signature semantics, or Event Hash semantics.

A JEP reference does not by itself imply causality. Causal, authorization, lifecycle, and termination-cascade interpretations are defined by JAC or another chain/profile layer.

23. Security Considerations

JEP-Core provides mechanisms and invariants for:

JEP-Core does not by itself prevent:

23.1. Event ID Security

id is not a secret and MUST NOT be used as an authorization token.

Because Event Identity is (who,id), deliberate use of another actor's id string does not create the same Event Identity.

A producer MUST NOT reuse an Event Identity for different unsigned event content. Verifiers with identity state MUST detect such reuse as ERR_EVENT_ID_CONFLICT.

Predictable Event IDs do not weaken signature integrity, but they may increase correlation or enumeration risk in systems that expose lookup interfaces. Profiles MAY impose stronger identifier-generation rules.

23.2. Replay and Safe Retry

A copied, unmodified signed event can remain cryptographically valid. Signature validity alone therefore does not prevent repeated delivery.

JEP-Core addresses duplicate acceptance through stable Event Identity and idempotent acceptance. A valid retry yields already_accepted rather than a second state-changing effect.

Applications requiring proof of current liveness, server challenge freshness, strict request ordering, or single-use authority SHOULD use an appropriate challenge, nonce, sequence, timestamp, counter, reservation, or ledger profile in addition to JEP-Core.

23.3. Acceptance-State Failure

If an implementation cannot reliably determine whether an Event Identity was already accepted, it MUST NOT claim a fresh accepted outcome.

If required acceptance state or atomicity guarantees are unavailable, the result MUST be indeterminate or rejected according to the applicable profile.

23.4. Downgrade Resistance

A verifier MUST reject algorithms prohibited by the applicable profile. A verifier MUST NOT accept a weaker algorithm merely because it is syntactically valid in JOSE.

23.5. Human-in-the-Loop Semantics

A human-review event records that a human actor emitted or endorsed a review-related claim. It does not prove that the human fully understood the underlying material, that the judgment was correct, or that legal compliance was satisfied.

23.6. AI Actor Semantics

JEP-Core does not mandate any specific AI actor identity scheme. AI actor identity, model identity, tool identity, service identity, and session identity are defined by trust profiles or extensions.

24. Privacy Considerations

JEP events may reveal actor identity, event identity, subject identity, judgment timing, delegation structure, organizational workflow, tool usage, and audit relationships.

Deployments SHOULD minimize personal data in what and extensions. When possible, external evidence SHOULD be referenced by digest rather than embedded directly.

Event IDs and Event Hashes may enable correlation across exports or systems. Deployments SHOULD avoid stable cross-context identifiers when they are not required by the trust or interoperability model.

Digest references may enable correlation, confirmation attacks, or dictionary attacks. Sensitive evidence references MAY require salted digests, commitment schemes, access-controlled evidence stores, audience-bound references, selective disclosure, or redaction.

JEP signatures and references may create linkability across contexts. Implementations SHOULD avoid reusing actor identifiers across unrelated audiences unless required by the trust profile.

JEP is an accountability protocol component. It SHOULD NOT be deployed as a general monitoring mechanism without data-minimization, retention, access-control, and redaction policies.

25. Registry Considerations

JEP registries SHOULD cover:

New verb registrations are NOT RECOMMENDED. New verbs require an update to JEP-Core explaining why existing verbs plus extensions are insufficient.

26. Versioning and Compatibility

26.1. Wire Version

For JEP-Core 0.7, jep remains "1".

The -06 and earlier Internet-Draft encodings are pre-stable draft artifacts. Their use of jep: "1" does not require JEP-Core 0.7 to preserve their field set.

26.2. Historical Verification

Implementations MAY retain historical pre--07 decoders.

Historical signed events MUST NOT be rewritten, re-signed, or silently upgraded merely to satisfy JEP-Core 0.7.

A historical decoder MUST be selected explicitly through a named compatibility mode, known artifact context, archive metadata, or other non-heuristic mechanism.

An implementation MUST NOT:

  1. attempt JEP-Core 0.7 validation;

  2. observe failure;

  3. silently retry as JEP-Core 0.6 based only on field presence.

26.3. Future Compatibility

Future revisions MAY add optional fields or extensions without changing the wire major when the core event object remains compatible.

A future revision that changes stable Event Identity semantics, signing input semantics, canonicalization requirements, or required Core fields after real-world jep: "1" adoption SHOULD define a new wire major.

Unknown critical extensions MUST fail the extension_processing check. Unknown non-critical extensions MAY be ignored.

27. Examples

27.1. Minimal Judgment Event Shape

json { "jep": "1", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0", "verb": "J", "who": "did:example:agent-789", "when": 1742345678, "what": { "claim": "example-judgment" }, "sig": "..." }

27.2. Judgment Event with Audience and Event Reference

json { "jep": "1", "id": "urn:uuid:018f4f8d-8ad2-7baf-b752-e529e79bc88a", "verb": "J", "who": "did:example:agent-789", "when": 1742345700, "what": { "claim": "approve-result", "subject": "urn:example:result:42" }, "aud": "https://platform.example.com", "ref": { "type": "jep:event", "value": { "who": "did:example:agent-123", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" }, "hash": "sha256:..." }, "sig": "..." }

Full signed test vectors belong in the matching conformance revision.

28. Changes from -06

Major changes from draft-wang-jep-judgment-event-protocol-06:

29. IANA Considerations

This document requests no IANA actions.

A future standards-track revision may request registries for JEP verbs, extension identifiers, validation checks, acceptance outcomes, trust profiles, conformance classes, or related identifiers.

30. References

30.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/rfc/rfc6234>.
[RFC7493]
Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, , <https://www.rfc-editor.org/rfc/rfc7493>.
[RFC7515]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785]
Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, , <https://www.rfc-editor.org/rfc/rfc8785>.

30.2. Informative References

[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, , <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC9562]
Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, , <https://www.rfc-editor.org/rfc/rfc9562>.

Acknowledgments

The author thanks implementers and reviewers who provided interoperability, security, and deployment feedback on earlier JEP draft revisions.

Author's Address

Yuqiang Wang
URI: https://github.com/hjs-spec