Internet-Draft Y. Wang draft-wang-jep-judgment-event-protocol-02 Intended status: Experimental 29 March 2026 Expires: 30 September 2026 Judgment Event Protocol (JEP) draft-wang-jep-judgment-event-protocol-02 Abstract This document specifies the Judgment Event Protocol (JEP), a minimal, verifiable format for logging judgment-related actions in distributed systems. It defines four immutable event verbs (J, D, T, V), a signed JSON event structure with replay protection, and standardized signature verification rules. The protocol is designed to be interoperable across platforms and autonomous agents. A set of optional, standard extensions are defined to enhance privacy, distribute responsibility, respect data lifecycles, and ensure data sovereignty, making the protocol adaptable to diverse legal and cultural contexts. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html. Information about the current status of this document, updates, and revisions is available at https://datatracker.ietf.org/doc/draft-wang-jep-judgment-event-protocol-02/. 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ............................................... 4 1.1. Motivation ............................................. 4 1.2. Scope .................................................. 4 1.3. Requirements Language .................................. 5 1.4. Terminology ............................................ 5 2. Protocol Model ............................................. 6 2.1. Event Primitives ....................................... 6 2.2. Core Event Format ...................................... 6 2.3. Replay Protection ...................................... 7 2.4. Signature and Verification ............................. 7 2.5. Standard Extensions for Real-World Adoption ............ 8 2.5.1. Digest-Only Mode Extension (Privacy) ................ 8 2.5.2. Multi-Signature Extension (Shared Responsibility) ... 9 2.5.3. Time-To-Live Extension (Data Lifecycle) ............ 10 2.5.4. Sovereign Storage Adapter (Data Sovereignty) ....... 10 3. Security and Privacy Considerations ....................... 11 3.1. Core Security Guarantees .............................. 11 3.2. Security of Extensions ................................ 11 3.3. Privacy and Data Minimization ......................... 12 4. IANA Considerations ....................................... 12 4.1. JEP Verbs Registry .................................... 12 4.2. JEP Extensions Registry ............................... 13 5. Normative References ...................................... 13 Author's Address .............................................. 14 1. Introduction 1.1. Motivation As distributed systems and autonomous agents operate across platforms and domains, a minimal, standard, secure format is needed to log and verify judgment actions. The Judgment Event Protocol (JEP) fills this gap with a compact, verifiable, and interoperable event record. Recognizing that technical standards must operate within diverse human, legal, and political contexts, this document also defines a set of optional extensions. These extensions are designed to address core concerns related to privacy, shared responsibility, data lifecycle management, and data sovereignty, thereby enhancing the protocol's real-world adoptability. 1.2. Scope The Judgment Event Protocol (JEP) defines: - A set of basic judgment event verbs (J, D, T, V) - A minimal signed event format - Replay protection using nonce and timestamp - Standardized signature and verification rules - A framework for optional, standard extensions JEP core does NOT define: - Accountability structure or liability rules - Delegation validity or authorization chains - State machines or lifecycle enforcement - Governance or compliance logic The standard extensions defined in Section 2.5 provide optional building blocks for these higher-level functions, but their implementation and interpretation remain the responsibility of the adopting system. 1.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. 1.4. Terminology o Event: A single observable judgment-related action o Actor: Entity that generates and signs the event o Nonce: A unique value to prevent replay attacks o Verifier: Entity that checks signature and validity 2. Protocol Model 2.1. Event Primitives JEP defines four immutable event verbs: o J (Judge): A judgment was created o D (Delegate): A judgment authority was transferred o T (Terminate): A judgment lifecycle was ended o V (Verify): An existing event was verified The V (Verify) verb SHOULD reference the target event via the optional 'ref' field to avoid circular dependencies and ambiguous verification semantics. 2.2. Core Event Format A valid JEP event MUST contain these top-level fields: - jep: Protocol version (MUST be "1") - verb: One of [J, D, T, V] - who: Actor identifier (URI, DID, or public key hash) - when: Unix timestamp (seconds since epoch) - what: Multihash [RFC9122] of judgment content (RECOMMENDED) - nonce: UUIDv4 unique identifier [RFC9562] - aud: Intended audience (domain/identifier, RECOMMENDED) - sig: Digital signature over canonicalized JSON - ref: For V (Verify) events: hash/ID of verified event (OPTIONAL) Example JEP Event: { "jep": "1", "verb": "J", "who": "did:example:agent-789", "when": 1742345678, "what": "122059e8878aa9a38f4d123456789abcdef01234", "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "aud": "https://platform.example.com", "sig": "eyJhbGciOiJFZERTQSJ9..." } Example Verify Event: { "jep": "1", "verb": "V", "who": "did:example:verifier-123", "when": 1742345680, "what": null, "nonce": "a1b2c3d4-5678-4abc-8ef0-123456789abc", "aud": "https://platform.example.com", "ref": "122059e8878aa9a38f4d123456789abcdef01234", "sig": "eyJhbGciOiJFZERTQSJ9..." } 2.3. Replay Protection To prevent replay attacks: 1. The issuer MUST generate a new UUIDv4 nonce for every event. 2. Nonce MUST be created with a cryptographically secure random generator to ensure unpredictability. 3. The receiver MUST cache and reject duplicate nonces. 4. A clock skew tolerance of +/-5 minutes (300 seconds) is RECOMMENDED if not explicitly configured. 5. The 'aud' field SHOULD bind events to specific recipients. 2.4. Signature and Verification JEP uses: o JSON Canonicalization Scheme (JCS) [RFC8785] o JSON Web Signature (JWS) Compact [RFC7515] Verification Steps: 1. Parse and validate JSON structure. 2. Verify JWS signature using the actor's public key. 3. Ensure nonce is unique and not previously seen. 4. Ensure timestamp is within acceptable time window. 5. Ensure audience matches if specified. 6. If 'ref' is present, validate its format as a reference. 7. Return VALID or INVALID. 2.5. Standard Extensions for Real-World Adoption To enhance the protocol's utility and acceptance across different legal, cultural, and technical environments, the following optional extensions are defined. These extensions are registered with IANA and are designed to be independent and modular. 2.5.1. Digest-Only Mode Extension (Privacy) This extension allows for the pseudonymization of the actor's identity in day-to-day operations, while preserving the ability to authenticate it during disputes or audits. * Identifier: https://jep.org/priv/digest-only * Compatibility: full * Fields: - identity_digest: A salted hash of the actor's canonical identifier. - salt_provider: An optional reference to the entity holding the salt (e.g., a DID). * Verification: A verifier cannot reverse the digest without the salt. The authenticity of the identity_digest is established through the JWS signature, which is created using the actor's private key corresponding to the hashed identifier. * Example: { "https://jep.org/priv/digest-only": { "identity_digest": "sha256:8b39f3c7d5e9...", "salt_provider": "did:example:user-org" } } 2.5.2. Multi-Signature Extension (Shared Responsibility) This extension records that a judgment event is the result of a collaborative decision involving multiple actors, distributing responsibility. * Identifier: https://jep.org/multisig * Compatibility: wire * Fields: - threshold: The minimum number of signatures required for the event to be considered valid. - signers: An ordered list of actor identifiers (DIDs or public key hashes) who participated in the signature. - aggregated_sig: The aggregated digital signature (e.g., using BLS multisignature scheme). * Verification: The verifier MUST check that the aggregated_sig is a valid aggregation of signatures from at least threshold distinct signers listed in the signers array. * Example: { "https://jep.org/multisig": { "threshold": 2, "signers": ["did:example:alice", "did:example:bob", "did:example:charlie"], "aggregated_sig": "bls:89ab3c4d..." } } 2.5.3. Time-To-Live Extension (Data Lifecycle) This extension allows the issuer to define a validity period for the plaintext information within an event, after which the data may be automatically purged or anonymized, retaining only a proof of existence. * Identifier: https://jep.org/ttl * Compatibility: full * Fields: - expiry: A Unix timestamp (seconds since epoch) after which the plaintext event data is considered expired. - expiry_action: An OPTIONAL field specifying the recommended action, such as retain_hash_only or archive. * Verification: Verifiers MAY check the expiry timestamp. However, the protocol does not mandate enforcement of data deletion. * Example: { "https://jep.org/ttl": { "expiry": 2042345678, "expiry_action": "retain_hash_only" } } 2.5.4. Sovereign Storage Adapter (Data Sovereignty) This extension defines a standard interface for storage backends, allowing JEP events to be stored in locations of the user's choice, decoupling the protocol from any specific storage provider or jurisdiction. * Identifier: https://jep.org/storage * Compatibility: wire * Fields: - adapter_type: The type of storage adapter (e.g., filesystem, s3, ipfs). - location: A URI or path indicating where the event is stored. - integrity_proof: An OPTIONAL field containing a hash or other proof of integrity for the stored event. * Verification: Verification of this extension is implementation-dependent. The core JEP protocol does not specify how to fetch or verify data from external storage adapters. * Example: { "https://jep.org/storage": { "adapter_type": "ipfs", "location": "ipfs://QmT5NvUy3n5jG...", "integrity_proof": "multihash:122059e8878a..." } } 3. Security and Privacy Considerations 3.1. Core Security Guarantees o Replay Attacks: Without nonce caching and uniqueness enforcement, JEP events can be fraudulently replayed. All implementations MUST reject duplicate nonces. o Tampering: JEP events are cryptographically signed; any modification invalidates the signature. o Confidentiality: JEP does not provide encryption. Sensitive events SHOULD be transmitted over TLS or encrypted using JWE [RFC7516]. o Algorithm Agility: Ed25519 is RECOMMENDED. ECDSA P-256, SM2, and post-quantum algorithms are permitted. o Randomness Requirements: Nonce generation MUST use cryptographically secure randomness to prevent prediction and collision attacks. 3.2. Security of Extensions Implementations of the standard extensions must consider their specific security properties: o Digest-Only Mode: The security of the pseudonymity relies on the secrecy and randomness of the salt. Loss of the salt makes the identity permanently unrecoverable. The JWS signature over the digest prevents impersonation. o Multi-Signature: The security depends on the underlying multisignature scheme (e.g., BLS). Implementations MUST ensure the scheme is resistant to rogue-key attacks. o Time-To-Live: This extension provides a declarative expiry. It does not provide cryptographic guarantees of deletion. Implementations that enforce deletion MUST ensure that the deletion process is cryptographically auditable (e.g., via a verifiable erase log). o Sovereign Storage: The security of the external storage system is out of scope for JEP. Users should ensure the chosen storage backend meets their integrity, confidentiality, and availability requirements. 3.3. Privacy and Data Minimization The Digest-Only Mode extension (Section 2.5.1) is the RECOMMENDED method for privacy-preserving event logging. Actors who require long-term auditability without continuous identity exposure SHOULD use this mode for routine operations. The TTL extension (Section 2.5.3) provides a mechanism to respect data retention policies and the "right to be forgotten." 4. IANA Considerations 4.1. JEP Verbs Registry IANA is requested to create a "Judgment Event Protocol (JEP) Verbs" registry. The registration policy for this registry is Expert Review. Initial entries are: +------+-------------------------------------+ | Verb | Description | +------+-------------------------------------+ | J | A judgment was created | | D | A judgment authority was transferred| | T | A judgment lifecycle was ended | | V | An existing event was verified | +------+-------------------------------------+ 4.2. JEP Extensions Registry IANA is requested to create a "Judgment Event Protocol (JEP) Extensions" registry. The registration policy for this registry is Specification Required. Initial entries are: +================================+=================+===================+ | Extension Identifier | Compatibility | Reference | +================================+=================+===================+ | https://jep.org/priv/digest-only| full | Section 2.5.1 | +--------------------------------+-----------------+-------------------+ | https://jep.org/multisig | wire | Section 2.5.2 | +--------------------------------+-----------------+-------------------+ | https://jep.org/ttl | full | Section 2.5.3 | +--------------------------------+-----------------+-------------------+ | https://jep.org/storage | wire | Section 2.5.4 | +--------------------------------+-----------------+-------------------+ 5. Normative References [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. [RFC7515] Jones, M., "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, https://www.rfc-editor.org/info/rfc7515. [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. [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. [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. [RFC9122] Maheshwari, H., "Multihash Format", RFC 9122, DOI 10.17487/RFC9122, July 2022, https://www.rfc-editor.org/info/rfc9122. [RFC9562] Davis, D., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, https://www.rfc-editor.org/info/rfc9562. Author's Address Yuqiang Wang Email: signal@humanjudgment.org GitHub: https://github.com/hjs-spec