Internet-Draft Y. Wang draft-wang-jep-judgment-event-protocol-01 HJS Foundation Ltd. Intended status: Experimental 20 March 2026 Expires: 20 September 2026 Judgment Event Protocol (JEP) 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-01/. 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. 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, and may be used either natively or as a foundation for extended accountability, audit, and decision provenance frameworks. Table of Contents 1. Introduction ............................................... 4 2. Protocol Model ............................................. 5 3. Security Considerations ................................... 9 4. IANA Considerations ...................................... 10 5. Normative References ..................................... 10 Author's Address ............................................. 11 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. 1.2. Scope The Judgment Event Protocol (JEP) defines: - A set of basic judgment event verbs - A minimal signed event format - Replay protection using nonce and timestamp - Standardized signature and verification rules JEP does NOT define: - Accountability structure or liability rules - Delegation validity or authorization chains - State machines or lifecycle enforcement - Multi-layer privacy architecture - Cryptographic erasure - Dispute detection or resolution - Governance or compliance logic JEP may be used natively for basic event recording, or incorporated into extended frameworks that add accountability, audit, privacy, or decision provenance capabilities. 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. 3. Security Considerations 3.1. Replay Attacks Without nonce caching and uniqueness enforcement, JEP events can be fraudulently replayed. All implementations MUST reject duplicate nonces. 3.2. Tampering JEP events are cryptographically signed; any modification invalidates the signature. 3.3. Confidentiality JEP does not provide encryption. Sensitive events SHOULD be transmitted over TLS or encrypted using JWE. 3.4. Algorithm Agility Ed25519 is RECOMMENDED. ECDSA P-256, SM2, and post-quantum algorithms are permitted. 3.5. Randomness Requirements Nonce generation MUST use cryptographically secure randomness to prevent prediction and collision attacks. 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. Extension Registry IANA is requested to create a "Judgment Event Protocol (JEP) Extensions" registry for future compatible extensions. The registration policy for this registry is Specification Required. 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs", BCP 14. [RFC7515] Jones, M., "JSON Web Signature (JWS)". [RFC8174] Leiba, B., "Ambiguity in RFC 2119 Keywords", BCP 14. [RFC8785] Rundgren, et al., "JSON Canonicalization Scheme". [RFC9122] Maheshwari, H., "Multihash Format". [RFC9562] Davis, D., et al., "Universally Unique IDentifiers (UUIDs)". Author's Address Yuqiang Wang HUMAN JUDGMENT SYSTEMS FOUNDATION LTD. Email: signal@humanjudgment.org GitHub: https://github.com/hjs-spec