Internet-Draft Y. Wang draft-wang-hjs-accountability-01 HJS Foundation Ltd. Intended status: Standards Track March 19, 2026 Expires: September 20, 2026 HJS: An Accountability Layer for AI Agents draft-wang-hjs-accountability-01 Abstract This document defines the Human Judgment Structure (HJS), a minimal and infrastructure‑grade accountability layer for AI agents, built on the Judgment Event Protocol (JEP) [draft-wang-jep-judgment-event-protocol-01]. HJS provides a cryptographic mechanism to manage and verify responsibility for AI agent judgment behaviors across heterogeneous platforms. Its core design consists of four primitives (Judge, Delegate, Terminate, Verify) inherited from JEP, a minimal receipt structure with responsibility chaining, and a three‑tier privacy architecture for accountability governance. All advanced features (state machines, compliance proofs, governance mechanisms) are defined as optional extensions or informative appendices, preserving the structure’s narrow‑waist stability and compatibility with 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). 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 September 20, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document MUST include the Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Core Accountability Model (Mandatory) . . . . . . . . . . . . 4 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Problem Statement . . . . . . . . . . . . . . . . . . 4 1.1.2. Design Goals . . . . . . . . . . . . . . . . . . . . 5 1.1.3. Relationship to JEP and IETF Ecosystem . . . . . . . 5 1.1.4. Terminology and Conventions . . . . . . . . . . . . 6 1.2. Model and Architecture . . . . . . . . . . . . . . . . . 6 1.2.1. Four Primitives (Inherited from JEP) . . . . . . . . 6 1.2.2. Core Receipt Fields (Reusing JEP Event Format) . . . 7 1.2.3. Three‑Tier Privacy Architecture . . . . . . . . . . 8 1.2.4. Signature and Chain Verification . . . . . . . . . . 9 1.3. Cryptographic Erasure (Accountability Compliance) . . . . 10 1.4. Security Considerations . . . . . . . . . . . . . . . . 10 1.4.1. Threat Model . . . . . . . . . . . . . . . . . . . . 10 1.4.2. Key Management . . . . . . . . . . . . . . . . . . . 11 1.4.3. Algorithm Agility . . . . . . . . . . . . . . . . . . 11 2. Optional Accountability Features (Optional Implementation) . . 12 2.1. Simplified State Machine . . . . . . . . . . . . . . . . 12 2.1.1. Basic States . . . . . . . . . . . . . . . . . . . . 12 2.1.2. Transition Rules . . . . . . . . . . . . . . . . . . 12 2.2. Extension Field Format . . . . . . . . . . . . . . . . . 13 2.2.1. Extension Object . . . . . . . . . . . . . . . . . . 13 2.2.2. IANA Registration Requirements . . . . . . . . . . . 13 3. Appendices (Informative) . . . . . . . . . . . . . . . . . . 14 Appendix A. Complete State Machine and Dispute Handling . . . 14 A.1. Full State Definitions . . . . . . . . . . . . . . . . 14 A.2. Dispute Detection and Resolution . . . . . . . . . . . 15 A.3. Federal Governance Extension . . . . . . . . . . . . . 15 Appendix B. Advanced Verification Modes . . . . . . . . . . . 16 B.1. Platform Mode . . . . . . . . . . . . . . . . . . . . 16 B.2. Dual Mode . . . . . . . . . . . . . . . . . . . . . . 16 B.3. Multi‑Source Time Consensus . . . . . . . . . . . . . . 17 Appendix C. Compliance and Regulatory Guidance . . . . . . . . 18 C.1. GDPR Mapping . . . . . . . . . . . . . . . . . . . . . 18 C.2. EU AI Act Mapping . . . . . . . . . . . . . . . . . . 19 C.3. Jurisdiction Marking Extension . . . . . . . . . . . . 19 C.4. GDPR Compliance Proof Extension . . . . . . . . . . . 20 C.5. AI Act Transparency Marking Extension . . . . . . . . . 20 Appendix D. Concrete Extension Definitions . . . . . . . . . . 21 D.1. TEE Evidence Format (Priority 1) . . . . . . . . . . . 21 D.2. Lightweight Mode (Priority 2) . . . . . . . . . . . . . 22 D.3. AIP Integration (Priority 2) . . . . . . . . . . . . . 22 D.4. Batch Operations (Priority 2) . . . . . . . . . . . . 23 D.5. Refusal Event (Priority 2) . . . . . . . . . . . . . . 23 D.6. Key Evolution (Priority 3) . . . . . . . . . . . . . . 24 D.7. Enhanced Hardware Binding (Priority 3) . . . . . . . . 24 D.8. Legal Validity Proof (Priority 4) . . . . . . . . . . 25 D.9. Federal Resolution (Priority 5) . . . . . . . . . . . . 26 Appendix E. Implementation Guide and Best Practices . . . . . 27 E.1. Minimal Implementation (Pseudocode) . . . . . . . . . . 27 E.2. Performance Benchmarks . . . . . . . . . . . . . . . . 28 E.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . 29 E.4. Cross‑Domain Deployment Recommendations . . . . . . . . 30 Appendix F. Examples . . . . . . . . . . . . . . . . . . . . 31 F.1. Judge Receipt Example . . . . . . . . . . . . . . . . 31 F.2. Error Code Reference . . . . . . . . . . . . . . . . . 32 Appendix G. References . . . . . . . . . . . . . . . . . . . . 33 G.1. Normative References . . . . . . . . . . . . . . . . . 33 G.2. Informative References . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Core Accountability Model (Mandatory) 1.1. Introduction 1.1.1. Problem Statement As AI agents become increasingly autonomous and pervasive in decision- making processes across industries, there is a critical need for a standardized, verifiable accountability framework to ensure non-repudiation, traceability, and compliance of AI-driven judgment actions. While the Judgment Event Protocol (JEP) [draft-wang-jep-judgment-event-protocol-01] provides a standard format for recording judgment events, it does not address accountability governance, responsibility chaining, or compliance with privacy regulations. This gap leads to unenforceable responsibility attribution and non-compliant data handling in cross- platform AI workflows, as illustrated by the multi-stage medical diagnosis example in [HJS-00]. 1.1.2. Design Goals HJS is designed with the following accountability-focused goals for AI agents: * Minimal integration cost: The structure acts as a thin governance plane on top of JEP, requiring only that JEP-compliant event generators enforce accountability rules. * Semantic accountability: HJS adds responsibility semantics to JEP primitives (e.g., Delegate = responsibility transfer, Terminate = accountability lifecycle end) while preserving JEP's neutrality. * Non‑repudiability: Accountability chains are self‑contained and can be verified offline without accessing the originating platform. * Progressive deployment: Implementations can start with a minimal subset (chain verification) and later adopt advanced features as needed. * Scope delimitation: HJS focuses solely on accountability governance for JEP-recorded AI judgment events. It does not modify JEP's core event format or signature logic. 1.1.3. Relationship to JEP and IETF Ecosystem HJS is a complementary accountability layer to JEP, built specifically for AI agents, and integrates with existing IETF standards: * Builds on JEP [draft-wang-jep-judgment-event-protocol-01] for core event formatting and primitive definitions. * SCITT [I‑D.ietf-scitt-architecture] may provide timestamp anchoring for accountability receipts (optional). * RATS [RFC9334] attestations can be embedded in Tier 2 (optional) to enhance accountability evidence for AI agents. * Identity frameworks (OAuth [RFC6749], DID [DID-CORE], AIP [AIP-CORE]) can be used to validate actor authorization in the `who` field (inherited from JEP). 1.1.4. Terminology and Conventions 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] when they appear in all capitals. Judgment: An atomic declaration made by an AI agent, possessing accountability effectiveness (as defined in JEP). Receipt: A cryptographically verifiable record of an AI judgment event (reusing JEP event format) with added accountability metadata. Actor: The entity (human or AI) initiating an AI judgment (inherited from JEP). Authorization chain: A sequence of JEP receipts linked by `based_on` fields, recording the flow of responsibility for AI agents (HJS-specific). Cryptographic erasure: The process of rendering Tier 3 content irrecoverable by destroying decryption keys (accountability compliance for AI systems). 1.2. Model and Architecture 1.2.1. Four Primitives (Inherited from JEP) HJS reuses JEP's four core operations and adds AI accountability semantics: * Judge: Create a new AI judgment (JEP primitive). Generates an initial receipt with `based_on = null`. The actor declares primary accountability for the AI decision. * Delegate: Transfer responsibility to another AI agent/human (JEP primitive). Requires an acceptance signature from the delegatee and validation of the delegatee's authorization (HJS-specific). * Terminate: Conclude the AI accountability lifecycle (JEP primitive). Supports two modes (HJS-specific): - `ARCHIVED` (all tiers retained for audit) - `ERASED` (Tier 3 content erased for compliance). * Verify: Independently attest to the validity of an AI accountability chain (extended from JEP primitive). May be used for audit or real‑time checks of responsibility attribution for AI agents. These primitives are the only operations that modify or inspect the accountability state, and are fully compatible with JEP's event format. 1.2.2. Core Receipt Fields (Reusing JEP Event Format) Every HJS accountability receipt MUST reuse JEP's core fields (as defined in [draft-wang-jep-judgment-event-protocol-01]) and add a `based_on` field for AI responsibility chaining: +-------------+---------------------------------------------------+ | Field | Description (AI Accountability Semantics) | +-------------+---------------------------------------------------+ | verb | JEP operation primitive: "J", "D", "T", "V" | +-------------+---------------------------------------------------+ | who | AI agent/human actor identifier URI (DID/URI) | +-------------+---------------------------------------------------+ | when | Unix timestamp (seconds since epoch) | +-------------+---------------------------------------------------+ | what | Hash of the AI judgment content. The hash itself | | | is public, but the actual content is stored | | | externally under the actor’s control. | +-------------+---------------------------------------------------+ | based_on | Hash of the parent JEP receipt (null for initial).| | | Provides AI accountability chain integrity. | +-------------+---------------------------------------------------+ | nonce | Globally unique identifier (UUID [RFC9562]) to | | | prevent replay attacks (inherited from JEP). | +-------------+---------------------------------------------------+ | signature | Digital signature over the canonical JSON | | | representation of all preceding fields (per JEP).| +-------------+---------------------------------------------------+ | time_anchor | (Optional but RECOMMENDED) Reference to an | | | external time‑anchoring service (e.g., SCITT | | | entry ID) for AI accountability timestamp validity.| +-------------+---------------------------------------------------+ These fields answer the fundamental AI accountability questions: who (AI agent), when, what (AI decision), why (verb), based on what (responsibility chain), how to prevent replay, how to prove authenticity, and how to secure time. 1.2.3. Three‑Tier Privacy Architecture (HJS-Specific for AI) JEP core fields are organized into three tiers by HJS according to AI accountability visibility requirements: * Tier 1 (Public Governance): Contains fields that MUST be publicly accessible for basic AI accountability verification: `verb`, `who`, `nonce`, and optionally `when`. These are placed in the JWS Protected Header (per JEP's signature format). * Tier 2 (Logical Accountability): Contains fields required for AI audit and authorization: `based_on`, `time_anchor`, and any extension fields carrying audit evidence. These are placed in the JWS Payload (per JEP), which MAY be encrypted for limited access. * Tier 3 (Private Payload): Contains the `what` field (content hash, per JEP). The hash itself is public, but the actual content is stored externally under the AI agent’s control. When cryptographic erasure is performed (HJS), the key to decrypt the external content is destroyed, leaving only the hash as a tombstone for AI accountability. This architecture ensures that each party can access only the information necessary for its AI accountability role, in line with data minimization principles for AI systems. 1.2.4. Signature and Chain Verification (Extended from JEP) HJS reuses JEP's JWS Compact Serialization [RFC7515] and adds chain-level verification for AI accountability: BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature) The Protected Header contains Tier 1 fields plus JWS‑specific parameters (e.g., `alg`, per JEP). The Payload contains Tier 2 and Tier 3 fields, possibly encrypted using JWE [RFC7516] (per JEP). HJS Chain Verification Algorithm (extends JEP's basic verification): 1. Parse the JWS structure (per JEP verification step 1). 2. Verify the signature using the actor’s public key (per JEP step 2). 3. Decrypt the Payload if necessary (per JEP step 3). 4. Verify that the hash of the parent receipt matches `based_on` (HJS-specific AI chain check). 5. Check that the timestamp is within the configured tolerance window (using `time_anchor` if present, per JEP step 5). 6. Validate authorization for all Delegate events in the AI chain (HJS-specific accountability check). 7. Return `VALID` if all checks pass, otherwise `INVALID` or `DISPUTED`. This process requires no online dependencies beyond the public key infrastructure needed to resolve the `who` URI (per JEP) and authorization lists (HJS-specific for AI agents). 1.3. Cryptographic Erasure (AI Accountability Compliance) To support privacy regulations such as the GDPR "right to be forgotten" (a core AI accountability requirement), HJS defines a cryptographic erasure mechanism for JEP receipts. When a `Terminate` operation is performed with mode `ERASED`, the AI agent destroys the encryption key that protects the external content referenced by the `what` hash (per JEP's `what` field definition). The JEP receipt remains, but the AI decision content becomes computationally unrecoverable. A Proof of Key Destruction (PKD) MAY be included in the receipt to provide evidence of compliance with AI accountability obligations. The three‑tier architecture ensures that even after erasure, Tier 1 and Tier 2 data remain intact for AI audit purposes. 1.4. Security Considerations 1.4.1. Threat Model HJS assumes the same semi‑trusted network environment as JEP and defends against additional AI accountability-specific threats: * Insider attackers: Malicious AI agents/humans delegating to evade responsibility or forging authorization evidence (HJS-specific). * External attackers: Intercepting and replaying receipts (inherited from JEP), or traffic analysis from Tier 1 metadata (HJS-specific). * Computational threats: Future quantum attacks against current signature algorithms (shared with JEP). Trust assumptions: Actors are responsible for private key security (per JEP); time sources are partially trusted within a tolerance window (per JEP); optional anchoring services (e.g., SCITT) are trusted for AI accountability timestamp validity (HJS-specific). 1.4.2. Key Management * Signature keys SHOULD be stored in hardware trust roots (HSM, TEE) and rotated periodically (RECOMMENDED yearly, per JEP). * Encryption keys for Tier 3 AI content (HJS-specific) MAY be managed externally and MUST be destroyed for `ERASED` termination mode. * In case of key compromise, the affected actor MUST issue a `Terminate` receipt (per JEP's `Terminate` primitive) to logically invalidate all receipts signed with that key after a certain timestamp (HJS-specific AI accountability rule). 1.4.3. Algorithm Agility HJS inherits JEP's support for multiple signature algorithms, including Ed25519, ECDSA P‑256, SM2, and future post‑quantum algorithms (e.g., Dilithium, Falcon). Implementations SHOULD monitor NIST standardization progress and be prepared to migrate when necessary to maintain long-term AI accountability chain integrity. 2. Optional Accountability Features (Optional Implementation) This section describes accountability-enhancing features for AI agents that are not required for basic interoperability with JEP but can be implemented to enhance governance functionality. 2.1. Simplified State Machine 2.1.1. Basic States Implementations that wish to track the AI accountability lifecycle of a JEP-recorded judgment MAY use the following minimal state machine: * ACTIVE: AI judgment created, responsibility held by current actor. * DELEGATING: Delegation initiated, awaiting acceptance (HJS-specific). * DELEGATED: Responsibility successfully transferred (HJS-specific). * TERMINATED: Lifecycle ended (archived or erased, per HJS). 2.1.2. Transition Rules * `Judge` (JEP primitive) → ACTIVE * `Delegate` (initiation, JEP primitive) → DELEGATING * `Delegate` (acceptance, JEP primitive) → DELEGATED (if in DELEGATING) * `Terminate` (JEP primitive) → TERMINATED (from ACTIVE, DELEGATING, or DELEGATED) * Timeout: If no acceptance is received within a configurable window, DELEGATING automatically reverts to ACTIVE (HJS-specific). These rules ensure basic AI accountability lifecycle tracking without introducing dispute or governance complexity. 2.2. Extension Field Format 2.2.1. Extension Object HJS receipts (reusing JEP event format) MAY include an `extensions` object at the top level (in the JWS Payload) to carry additional AI accountability data. Each extension is identified by a URI and contains a value whose semantics are defined by the extension specification. Example: ```json { "extensions": { "org.example.hjs.tee-evidence": { ... }, "org.example.hjs.gdpr-proof": { ... } } } ``` 2.2.2. IANA Registration Requirements HJS extensions MUST be registered in the "HJS Extensions" registry with the following metadata (compatible with JEP's extension registry requirements): · Extension Identifier: URI · Semantics Description: URL to specification · Compatibility Level: "full", "wire", or "none" · Version: Semantic version · Registration Date · Contact Compatibility level indicates how the extension interacts with implementations that do not recognize it: · full: Can be safely ignored; core AI accountability semantics unchanged. · wire: Adds new fields that may be ignored but could affect interoperability if critical for AI accountability. · none: Modifies core AI accountability semantics; requires explicit support. 3. Appendices (Informative) The following appendices provide additional guidance, examples, and specifications for optional AI accountability extensions. They are not part of the core HJS model but are compatible with JEP's optional features. Appendix A. Complete State Machine and Dispute Handling A.1. Full State Definitions For systems requiring sophisticated AI accountability lifecycle management, the following states can be added to the simplified state machine: · DISPUTED_FROZEN: Conflict detected (e.g., dual‑mode verification), AI accountability chain frozen pending resolution. · RESOLVED_CONTINUE: Dispute resolved, chain continues. · RESOLVED_INVALID: Dispute resolved by invalidation; chain must be re‑initiated. A.2. Dispute Detection and Resolution Disputes are detected when dual‑mode verification yields inconsistent AI accountability results (platform signature valid but open verification fails, or vice versa). Upon detection, the chain enters DISPUTED_FROZEN and a resolution process is triggered. Resolution can be manual or automated using the $Resolve extension (Appendix D.9), which is HJS-specific and compatible with JEP events. A.3. Federal Governance Extension For multi‑party AI accountability governance, the Federal Resolution extension (Appendix D.9) allows configuring participants with weights and a threshold. Resolutions require a weighted signature set meeting the threshold, ensuring collective accountability for AI dispute outcomes. Appendix B. Advanced Verification Modes B.1. Platform Mode In platform mode, AI accountability verification relies on a platform‑issued signature in addition to JEP's cryptographic proof. This mode offers low latency (<10 ms) and is suitable for high‑trust AI accountability environments. B.2. Dual Mode Dual mode performs both platform and open AI accountability verification simultaneously (extending JEP's basic verification). If results conflict, the receipt is marked DISPUTED. This mode provides maximum assurance and detects platform compromise or misconfiguration that could break AI accountability. B.3. Multi‑Source Time Consensus To mitigate single time‑source failures (critical for AI accountability timestamp validity), implementations MAY collect timestamps from multiple independent sources (e.g., NTS, SCITT, hardware clock) and use a consensus algorithm (e.g., median) to determine authoritative time for JEP receipts. Appendix C. Compliance and Regulatory Guidance C.1. GDPR Mapping HJS's three‑tier architecture supports GDPR data minimization (Article 5) by design, extending JEP's neutral event format with AI accountability controls. Cryptographic erasure (Article 17) is implemented via the ERASED termination mode and Proof of Key Destruction (HJS-specific). For full compliance, deployers SHOULD enable the GDPR Compliance Proof extension (Appendix C.4), which adds AI accountability evidence for GDPR obligations. C.2. EU AI Act Mapping For high‑risk AI systems, HJS's `based_on` field (extending JEP's event format) enables traceability (Article 12 of the EU AI Act). The AI Act Transparency Marking extension (Appendix C.5) can record risk level, human oversight, and conformity assessment identifiers to meet AI accountability requirements for high-risk AI. C.3. Jurisdiction Marking Extension This HJS-specific extension allows receipts (reusing JEP format) to declare applicable law, data localization, and retention period—key AI accountability requirements for cross-border AI systems. See Appendix D.8 for details. C.4. GDPR Compliance Proof Extension Adds fields for DPO signature, erasure proof (PKD, timestamp, witness), and audit trail—HJS-specific AI accountability evidence for GDPR compliance. See Appendix D.8. C.5. AI Act Transparency Marking Extension Adds fields for risk level, transparency obligation, synthetic content flag, human supervisor ID, and conformity assessment—HJS-specific AI accountability metadata for EU AI Act compliance. See Appendix D.8. Appendix D. Concrete Extension Definitions D.1. TEE Evidence Format (Priority 1) Identifier: org.ietf.hjs.ext.tee-evidence Compatibility: wire Purpose: Standardize TEE evidence in Tier 2 for enhanced AI accountability. Fields: tee_type, format, evidence, verifier, timestamp. D.2. Lightweight Mode (Priority 2) Identifier: org.ietf.hjs.ext.lightweight Compatibility: wire Purpose: Reduce receipt size for constrained environments while preserving core AI accountability. Features: Compression, partial chain proof, open mode only. D.3. AIP Integration (Priority 2) Identifier: org.ietf.hjs.ext.aip Compatibility: wire Purpose: Bind HJS AI accountability chains to Agent Identity Protocol sessions for actor authorization validation. Fields: aip_session, aip_capability. D.4. Batch Operations (Priority 2) Identifier: org.ietf.hjs.ext.batch Compatibility: none Purpose: Atomically process multiple AI accountability primitives. Adds $Batch primitive with operations array (compatible with JEP events). D.5. Refusal Event (Priority 2) Identifier: org.ietf.hjs.ext.refusal Compatibility: wire Purpose: Record AI system refusals with AI accountability metadata. Fields: refusal.reason, policy_ref, input_hash. D.6. Key Evolution (Priority 3) Identifier: org.ietf.hjs.ext.key-evolution Compatibility: wire Purpose: Forward‑secrecy via key rotation for long-term AI accountability. Adds ROTATE_KEY event with rotation proof (compatible with JEP's Verify primitive). D.7. Enhanced Hardware Binding (Priority 3) Identifier: org.ietf.hjs.ext.enhanced-hardware Compatibility: wire Purpose: Strengthen AI accountability via VDF and biometrics. Supports binding_level, VDF proofs, biometric signals. D.8. Legal Validity Proof (Priority 4) Identifier: org.ietf.hjs.ext.legal-proof Compatibility: full Purpose: Enhance admissibility of HJS AI accountability chains with notary/regulator signatures. Fields: regulation, witnesses, pkd, audit_trail. D.9. Federal Resolution (Priority 5) Identifier: org.ietf.hjs.ext.federal-resolution Compatibility: full Purpose: Multi‑party governance for AI dispute resolution (HJS-specific). Fields: governance_model, participants, threshold_policy. Appendix E. Implementation Guide and Best Practices E.1. Minimal Implementation (Pseudocode) ```python # HJS implementation extending JEP's core event class class HJSReceipt(JEPReceipt): def __init__(self, verb, who, when, what, based_on, nonce): super().__init__(verb, who, when, what, nonce) # Reuse JEP self.based_on = based_on # HJS-specific AI chain field def verify_chain(self, public_key, authorization_list): # Step 1: Verify JEP signature (inherited) if not self.verify(public_key): return "INVALID" # Step 2: Verify AI accountability chain (HJS-specific) if self.based_on and not self.validate_parent(self.based_on): return "INVALID" # Step 3: Verify authorization (HJS-specific for AI) if self.verb == "D" and not self.check_authorization(authorization_list): return "INVALID" # Step 4: Verify erasure proof if terminated (HJS-specific) if self.verb == "T" and self.mode == "ERASED" and not self.validate_pkd(): return "INVALID" return "VALID" ``` E.2. Performance Benchmarks Reference implementation (Rust) on a 16‑core server: · Judge generation: 4.5 ms average · Throughput: 12,000 receipts/second · Open chain verification: <5 ms · Dual verification: <100 ms · Receipt size: 1.5–3 KB (core) E.3. Test Vectors (Example AI accountability receipt and verification results; refer to [HJS-00] for full test vectors.) E.4. Cross‑Domain Deployment Recommendations · Use ephemeral DIDs for public AI deployments, rotated daily. · For cross‑border transfers, enable Jurisdiction Marking. · For high‑risk AI, enable TEE Evidence and dual mode. Appendix F. Examples F.1. Judge Receipt Example (AI Agent) ```json { "hjs": "1.0", "verb": "J", "who": "did:example:ai-agent-123", "when": 1742345678, "what": "1220a1b2c3d4e5f67890abcdef0123456789", "based_on": null, "privacy": "AUDIT", "status": "ACTIVE", "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479", "aud": "https://platform.example.com", "sig": "eyJhbGciOiJFZERTQSJ9..." } ``` F.2. Error Code Reference · INVALID_SIGNATURE: Signature verification failed. · BROKEN_CHAIN: Parent hash mismatch (AI accountability chain broken). · UNAUTHORIZED_DELEGATION: Delegate not in AI authorization chain. · INVALID_TERMINATION: Missing dual signature in DELEGATED state. · PAYLOAD_ERASED: Tier 3 AI content erased. · CHAIN_TOO_DEEP: Delegation depth exceeds limit. · EXPIRED_RECEIPT: Timestamp outside window. · DISPUTED: Dual‑mode conflict in AI accountability. · RESOLUTION_REQUIRED: Governance resolution applied. Appendix G. References G.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7515] Jones, M., "JSON Web Signature (JWS)", RFC 7515, May 2015. [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, May 2015. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8785] Rundgren, A., et al., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. [RFC9334] Birkholz, H., et al., "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023. [RFC9122] Maheshwari, H., "Multihash Format", RFC 9122, July 2021. [RFC9562] Davis, D., et al., "Universally Unique IDentifiers (UUIDs)", RFC 9562, May 2024. [draft-wang-jep-judgment-event-protocol-01] Wang, Y., "Judgment Event Protocol (JEP)", draft-wang-jep-judgment-event-protocol-01 (Work in Progress), March 2026. G.2. Informative References [HJS-00] Wang, Y., "HJS: An Accountability Layer for AI Agents", draft-wang-hjs-accountability-00, February 2026. [I-D.ietf-scitt-architecture] Birkholz, H., et al., "Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture", Work in Progress. [DID-CORE] Sporny, M., et al., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022. [AIP-CORE] Agent Identity Protocol Working Group, "Agent Identity Protocol (AIP) Core Specification", 2025, https://aip.dev/. [GDPR-2016] European Parliament, "General Data Protection Regulation (GDPR)", 2016. [EU-AI-ACT] European Commission, "Artificial Intelligence Act", 2024. Author's Address Yuqiang Wang HUMAN JUDGMENT SYSTEMS FOUNDATION LTD. Email: signal@humanjudgment.org GitHub: https://github.com/hjs-spec