draft-wang-jep-judgment-event-protocol-05

Internet-Draft Y. Wang
Intended status: Experimental April 29, 2026
Expires: October 29, 2026

Judgment Event Protocol (JEP)
A Minimal Verifiable Log Format for Agent Decisions
draft-wang-jep-judgment-event-protocol-05

Abstract

This document defines the Judgment Event Protocol (JEP), a minimal
verifiable log format for decision-related operations in agent
systems. JEP specifies four immutable event verbs (J, D, T, V), a
signed JSON event structure, anti-replay protection, detached JSON Web
Signature (JWS) verification over JSON Canonicalization Scheme (JCS)
canonicalized payloads, event hash and reference semantics, validation
modes, and a modular extension framework.

JEP is intended to provide global protocol-level interoperability for
verifiable decision event records. It does not define legal
liability, authorization validity, regulatory compliance, or
organizational trust decisions.

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 October 29, 2026.

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.

Table of Contents

1. Introduction
1.1. Motivation
1.2. Scope
1.3. Requirements Language
1.4. Terminology
2. Protocol Model
2.1. Design Goals
2.2. Event Verbs
2.3. Core Event Object
2.4. Algorithm-Tagged Digest Strings
2.5. Event Hashes and Reference Semantics
2.6. Signing Input and Signature Container
2.7. Key Resolution and Trust Profiles
2.8. Anti-Replay and Validation Modes
2.9. Extension Framework
2.10. Standard Extensions
2.10.1. Digest-Only Anonymity Extension
2.10.2. Multi-Signature Extension
2.10.3. Time-to-Live Extension
2.10.4. Sovereign Storage Extension
2.10.5. Subject Reference Extension
2.10.6. Cryptographic Profile Extension
2.11. Conformance Profiles
3. Security and Privacy Considerations
3.1. Core Security Properties
3.2. Threat Model and Non-Goals
3.3. Verification Limits under Partial Observation
3.4. Extension Security Considerations
3.5. Privacy and Data Minimization
4. IANA Considerations
4.1. JEP Verbs Registry
4.2. JEP Extensions Registry
4.3. JEP Signature Capability Values Registry
4.4. JEP Conformance Profiles Registry
5. Normative References
6. Informative References
Appendix A. Examples and Test Vectors
Appendix B. Changes from -04
Author's Address

1. Introduction

1.1. Motivation

Autonomous and semi-autonomous agent systems increasingly make,
assist with, or record decisions across organizational, platform, and
jurisdictional boundaries. These systems need a minimal and
interoperable way to record decision-related actions so that later
verifiers can determine whether a particular event was emitted by a
particular actor, whether the event has been modified, and whether it
relates to other events in a verifiable chain.

JEP addresses this need by defining a compact signed JSON event
format. The format is intentionally small: the protocol identifies a
decision-related action, binds it to an actor, timestamp, nonce,
optional audience, related content digest, related event reference,
and signature.

JEP is designed to adapt to diverse cultural, legal, political, and
operational environments. It achieves this by separating the stable
event format from optional extension and trust profiles. This
document defines the protocol-level mechanics; deployers and
verifiers apply their own legal, organizational, and policy
requirements.

JEP also does not assume that every external target fact is
determinable from the available event log. In partially observed
causal systems, logs, traces, measurements, or explanations can
support verification and audit workflows without guaranteeing
zero-error determination of external facts
[TARGET-DETERMINABILITY]. JEP therefore records verifiable event
claims rather than global fact determination.

1.2. Scope

JEP defines:

* Four immutable core decision event verbs: J, D, T, and V.

* A minimal signed JSON event object.

* Algorithm-tagged digest strings for content and event references.

* Event hash calculation and reference semantics.

* Detached JWS signature verification over JCS-canonicalized
unsigned events.

* Anti-replay protection using nonce, timestamp, and optional
audience binding.

* Acceptance validation and archival validation modes.

* A modular extension framework using "ext" and "ext_crit".

* Optional standard extensions for privacy, accountability
distribution, lifecycle metadata, storage adaptation, subject
reference, and cryptographic capability profiles.

JEP explicitly does not define:

* Legal liability or accountability determination rules.

* Authorization delegation validity or permission chain constraints.

* State machine or lifecycle enforcement logic.

* Regulatory, governance, or business compliance determination.

* Determinability of external target facts from partial observations.

* A global identity, credential, or trust framework.

* A confidentiality mechanism for event content.

1.3. 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.

1.4. Terminology

Event:
A single observable record of a decision-related action.

Actor:
The entity identified by "who" that claims to generate and sign a
JEP event.

Subject:
An entity referenced by an event, typically the person, agent,
object, or system about which a decision is made. A subject is
distinct from the actor.

Verifier:
An entity that evaluates event structure, signatures, references,
replay properties, extensions, and local policy.

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

JEP Signing Payload:
The UTF-8 octets of the JCS-canonicalized unsigned event. This
payload is supplied as the JWS Payload for detached JWS
processing.

Event Hash:
A protocol-level identifier calculated over the full signed event
object, including the "sig" member.

Acceptance Validation:
Verification performed when deciding whether to accept a newly
received event. This mode includes replay and timestamp freshness
checks.

Archival Validation:
Verification performed when evaluating a previously recorded event.
This mode does not reject an event solely because its timestamp is
outside the current freshness window.

Trust Profile:
A deployment-defined profile that binds actor identifiers and key
identifiers to verification keys and defines key rotation,
revocation, and historical validation rules.

Extension:
A named object inside the "ext" member that adds deployment-specific
or standardized semantics without changing the core JEP event
structure.

2. Protocol Model

2.1. Design Goals

JEP has the following design goals:

* Minimality: the core event object is small and stable.

* Verifiability: event integrity is protected by a detached JWS
signature over a JCS-canonicalized unsigned event.

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

* Global protocol interoperability: conforming implementations can
parse, canonicalize, sign, reference, and verify the same event
object.

* Policy neutrality: JEP records claims and evidence but does not
decide legal, organizational, or regulatory consequences.

* Long-term operability: the protocol distinguishes real-time
acceptance validation from archival validation.

2.2. Event Verbs

JEP defines four immutable core verbs:

Algorithm choice, signature capability, privacy mode, retention
policy, storage location, and identity resolution do not create new
verbs. Those properties are represented by JOSE headers, trust
profiles, or extensions.

2.3. Core Event Object

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

The "jep" member identifies the wire-format major version and is
fixed as the string "1" for this specification. The Internet-Draft
revision number is not the wire-format version.

The top-level extensibility mechanism is the "ext" member. Producers
SHOULD NOT define new top-level members outside this specification
unless those members are defined by a future JEP revision or a
registered JEP extension that explicitly updates the top-level event
object.

The following top-level members are used by JEP:

The "when" value is a JSON integer representing seconds since the Unix
epoch. It MUST be within the exact integer range permitted by I-JSON.

The "what" member:

* MUST be a non-null algorithm-tagged digest string for J, D, and T
events.

* MAY be null for V events when the event records only that a
verification action occurred.

* SHOULD be a non-null algorithm-tagged digest string for V events
that record a verification result or report.

The "ref" member:

* SHOULD be null for root J events.

* SHOULD reference the relevant prior event or lifecycle event for D
and T events.

* MUST be non-null for V events and SHOULD contain the event hash of
the event being verified.

The "aud" member is RECOMMENDED for acceptance validation. If present,
it MUST be included in the signed payload and MUST be checked by an
acceptance validator against the expected recipient or audience.

2.4. Algorithm-Tagged Digest Strings

JEP uses algorithm-tagged digest strings for "what", "ref", event
hashes, and extension integrity fields.

The syntax is:

<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 JEP-Core-1 MUST support "sha256". A
sha256 digest string contains exactly 64 hexadecimal characters after
the colon.

Example:

sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7

Deployments MAY define additional digest algorithms, such as regional
or post-quantum-adjacent profiles, if the algorithm identifier, digest
length, and verification rules are specified by the applicable trust
profile or registered extension.

This syntax is defined by this document for JEP interoperability.

2.5. Event Hashes and Reference Semantics

The event hash of a JEP event is calculated as follows:

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

where "full_signed_event" is the complete JEP event object including
the "sig" member.

The textual representation of the event hash is the algorithm-tagged
digest string:

sha256:<lowercase-hex-digest>

The signing input and the event hash are intentionally different:

* The signing input is the unsigned event with "sig" omitted.

* The event hash identifies the full signed event with "sig" included.

The "ref" member SHOULD contain the event hash of the referenced JEP
event unless a registered extension or trust profile explicitly defines
another reference scheme.

A reference chain proves cryptographic linkage between event objects.
It does not by itself prove that the chain is complete, append-only, or
free from omission. Append-only log semantics, transparency logs, or
storage-level guarantees are outside the JEP core scope.

2.6. Signing Input and Signature Container

JEP uses JSON Canonicalization Scheme (JCS) [RFC8785] and JSON Web
Signature (JWS) [RFC7515].

To create a JEP signature, a producer MUST perform the following
steps:

1. Construct the unsigned event object with all top-level members
except "sig".

2. Canonicalize the unsigned event object using JCS.

3. Encode the canonicalized unsigned event as UTF-8 octets. These
octets are the JEP signing payload.

4. Supply the JEP signing payload as the JWS Payload.

5. Create a detached JWS over that payload according to JWS rules.

6. Insert the detached JWS into the "sig" member.

For JWS Compact Serialization, the detached payload form is used by
replacing the second segment with the empty string. The resulting
compact representation has the form:

BASE64URL(Protected) || "." || "." || BASE64URL(Signature)

For JWS JSON Serialization, the detached payload form is used by
omitting the "payload" member. The omitted payload is the JEP signing
payload.

For single-signature JEP-Core-1 events, "sig" SHOULD be a detached JWS
Compact Serialization string. For multi-signature or composite
signature profiles, "sig" MAY be a detached JWS JSON Serialization
object or another registered signature container defined by an
applicable profile.

The JWS Protected Header MUST contain "alg". The "alg" value "none"
MUST NOT be used. The JWS Protected Header SHOULD contain "kid".

A JEP-Core-1 producer MUST use the fully specified JOSE algorithm
identifier "Ed25519" for Ed25519 signatures. A JEP-Core-1 verifier
MUST support "Ed25519". A verifier MAY accept legacy "EdDSA" under a
local compatibility policy, but producers SHOULD NOT emit "EdDSA" for
JEP-Core-1 events.

A verifier MUST reject an event if the JOSE algorithm is unsupported,
prohibited by local policy, inconsistent with the resolved
verification key, or inconsistent with a critical cryptographic
extension.

2.7. Key Resolution and Trust Profiles

JEP does not define a global identity or trust framework.

The "who" member identifies the actor that claims to have generated
the event. The JWS "kid" header identifies the verification key used
for the signature.

A verifier MUST resolve "who" and "kid" to a verification key
according to an applicable trust profile. A trust profile MAY use DID
resolution, JWKS, X.509 certificates, public key hashes, local
configuration, or another mechanism.

A verifier MUST reject an event if the resolved key is not bound to
the actor identified by "who" under the applicable trust profile.

Trust profiles SHOULD define:

* Supported actor identifier forms.

* Key identifier syntax and key discovery.

* Binding rules between "who" and "kid".

* Key rotation handling.

* Revocation handling.

* Historical key validity for archival validation.

* Accepted algorithms and algorithm downgrade policy.

2.8. Anti-Replay and Validation Modes

Event initiators MUST generate a fresh UUIDv4 nonce [RFC9562] for each
event. Nonces MUST be generated using a cryptographically secure
random source.

For acceptance validation, a receiver MUST maintain a replay cache.
The replay cache scope MUST include "who" and "nonce". If "aud" is
present, the replay cache scope SHOULD include "aud" as well.

Unless otherwise configured by a trust profile, a freshness window of
plus or minus 300 seconds is RECOMMENDED for acceptance validation.

2.8.1. Acceptance Validation

Acceptance validation is used when a receiver decides whether to
accept a newly received event.

A verifier performing acceptance validation MUST:

1. Parse and validate the JSON event structure, including rejection
of duplicate member names.

2. Validate top-level field requirements for the event verb.

3. Reconstruct the unsigned event by omitting "sig".

4. Canonicalize the unsigned event using JCS.

5. Verify the detached JWS signature using the reconstructed JEP
signing payload.

6. Resolve "who" and "kid" according to the applicable trust profile.

7. Verify nonce uniqueness within the replay cache.

8. Verify that "when" falls within the configured freshness window.

9. Verify "aud" if present.

10. Verify "what" and "ref" syntax if present.

11. Process all extensions listed in "ext_crit".

12. Apply local verifier policy.

2.8.2. Archival Validation

Archival validation is used when a verifier evaluates a previously
recorded event.

A verifier performing archival validation MUST:

1. Parse and validate the JSON event structure, including rejection
of duplicate member names.

2. Validate top-level field requirements for the event verb.

3. Reconstruct the unsigned event by omitting "sig".

4. Canonicalize the unsigned event using JCS.

5. Verify the detached JWS signature using the reconstructed JEP
signing payload.

6. Verify the event hash if an expected event hash is supplied.

7. Verify "ref" chain integrity if applicable.

8. Resolve historical key validity according to the applicable trust
profile, if such information is available.

9. Process all extensions listed in "ext_crit".

10. Apply local verifier policy.

Archival validation MUST NOT reject an event solely because "when" is
outside the current freshness window.

2.9. Extension Framework

Extensions are represented by the optional "ext" member. The "ext"
member is a JSON object. Each member name inside "ext" is an extension
identifier.

The optional "ext_crit" member is an array of extension identifiers
that are critical to validation or interpretation.

The "ext" and "ext_crit" members, when present, are included in the
JEP signing payload.

If a verifier encounters an extension listed in "ext_crit" that it
does not understand or cannot process, it MUST reject the event.

If a verifier encounters an extension not listed in "ext_crit" that it
does not understand, it MAY ignore that extension.

Extension identifiers are stable identifiers. They are not required
to be dereferenceable.

Example:

{
"ext": {
"https://jep.org/ttl": {
"expires_at": 1774567890,
"expiry_action": "delete_plaintext_retain_hash"
}
},
"ext_crit": [
"https://jep.org/ttl"
]
}

2.10. Standard Extensions

This section defines standard JEP extensions. Each extension is
optional unless listed in "ext_crit" or required by a trust profile.

2.10.1. Digest-Only Anonymity Extension

Identifier: https://jep.org/priv/digest-only

Purpose: support pseudonymous actor or subject representation while
enabling traceability under a deployment-defined dispute or audit
process.

Example:

{
"https://jep.org/priv/digest-only": {
"identity_digest": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"digest_alg": "sha256",
"salt_holder": "did:example:escrow-1",
"salt_policy": "profile:example-dispute-resolution-v1",
"domain": "actor"
}
}

The "identity_digest" field MUST be an algorithm-tagged digest string.
The "domain" field SHOULD identify the digest domain, such as "actor"
or "subject", to support domain separation.

This extension supports pseudonymization. It does not guarantee legal
anonymity. Privacy depends on salt confidentiality, salt entropy,
domain separation, and the entropy of the underlying identifier.

2.10.2. Multi-Signature Extension

Identifier: https://jep.org/multisig

Purpose: record collaborative decisions or approvals involving
multiple parties, enabling distributed accountability.

Example:

{
"https://jep.org/multisig": {
"mode": "threshold",
"threshold": 2,
"participants": [
"did:example:a#key-1",
"did:example:b#key-1",
"did:example:c#key-1"
]
}
}

If this extension is listed in "ext_crit", a verifier MUST verify that
at least "threshold" valid signatures over the same JEP signing payload
correspond to the participant list.

A critical multisig event MUST use JWS JSON Serialization or another
registered signature container capable of representing multiple
signatures over the same JEP signing payload.

2.10.3. Time-to-Live Extension

Identifier: https://jep.org/ttl

Purpose: express lifecycle metadata for plaintext data or linked
evidence.

Example:

{
"https://jep.org/ttl": {
"expires_at": 1774567890,
"expiry_action": "delete_plaintext_retain_hash",
"retained_evidence": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
}
}

The "expires_at" field is a Unix timestamp in seconds. The
"expiry_action" field describes a declared action, such as
"delete_plaintext_retain_hash" or
"anonymize_plaintext_retain_hash".

TTL metadata can support data-retention workflows. JEP does not
guarantee physical deletion, legal compliance, or fulfillment of any
particular data-subject right.

2.10.4. Sovereign Storage Extension

Identifier: https://jep.org/storage

Purpose: identify where related content or evidence may be stored,
while decoupling JEP from any particular storage vendor.

Example:

{
"https://jep.org/storage": {
"adapter_type": "uri",
"storage_address": "https://storage.example/object/123",
"integrity_hash": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"jurisdiction": "optional-string"
}
}

This extension identifies storage metadata. JEP does not endorse or
validate any storage provider, jurisdiction, or data sovereignty claim.

2.10.5. Subject Reference Extension

Identifier: https://jep.org/subject

Purpose: identify the subject of a decision to improve traceability
transparency.

Example:

{
"https://jep.org/subject": {
"id_type": "did",
"id": "did:example:user-123",
"privacy_mode": "plaintext"
}
}

Example using pseudonymous representation:

{
"https://jep.org/subject": {
"id_type": "salted_digest",
"id": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"privacy_mode": "pseudonymous"
}
}

A subject reference is informational. It does not imply consent,
authorization, legal responsibility, or correctness of the referenced
identity.

2.10.6. Cryptographic Profile Extension

Identifier: https://jep.org/crypto/profile

Purpose: declare cryptographic capabilities or preferences of an
issuer, system, or event so that verifiers can discover signature
surface, canonicalization profile, and hash family without changing
event verbs.

Example:

{
"https://jep.org/crypto/profile": {
"scope": "issuer",
"profile_id": "did:example:agent-789#crypto-profile-2026-04",
"signature_capability": "composite",
"signature_schemes": [
"Ed25519",
"ML-DSA-65"
],
"composite_rule": "all-of",
"canonicalization_profile": "jcs-rfc8785",
"hash_family": [
"sha256"
],
"valid_from": 1742340000,
"valid_until": null
}
}

The "signature_capability" value MUST be one of the values registered
in the JEP Signature Capability Values Registry. Initial values are
"classical", "post_quantum", and "composite".

Absence of this extension means that cryptographic capability is
undeclared. Security-sensitive verifiers SHOULD apply local policy
rather than assuming undeclared capability is equivalent to classical
capability.

The cryptographic profile extension is descriptive unless it is listed
in "ext_crit" or made normative by an applicable trust profile.

JEP does not require post-quantum cryptography. JEP does not
prescribe which signature capability a verifier must accept.

"composite" is distinct from "post_quantum". The distinction reflects
a different cryptographic failure model, not merely a nominal security
level.

Multi-signature and composite signature are distinct mechanisms.
Multi-signature distributes accountability across multiple actors or
keys. Composite signature combines multiple cryptographic schemes for
a single issuer or signing identity. Implementations MUST NOT treat a
multisig threshold rule as equivalent to a composite cryptographic
rule unless an applicable profile explicitly defines such equivalence.

2.11. Conformance Profiles

2.11.1. JEP-Core-1

A JEP-Core-1 producer MUST generate events with:

* "jep" equal to "1".

* A verb equal to "J", "D", "T", or "V".

* I-JSON compatible JSON.

* JCS canonicalization.

* Detached JWS Compact Serialization for single signatures.

* JOSE "alg" equal to "Ed25519".

* Algorithm-tagged digest strings using "sha256".

* UUIDv4 nonces.

* Correct event hash and "ref" semantics when references are used.

* "ext" and "ext_crit" semantics when extensions are present.

A JEP-Core-1 verifier MUST support:

* Parsing and validation of JEP event objects.

* Duplicate JSON member rejection.

* JCS canonicalization.

* Detached JWS Compact Serialization verification.

* JOSE "alg" equal to "Ed25519".

* Algorithm-tagged digest strings using "sha256".

* UUIDv4 nonce syntax.

* Event hash calculation.

* Acceptance validation.

* Archival validation.

* Unknown critical extension rejection.

2.11.2. JEP-Multisig-1

A JEP-Multisig-1 implementation MUST support:

* The https://jep.org/multisig extension.

* JWS JSON Serialization for multiple signatures over the same JEP
signing payload, or another registered equivalent container.

* Threshold validation.

* Participant key binding according to the applicable trust profile.

2.11.3. JEP-Crypto-Profile-1

A JEP-Crypto-Profile-1 implementation MUST support:

* The https://jep.org/crypto/profile extension.

* "signature_capability".

* "signature_schemes".

* "canonicalization_profile".

* "hash_family".

* "scope".

2.11.4. JEP-PQC-1

JEP-PQC-1 is an optional deployment profile. It is not part of
JEP-Core-1.

A JEP-PQC-1 profile SHOULD use registered JOSE algorithm identifiers
for post-quantum signatures, such as ML-DSA algorithm identifiers
registered for JOSE. The profile MUST define verification rules,
accepted algorithms, key representation, and downgrade policy.

2.11.5. Regional Cryptographic Profiles

Regional cryptographic profiles MAY define additional algorithms,
digest identifiers, or key resolution rules, such as SM2/SM3 profiles.
Such profiles MUST define their algorithm identifiers, digest syntax,
key representation, and verifier policy sufficiently for independent
implementation.

3. Security and Privacy Considerations

3.1. Core Security Properties

A valid JEP signature proves that the signed event payload was signed
by a key resolved under the applicable trust profile. It does not
prove that the event content is true, legally effective, authorized,
compliant, or complete.

The "sig" member protects event integrity for all signed fields in the
unsigned event, including "ext" and "ext_crit" when present. Any
modification to those fields invalidates the signature.

The "event_hash" identifies a particular full signed event object. It
does not prove that no other event was omitted from a log.

JEP does not provide confidentiality. Sensitive data requires
transport protection, object encryption, JWE [RFC7516], or another
confidentiality control.

3.2. Threat Model and Non-Goals

Replay attacks:
Acceptance validators MUST enforce nonce uniqueness within the
configured replay cache and freshness window.

Archival validation:
Archival validators MUST NOT reject an event solely because it is
outside the current freshness window.

Algorithm downgrade:
Verifiers MUST enforce local algorithm policy and reject prohibited
or unsupported algorithms.

Extension downgrade:
Critical extensions listed in "ext_crit" MUST be understood and
processed. Unknown critical extensions MUST cause rejection.

Key compromise:
Key compromise, rotation, and revocation are handled by trust
profiles. JEP does not define a global revocation system.

Identity substitution:
Verifiers MUST ensure that the resolved "kid" is bound to "who"
according to the applicable trust profile.

Log truncation and omission:
JEP references can link events but do not guarantee append-only
logging, completeness, or non-equivocation.

Timestamp manipulation:
The "when" value is an actor-supplied timestamp. Trust profiles or
external timestamping systems can provide stronger time evidence.

Legal and policy decisions:
JEP records verifiable event evidence. It does not determine legal
liability, consent, authorization validity, delegation validity, or
regulatory compliance.

3.3. Verification Limits under Partial Observation

A JEP event can be structurally valid and signature-valid while still
being insufficient to determine an external target fact. In partially
observed causal systems, multiple real histories can yield the same
observed log projection while differing on the target fact of interest
[TARGET-DETERMINABILITY].

Verifiers therefore need external evidence policies, trust profiles,
and domain-specific procedures when using JEP events for audit,
accountability, or dispute-resolution decisions. Archival validation
checks the integrity and linkage of recorded events; it does not
establish that the available observations are complete or
determinative.

3.4. Extension Security Considerations

Digest-only anonymity:
Privacy depends on salt confidentiality, salt entropy, domain
separation, and identifier entropy. Low-entropy identifiers can be
vulnerable to dictionary attacks.

Multi-signature:
Implementations need to protect against malicious key substitution,
participant-list ambiguity, and threshold downgrade.

TTL:
TTL declares lifecycle metadata but does not enforce physical
deletion. Deletion workflows can retain verifiable hashes or logs,
depending on policy.

Storage:
Security of external storage is outside the JEP core scope.
Storage integrity SHOULD be checked using digest fields.

Subject reference:
Subject references can expose personal or sensitive information.
Deployers SHOULD minimize subject identifiers and use pseudonymous
representations when appropriate.

Cryptographic profile:
A cryptographic profile can help verifiers discover algorithm
capability, but it does not replace actual signature verification
or local algorithm policy.

3.5. Privacy and Data Minimization

Deployers SHOULD minimize directly identifying information in event
objects. When direct identifiers are not required, deployers SHOULD
consider digest-only or pseudonymous extensions.

The subject reference extension SHOULD be enabled only when necessary
to support transparency, auditability, or dispute resolution.

TTL metadata can support retention workflows but MUST NOT be described
as a guarantee of legal compliance or physical deletion.

4. IANA Considerations

4.1. JEP Verbs Registry

IANA is requested to create the "JEP Verbs Registry".

The registration policy is IETF Review.

New verb registrations are NOT RECOMMENDED. A new verb registration
requires an RFC that updates this specification and explains why the
semantics cannot be represented by an existing verb plus a registered
extension.

Registration template:

* Value:

* Name:

* Description:

* Reference:

* Change controller:

* Security considerations:

* Privacy considerations:

Initial registrations:

4.2. JEP Extensions Registry

IANA is requested to create the "JEP Extensions Registry".

The registration policy is Specification Required [RFC8126].

Registration template:

* Extension identifier:

* Short name:

* Description:

* Specification URI:

* Criticality allowed: yes/no

* Required fields:

* Optional fields:

* Validation impact:

* Security considerations:

* Privacy considerations:

* Change controller:

Initial registrations:

4.3. JEP Signature Capability Values Registry

IANA is requested to create the "JEP Signature Capability Values
Registry".

The registration policy is Specification Required [RFC8126].

Registration template:

* Value:

* Description:

* Reference:

* Security considerations:

Initial registrations:

4.4. JEP Conformance Profiles Registry

IANA is requested to create the "JEP Conformance Profiles Registry".

The registration policy is Specification Required [RFC8126].

Registration template:

* Profile name:

* Description:

* Required features:

* Specification URI:

* Security considerations:

* Privacy considerations:

Initial registrations:

5. Normative References

[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
May 2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.

[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.

[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562,
May 2024, <https://www.rfc-editor.org/info/rfc9562>.

[RFC9864] Jones, M. B. and O. Steele, "Fully-Specified Algorithms
for JSON Object Signing and Encryption (JOSE) and CBOR
Object Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/info/rfc9864>.

6. Informative References

[DID-CORE]
W3C, "Decentralized Identifiers (DIDs) v1.0",
W3C Recommendation, July 2022,
<https://www.w3.org/TR/did-core/>.

[FIPS204] National Institute of Standards and Technology,
"Module-Lattice-Based Digital Signature Standard",
FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024.

[TARGET-DETERMINABILITY]
Wang, Y., "Target Determinability under Partial Causal
Observation: A Faithful Reduction Framework", Zenodo,
Version v1, DOI 10.5281/zenodo.19678205, April 2026,
<https://doi.org/10.5281/zenodo.19678205>.

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446,
August 2018, <https://www.rfc-editor.org/info/rfc8446>.

Appendix A. Examples and Test Vectors

This appendix provides a signed JEP-Core-1 example. The test vector
uses fixed Ed25519 private keys for reproducibility. Production
systems MUST NOT use these keys.

A.1. Public Keys

Actor public JWK:

{
"kty": "OKP",
"crv": "Ed25519",
"kid": "did:example:agent-789#key-1",
"x": "A6EHv_POEL4dcN0Y50vAmWfk1jCbpQ1fHdyGZBJVMbg"
}

Verifier public JWK:

{
"kty": "OKP",
"crv": "Ed25519",
"kid": "did:example:verifier-123#key-1",
"x": "Kay64UG8yvCyLhqU000LxzYeUm0L_hLIl5S8kyKWbdc"
}

A.2. Signed Judgment Event

The following event uses detached JWS Compact Serialization in "sig":

{
"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,
"ext": {
"https://jep.org/crypto/profile": {
"scope": "issuer",
"signature_capability": "classical",
"signature_schemes": [
"Ed25519"
],
"canonicalization_profile": "jcs-rfc8785",
"hash_family": [
"sha256"
]
}
},
"sig": "eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiZGlkOmV4YW1wbGU6YWdlbnQtNzg5I2tleS0xIn0..toFm0eHSPXiSdy3CM6U0HXM93b3JACjyOM6hjdxMG4NXB85mcdxUS74a4GO9bZ-ahFKNVDoKTEXWK9UhPfYRBA"
}

Event hash:

sha256:1ea7989431a7f21cfcd5300284c4f6dcdcff885ba004942654aeb5916ddf2558

A.3. Signed Verification Event

The following V event references the event hash of the judgment event:

{
"jep": "1",
"verb": "V",
"who": "did:example:verifier-123",
"when": 1742345680,
"what": "sha256:11433ad3dd3794f3607bef1c13b5a68939df8753dbcf4b79ebe66f64010b8e25",
"nonce": "a1b2c3d4-5678-4abc-8ef0-123456789abc",
"aud": "https://platform.example.com",
"ref": "sha256:1ea7989431a7f21cfcd5300284c4f6dcdcff885ba004942654aeb5916ddf2558",
"sig": "eyJhbGciOiJFZDI1NTE5Iiwia2lkIjoiZGlkOmV4YW1wbGU6dmVyaWZpZXItMTIzI2tleS0xIn0..UpB0JKwtHYXvcrGeBd8EFJsEN0iE5c_s9YyO5QRdqboDDysq5EFPd3G42OxbSRSVn4z4h4aWtKN0kYK7mIqnDQ"
}

Event hash:

sha256:34affe990f7f09e5a623f66f80d318fad861346fc2064d8a454ff512a30738c8

A.4. Canonicalization Note

To verify the examples, remove the "sig" member, canonicalize the
remaining event object using JCS, and supply the resulting UTF-8 octets
as the detached JWS payload. Reconstruct the JWS signing input
according to RFC 7515.

Appendix B. Changes from -04

The following major changes were made from
draft-wang-jep-judgment-event-protocol-04 to this revision:

* Clarified the JEP signing input and adopted detached JWS semantics.

* Defined event hash calculation and reference semantics.

* Split validation into acceptance validation and archival validation.

* Clarified required, recommended, optional, and verb-specific
fields.

* Replaced ambiguous multihash language with algorithm-tagged
digest strings.

* Added key resolution and trust profile requirements.

* Added "ext" and "ext_crit" extension container semantics.

* Added minimal schemas for standard extensions.

* Added the cryptographic profile extension for signature capability,
canonicalization profile, and hash family.

* Distinguished multi-signature from composite signature.

* Added conformance profiles.

* Expanded security and privacy considerations.

* Added an informative reference and security-boundary note on
target determinability under partial causal observation.

* Expanded IANA registration templates and expert guidance.

* Updated normative and informative references.

Author's Address

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

Document	Document type	This is an older version of an Internet-Draft whose latest revision state is "Active". This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.
	Select version	00 01 02 03 04 05 06
	Compare versions
	Author	yuqiang wang
	Replaces	draft-wang-hjs-judgment-event
	RFC stream	(None)
	Other formats	txt bibtex bibxml