INTERNET-DRAFT Y. Wang Intended status: Standards Track March 2, 2026 Expires: September 3, 2026 HJS: A Judgment Event Protocol draft-wang-hjs-judgment-event-00 Abstract This document defines HJS, a specialized protocol for judgment attribution — determining who is responsible for AI decisions, when, and under what authority — and enables portable, verifiable judgment transfer across heterogeneous AI systems. HJS addresses one specific problem that complementary systems do not: binding decisions to accountable actors, tracking how responsibility transfers over time, and providing cryptographic credentials that allow AI agents to prove decision authority to external systems without requiring prior trust relationships. It works alongside provenance frameworks (VAP), security protocols (SEAT), monitoring platforms (Arize, WhyLabs), and governance systems (Fiddler), providing the attribution layer these systems complement. HJS contributes standardized judgment events, portable cryptographic Receipts that serve as verifiable credentials for cross-system delegation, and flexible verification modes for diverse deployment scenarios. 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 3, 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 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. The Gap: Why Current Approaches Are Insufficient . . . . . . . 3 1.1. The Accountability Gap in Production AI Systems . . . . . 3 1.1.1. Case Study: The Cross-Platform Diagnosis Challenge . . 3 1.1.2. Where Existing Standards Have Gaps . . . . . . . . . . 4 1.2. The Regulatory Imperative . . . . . . . . . . . . . . . . 5 1.3. Why IETF Standardization Is the Optimal Path . . . . . . . 5 1.3.1. Interoperability Across Competitive Platforms . . . . 6 1.3.2. Regulatory Recognition and Compliance . . . . . . . . 6 1.3.3. Long-Term Stability and Institutional Memory . . . . . 6 1.3.4. Integration with IETF Protocol Ecosystem . . . . . . . 7 2. The Constraints: Why Design Must Be Minimal . . . . . . . . . 7 2.1. The Tension: Power vs. Adoption . . . . . . . . . . . . . 8 2.2. Limitations of Existing "Middle Ground" Approaches . . . . 8 2.2.1. Signed JSON Web Tokens (JWT) . . . . . . . . . . . . . 8 2.2.2. Blockchain Anchoring (Heavyweight) . . . . . . . . . . 9 2.2.3. Vendor-Neutral APIs (Industry Alliance) . . . . . . . 9 2.3. The Design Constraints . . . . . . . . . . . . . . . . . . 9 3. The Mechanism: Receipt as Portable Credential . . . . . . . . 10 3.1. Core Insight . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. The Four Primitives . . . . . . . . . . . . . . . . . . . 10 3.2.1. Judge: Establish Accountability . . . . . . . . . . . 10 3.2.2. Delegate: Transfer Responsibility (The Key Innovation) 11 3.2.3. Terminate: Conclude Accountability . . . . . . . . . . 11 3.2.4. Verify: Independent Attestation . . . . . . . . . . . 11 3.3. Receipt: The Universal Credential . . . . . . . . . . . . 11 3.3.1. Receipt Structure . . . . . . . . . . . . . . . . . . 11 3.3.2. Verification Without Trust . . . . . . . . . . . . . 12 3.4. Three Verification Modes . . . . . . . . . . . . . . . . . 13 4. Validation and Testing . . . . . . . . . . . . . . . . . . . . 14 4.1. Design Validation Approach . . . . . . . . . . . . . . . . 14 4.2. Performance Characteristics . . . . . . . . . . . . . . . 14 4.2.1. Computational Complexity . . . . . . . . . . . . . . . 14 4.2.2. Cryptographic Overhead . . . . . . . . . . . . . . . . 14 4.3. Cross-Platform Testing . . . . . . . . . . . . . . . . . . 15 4.3.1. Test Configuration . . . . . . . . . . . . . . . . . . 15 4.3.2. Delegation Flow Validation . . . . . . . . . . . . . . 15 4.4. Security Validation . . . . . . . . . . . . . . . . . . . 15 4.4.1. Threat Model Testing . . . . . . . . . . . . . . . . . 15 4.4.2. Audit Simulation . . . . . . . . . . . . . . . . . . . 16 4.5. Comparison to Alternative Approaches . . . . . . . . . . . 16 5. Regulatory and Deployment Context . . . . . . . . . . . . . . 17 5.1. Current Regulatory Landscape . . . . . . . . . . . . . . . 17 5.1.1. Compliance Requirements Today . . . . . . . . . . . . 17 5.1.2. Regulatory Compliance Support . . . . . . . . . . . . 18 5.2. Deployment Considerations . . . . . . . . . . . . . . . . 18 5.2.1. Multi-Platform AI Workflows . . . . . . . . . . . . . 18 5.2.2. Autonomous Agent Delegation . . . . . . . . . . . . . 18 5.3. Technical Evolution Considerations . . . . . . . . . . . . 19 5.3.1. Integration with Developing Standards . . . . . . . . 19 5.4. Adoption Evaluation Framework . . . . . . . . . . . . . . 19 5.5. Limitations and Uncertainties . . . . . . . . . . . . . . 19 5.5.1. Technical Limitations . . . . . . . . . . . . . . . . 19 5.5.2. Market Uncertainties . . . . . . . . . . . . . . . . . 20 5.6. Success Criterion . . . . . . . . . . . . . . . . . . . . 20 6. Technical Specification . . . . . . . . . . . . . . . . . . . 20 6.1. Judgment Event Model . . . . . . . . . . . . . . . . . . . 20 6.1.1. Event Types . . . . . . . . . . . . . . . . . . . . . 20 6.1.2. Lifecycle Events . . . . . . . . . . . . . . . . . . . 20 6.1.3. Verify Events . . . . . . . . . . . . . . . . . . . . 21 6.2. Common Fields . . . . . . . . . . . . . . . . . . . . . . 21 6.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 21 6.3.1. States . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3.2. State Transitions . . . . . . . . . . . . . . . . . . 22 6.3.3. Delegation and Acceptance Flow . . . . . . . . . . . . 22 6.4. Data Format . . . . . . . . . . . . . . . . . . . . . . . 23 6.4.1. JSON Representation . . . . . . . . . . . . . . . . . 23 6.4.2. Serialization . . . . . . . . . . . . . . . . . . . . 26 6.4.3. Hash Computation . . . . . . . . . . . . . . . . . . . 26 6.5. HJS Receipt Format . . . . . . . . . . . . . . . . . . . . 27 6.5.1. Receipt Structure . . . . . . . . . . . . . . . . . . 27 6.5.2. Receipt Verification . . . . . . . . . . . . . . . . . 28 6.6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 7. HJS Verification Layer . . . . . . . . . . . . . . . . . . . . 29 7.1. Verification Modes . . . . . . . . . . . . . . . . . . . . 29 7.2. HTTP API . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1. Event Retrieval . . . . . . . . . . . . . . . . . . . 29 7.2.2. Chain Integrity Verification . . . . . . . . . . . . . 29 7.2.3. Receipt Retrieval . . . . . . . . . . . . . . . . . . 29 7.2.4. Verification . . . . . . . . . . . . . . . . . . . . . 30 8. Ecosystem Integration . . . . . . . . . . . . . . . . . . . . 31 8.1. Complementary Systems . . . . . . . . . . . . . . . . . . 31 8.2. Complementary Relationship with SCITT . . . . . . . . . . 31 8.2.1. Core Differences . . . . . . . . . . . . . . . . . . . 31 8.2.2. Complementary Usage Patterns . . . . . . . . . . . . . 31 8.3. Alignment with VAP Framework . . . . . . . . . . . . . . . 32 8.4. Integration with SEAT . . . . . . . . . . . . . . . . . . 32 8.5. Relationship to RATS Architecture . . . . . . . . . . . . 32 8.6. Integration with Monitoring Platforms . . . . . . . . . . 32 8.7. Relationship to AIP (Agent Identity Protocol) . . . . . . 33 8.8. HJS as Inter-Agent Communication Protocol . . . . . . . . 33 8.8.1. The Cross-System Delegation Problem . . . . . . . . . 33 8.8.2. Cross-System Delegation Flow . . . . . . . . . . . . . 33 8.8.3. Receipt as Universal Credential . . . . . . . . . . . 33 8.9. What HJS Does NOT Do . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9.1. Signature Validation . . . . . . . . . . . . . . . . . . . 34 9.2. Chain Integrity . . . . . . . . . . . . . . . . . . . . . 34 9.3. Replay Attacks and Connection Binding . . . . . . . . . . 34 9.4. Delegation Security . . . . . . . . . . . . . . . . . . . 35 9.5. Time Source Security . . . . . . . . . . . . . . . . . . . 35 9.6. UUIDv7 Clock Dependency . . . . . . . . . . . . . . . . . 35 9.7. Trust Model Summary . . . . . . . . . . . . . . . . . . . 35 9.8. Post-Quantum Cryptography Migration . . . . . . . . . . . 35 9.8.1. Risk Assessment . . . . . . . . . . . . . . . . . . . 35 9.8.2. Algorithm-Agnostic Design . . . . . . . . . . . . . . 36 9.8.3. Dual Signatures (High-Security Scenarios) . . . . . . 36 9.8.4. Migration Timeline (March 2026) . . . . . . . . . . . 36 9.8.5. Long-Term Receipt Verification . . . . . . . . . . . . 37 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 10.1. Decision Content Privacy . . . . . . . . . . . . . . . . 37 10.2. Metadata Leakage . . . . . . . . . . . . . . . . . . . . 37 10.3. Data Minimization . . . . . . . . . . . . . . . . . . . . 38 10.4. GDPR and the "Right to be Forgotten" . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11.1. Media Types . . . . . . . . . . . . . . . . . . . . . . . 38 11.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 39 12. Normative References . . . . . . . . . . . . . . . . . . . . 39 13. Informative References . . . . . . . . . . . . . . . . . . . 40 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. Reference Implementation . . . . . . . . . . . . . . 42 Appendix B. Dispute Handling Decision Framework . . . . . . . . . 42 B.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 42 B.2. Risk Assessment Matrix . . . . . . . . . . . . . . . . 42 B.3. Decision Tree . . . . . . . . . . . . . . . . . . . . 43 B.4. Implementation Recommendations . . . . . . . . . . . . 43 Appendix C. Implementation Risks and Mitigations . . . . . . . . 44 C.1. Asynchronous Delegation Risks . . . . . . . . . . . . 44 C.2. Clock Synchronization Risks . . . . . . . . . . . . . 44 C.3. Platform Compromise Detection . . . . . . . . . . . . 44 C.4. Adoption Dependencies . . . . . . . . . . . . . . . . 44 C.5. Alternative Deployment Paths . . . . . . . . . . . . . 45 Author's Address Yuqiang Wang HUMAN JUDGMENT SYSTEMS FOUNDATION LTD. Email: signal@humanjudgment.org GitHub: https://github.com/schchit 1. The Gap: Why Current Approaches Are Insufficient 1.1. The Accountability Gap in Production AI Systems AI systems are rapidly evolving from isolated tools to interconnected agent networks. This transformation has created a critical gap that existing infrastructure does not fully address: how do we track who is responsible for AI decisions when those decisions cross organizational and platform boundaries? 1.1.1. Case Study: The Cross-Platform Diagnosis Challenge In late 2025, a European hospital network deployed a multi-stage AI diagnostic system: * Stage 1 (AWS-hosted, Arize-monitored): Primary screening AI flags potential cardiac anomalies * Stage 2 (Azure-hosted, Fiddler-governed): Specialist AI confirms diagnosis and recommends treatment * Stage 3 (On-premise, custom governance): Clinical decision support system generates final report The Challenge: When regulators investigated a misdiagnosis six months later, they discovered: 1. Platform A's logs showed "AI decision made" but no link to Platform B's confirmation 2. Platform B's audit trail referenced "external input" but couldn't cryptographically verify it came from Platform A 3. The hospital's compliance team spent 400+ hours reconciling three incompatible log formats 4. The final report contained no verifiable proof of which AI system made which decision at which time The Root Cause: No standard existed for portable, cryptographically verifiable proof of AI decision authority that works across heterogeneous platforms without pre-established trust. This is not an isolated incident. Similar patterns have been observed in: * Financial services (cross-bank algorithmic trading audits) * Autonomous vehicle fleets (multi-vendor sensor fusion decisions) * Supply chain logistics (AI-orchestrated multi-party shipments) 1.1.2. Where Existing Standards Have Gaps Current solutions address adjacent problems but do not fully cover the accountability gap: +-------------+------------------------+---------------------------+ | Standard | Scope | Gap in Cross-Platform | | | | Attribution | +-------------+------------------------+---------------------------+ | W3C DID | Decentralized identity | Proves "who you are," not | | | | "what you decided" or | | | | "who is responsible now" | +-------------+------------------------+---------------------------+ | OIDC/OAuth | Authorization | Tokens prove "you may | | 2.0 | | access," not "you decided | | | | X at time Y with authority| | | | Z" | +-------------+------------------------+---------------------------+ | SCITT | Supply chain | Provides global | | | transparency | transparency for | | | | artifacts; does not define| | | | judgment attribution | | | | semantics or delegation | | | | state machine | +-------------+------------------------+---------------------------+ | X.509/PKIX | Public key | Certificates bind keys to | | | infrastructure | identities, not decisions | | | | to accountable actors | +-------------+------------------------+---------------------------+ | Blockchain | Distributed consensus | Heavyweight, expensive, | | (Ethereum, | | slow; impractical for | | etc) | | real-time AI delegation | +-------------+------------------------+---------------------------+ | Syslog/ | System logging | No cryptographic | | Auditd | | integrity, no portable | | | | verification, no cross- | | | | system semantics | +-------------+------------------------+---------------------------+ The Pattern: Each system creates islands of accountability. Within a single platform, audit trails work. Across platforms, regulators and auditors face significant operational burden from manually correlating incompatible logs — a process lacking cryptographic guarantees that HJS can streamline. 1.2. The Regulatory Imperative The accountability gap is becoming a legal liability: * EU AI Act (2024): Article 12 requires "technical documentation" including "traceability of the AI system" — but provides no standard for cross-platform traceability * US NIST AI RMF: Calls for "accountability mechanisms" — but existing mechanisms are platform-specific * UK ICO AI Auditing Framework: Requires "explainability and transparency" — but auditors lack tools for multi-system investigations The Consequence: Organizations deploying multi-platform AI face compliance uncertainty. They cannot prove accountability to regulators, and regulators cannot efficiently verify compliance. 1.3. Why IETF Standardization Is the Optimal Path HJS benefits from IETF standardization for four fundamental reasons that are best served by the IETF process — neutrality, regulatory recognition, long-term stability, and ecosystem integration. 1.3.1. Interoperability Across Competitive Platforms AI accountability infrastructure is dominated by competing vendors (AWS, Google Cloud, Azure) and specialized platforms (Arize, Fiddler, WhyLabs). These competitors will not adopt each other's proprietary formats, nor will they cede control to a single vendor's solution. IETF provides the neutral venue where competing interests can converge on a minimal, non-overlapping standard. HJS is designed specifically for this context: it does not compete with platforms' core value (monitoring, governance, security) but provides the interoperability layer they all need for cross-platform accountability. IETF standardization mitigates risks of: * Vendor lock-in: Each platform developing incompatible attribution mechanisms * Regulatory fragmentation: Jurisdictions mandating different formats * Audit inefficiency: No common language for third-party verification 1.3.2. Regulatory Recognition and Compliance Regulators explicitly reference international standards as presumptions of conformity. An IETF standard carries unique weight in: * Legal admissibility: IETF standards are recognized in courts and regulatory proceedings worldwide * Procurement requirements: Government and enterprise RFPs routinely mandate IETF standards for interoperability-critical components * Cross-border mutual recognition: IETF standards facilitate compliance equivalence across jurisdictions 1.3.3. Long-Term Stability and Institutional Memory AI accountability requires decades-long verifiability. A judgment made in 2026 may be audited in 2036 or 2046. This requires: * Stable specification: IETF's change control and version management * Institutional continuity: IETF's 50+ year track record vs. corporate or project lifecycles * Public documentation: RFC series archival ensures permanent, globally accessible reference 1.3.4. Integration with IETF Protocol Ecosystem HJS does not operate in isolation. It builds upon and integrates with existing IETF standards: +---------------------+----------------------------------------------+ | IETF Standard | HJS Integration | +---------------------+----------------------------------------------+ | RFC 9562 (UUIDv7) | Event identification with time-sortability | +---------------------+----------------------------------------------+ | RFC 8785 (JCS) | Canonical serialization for signatures | +---------------------+----------------------------------------------+ | RFC 9334 (RATS) | Attestation architecture alignment | +---------------------+----------------------------------------------+ | draft-ietf-scitt- | Transparency log integration | | architecture | | +---------------------+----------------------------------------------+ | draft-fossati-seat- | Session binding for replay protection | | expat | | +---------------------+----------------------------------------------+ 2. The Constraints: Why Design Must Be Minimal 2.1. The Tension: Power vs. Adoption Any solution to the accountability gap faces a fundamental tension: +------------------+----------------------+--------------------------+ | Approach | Capability | Adoption Barrier | +------------------+----------------------+--------------------------+ | Heavyweight | Strong guarantees, | Too slow, too expensive, | | (Blockchain) | full decentralization| too complex for real-time| | | | AI | +------------------+----------------------+--------------------------+ | Lightweight | Fast, cheap, simple | No cryptographic | | (Logs) | | integrity, no cross- | | | | platform verification | +------------------+----------------------+--------------------------+ | Platform- | Optimized for | Creates vendor lock-in, | | Specific | specific stack | fails cross-platform | | | | scenario | +------------------+----------------------+--------------------------+ The Constraint: The solution must be lightweight enough for real-time AI systems (millisecond latency, minimal overhead), yet robust enough for regulatory audit (cryptographic proof, decades-long verifiability). 2.2. Limitations of Existing "Middle Ground" Approaches Several attempts have been made to bridge this gap. Each faces specific constraints in the cross-platform attribution context that HJS addresses. 2.2.1. Signed JSON Web Tokens (JWT) Approach: Embed claims in signed JWTs, pass between systems. Constraint: * JWTs prove identity ("Alice sent this") not judgment lineage ("This is the 3rd delegation in a chain starting with Bob") * No standardized mechanism for offline verification of chain integrity without contacting originator * Platform-specific claim formats prevent interoperability 2.2.2. Blockchain Anchoring (Heavyweight) Approach: Record every AI decision on public blockchain. Constraint: * Latency: 10-60 second confirmation times unacceptable for real-time AI delegation * Cost: Gas fees make high-frequency AI decisions economically infeasible * Scalability: Public blockchains cannot handle enterprise AI transaction volumes * Privacy: Public ledgers expose sensitive decision metadata 2.2.3. Vendor-Neutral APIs (Industry Alliance) Approach: Define REST API standard for accountability queries. Constraint: * Often requires online connectivity to originating platform for verification * Creates potential availability dependency: if Platform A is down, Platform B may lack cached data for verification * Even with batch export, exported data often lacks the self-contained cryptographic structure of HJS Receipts, requiring platform-specific validation logic 2.3. The Design Constraints HJS is designed under five strict constraints that emerge from the analysis: C1: Minimal Primitives Only four operations: Judge (create), Delegate (transfer), Terminate (end), Verify (attest). No policy engine, no identity system, no consensus mechanism. C2: Offline Verifiability Receipt must enable verification without contacting originating platform. Critical for audit scenarios where platforms may be defunct, unavailable, or uncooperative. C3: Optional Heaviness Blockchain anchoring (OTS, SCITT) must be optional, not mandatory. Systems choose their security/performance tradeoff. C4: No Platform Trust Cross-platform delegation must work without pre-established API integration or business relationships. C5: IETF Alignment Must integrate with existing IETF standards (JCS, UUIDv7, RATS) rather than invent parallel mechanisms. 3. The Mechanism: Receipt as Portable Credential 3.1. Core Insight The core mechanism is not a new cryptographic primitive, but a new composition of existing primitives into a portable credential format: Receipt = Event Hash + Chain Proof + Anchor Proof + Platform Attestation ↓ ↓ ↓ ↓ Integrity Lineage Timestamp Origin (SHA-256) (prev_hash) (OTS/SCITT) (Signature) This composition enables trustless handoff: Platform B can verify Platform A's judgment without: * Prior integration with Platform A * Real-time access to Platform A's infrastructure * Trust in Platform A's operators 3.2. The Four Primitives HJS provides exactly four operations, each addressing a specific accountability need. 3.2.1. Judge: Establish Accountability Creates a new judgment lifecycle. Semantics: "I, Actor X, take responsibility for Decision Y under Authority Z, from Time A to Time B." State Transition: null -> Active Critical Property: Genesis event (prev_hash = null) establishes Chain ID, a deterministic identifier for the entire lifecycle. 3.2.2. Delegate: Transfer Responsibility (The Key Innovation) Transfers responsibility to another actor. Semantics: "I transfer accountability to Actor P, who accepts with Proof Q." State Transition: Active -> Delegated, or Delegated -> Delegated Cross-System Mechanism: 1. Platform A generates Judge event, creates Receipt 2. Platform A passes Receipt to Platform B (out-of-band or via API) 3. Platform B independently verifies Receipt using only public data 4. Platform B generates Delegate event, references Platform A's event 5. New chain continues with Platform B as responsible actor Why This Works: Receipt contains cryptographic proof of the entire lineage. Platform B doesn't need to trust Platform A's logs—it verifies the math. 3.2.3. Terminate: Conclude Accountability Concludes the judgment lifecycle. Semantics: "Accountability ends for Reason R." State Transition: Active -> Terminal, or Delegated -> Terminal Regulatory Value: Provides definitive endpoint for audit scope. 3.2.4. Verify: Independent Attestation Provides external attestation without modifying state. Semantics: "Third Party V confirms Event E occurred with Method M." Value: Enables auditor, regulator, or counterparty verification without participating in the lifecycle chain. 3.3. Receipt: The Universal Credential The Receipt is the core innovation that enables cross-platform accountability. It is a self-contained cryptographic proof bundle. 3.3.1. Receipt Structure { "hjs_receipt": "1.0", "event_id": "uuid-of-event", "event_hash": {"hash": "sha256:...", "alg": "sha256"}, "chain_proof": { "type": "linear", "anchor": {"hash": "...", "alg": "sha256"}, "depth": 3 }, "anchor_proof": { "type": "ots", "timestamp": 1712345678, "data": "base64-ots-proof", "uri": "https://ots.example.com" }, "verification_mode": "open", "platform_attestation": { "issuer": "https://platform-a.example", "issued_at": 1712345678, "signature": "base64-sig", "alg": "Ed25519" } } Note on verification_mode: This field indicates the mode used when generating the Receipt (e.g., whether platform attestation was included), not a recommendation for how the Receipt should be verified. Verification mode selection occurs at verification time via API parameter. 3.3.2. Verification Without Trust Receipt verification requires only: * Standard cryptographic libraries (SHA-256, Ed25519, or SM2/SM3) * Public timestamping infrastructure (OpenTimestamps, SCITT, or TSP) * No platform-specific code or credentials Note on Timestamping Neutrality: The use of OpenTimestamps (OTS) with the Bitcoin blockchain is described as one example implementation of the anchor_proof mechanism. Implementations are free to use any timestamping service that meets their security and operational requirements. function verifyReceipt(receipt, event) { // 1. Verify event hasn't been tampered if (computeHash(event) !== receipt.event_hash.hash) return {valid: false, reason: "hash_mismatch"}; // 2. Verify chain integrity (previous events linked correctly) if (!verifyChainProof(receipt.chain_proof)) return {valid: false, reason: "chain_broken"}; // 3. Verify timestamp (event occurred when claimed) if (!verifyAnchor(receipt.anchor_proof)) return {valid: false, reason: "timestamp_invalid"}; // 4. Verify platform signature (optional, for dual mode) if (receipt.verification_mode === "dual" && !verifyPlatformSig(receipt.platform_attestation)) return {valid: false, reason: "platform_sig_invalid"}; return {valid: true, verified_at: now()}; } Key Property: This verification can occur years after the event, even if Platform A no longer exists. 3.4. Three Verification Modes HJS supports three verification modes for different assurance needs: +----------+--------------------+----------+--------------------------+ | Mode | Trust Root | Latency | Use Case | +----------+--------------------+----------+--------------------------+ | platform | HJS platform | <10ms | Real-time monitoring, | | | signature | | high-trust environments | +----------+--------------------+----------+--------------------------+ | open | Receipt | <1ms | Cross-platform | | | cryptographic proof| (local) | delegation, offline | | | | | audit, regulatory | | | | | verification | +----------+--------------------+----------+--------------------------+ | dual | Cross-confirmation | <100ms | High-value decisions, | | | | | maximum assurance | +----------+--------------------+----------+--------------------------+ Dual Mode is the innovation: when platform and open verification disagree, the system returns disputed with detailed forensic information. This detects compromise, misconfiguration, or implementation bugs. Handling Disputed Results: Upon receiving a disputed result, the relying party SHOULD NOT rely on the event for any security-critical or compliance-critical decision. The dispute indicates a fundamental inconsistency between the platform's live attestation and the independently verifiable Receipt. This may indicate a compromise of the platform's signing keys, a rollback attack, or a bug in the Receipt generation logic. The relying party SHOULD log the dispute details and MAY alert an operator or auditor for manual investigation. 4. Validation and Testing 4.1. Design Validation Approach HJS design claims are validated through: * Protocol review: Expert review by complementary protocol teams (VAP, SEAT, AIP, RATS) * Security analysis: Adversarial testing of cryptographic mechanisms * Scenario testing: Validation against documented use cases * Standards alignment: Verification of IETF dependency integration This section documents validation results and known limitations. 4.2. Performance Characteristics 4.2.1. Computational Complexity +----------------------+--------------+-----------------------------+ | Operation | Complexity | Dominant Cost | +----------------------+--------------+-----------------------------+ | Judge (create event) | O(1) | JCS canonicalization + | | | | signature | +----------------------+--------------+-----------------------------+ | Delegate (with | O(1) | Hash chain verification + | | Receipt) | | signature | +----------------------+--------------+-----------------------------+ | Receipt verification | O(1) | Local cryptographic | | (open) | | operations | +----------------------+--------------+-----------------------------+ | Receipt verification | O(1) | Platform attestation + | | (dual) | | local | +----------------------+--------------+-----------------------------+ | Chain integrity | O(n) | n = chain depth, typically | | check | | < 10 | +----------------------+--------------+-----------------------------+ Note: These are computational costs only. End-to-end latency includes network transfer time for cross-platform delegation. 4.2.2. Cryptographic Overhead The protocol is designed to minimize cryptographic overhead: * Hash operations: SHA-256 or SM3 (hardware-accelerated on modern CPUs) * Signatures: Ed25519 or SM2 (fast verification, compact signatures) * Serialization: JCS (deterministic, single-pass) Validation: Cryptographic operations add < 5ms to event processing in reference implementations, negligible compared to typical network latencies (10-100ms). 4.3. Cross-Platform Testing 4.3.1. Test Configuration Laboratory validation across three independent deployments: +----------+-------------------+---------------------------+ | Platform | Infrastructure | Governance Stack | +----------+-------------------+---------------------------+ | Alpha | Cloud Provider A | Monitoring Platform X | +----------+-------------------+---------------------------+ | Beta | Cloud Provider B | Governance Platform Y | +----------+-------------------+---------------------------+ | Gamma | On-premise | Custom compliance | +----------+-------------------+---------------------------+ 4.3.2. Delegation Flow Validation Test: Controlled end-to-end delegations (Alpha -> Beta -> Gamma) +------------------------------------+------------+-----------------+ | Metric | Result | Notes | +------------------------------------+------------+-----------------+ | Successful Receipt verification | 100% | All receipts | | | | cryptographically| | | | valid | +------------------------------------+------------+-----------------+ | Cross-platform chain reconstruction| Successful | Verified without| | | | platform | | | | coordination | +------------------------------------+------------+-----------------+ | Offline verification (simulated) | Successful | Verified using | | | | only public | | | | timestamp data | +------------------------------------+------------+-----------------+ Limitation: These are laboratory tests with controlled conditions. Production deployment validation is pending. 4.4. Security Validation 4.4.1. Threat Model Testing Security analysis covered: +-------------------+-----------------------------+-----------------+ | Attack Vector | Mitigation | Verification | +-------------------+-----------------------------+-----------------+ | Signature forgery | Ed25519/SM2 + strict JCS | Cryptographic | | | | review | +-------------------+-----------------------------+-----------------+ | Receipt replay | UUIDv7 uniqueness + validity| Protocol | | | windows | analysis | +-------------------+-----------------------------+-----------------+ | Chain tampering | prev_hash chaining | Formal | | | | verification | +-------------------+-----------------------------+-----------------+ | Backdated events | Dual time sources + OTS | Implementation | | | anchoring | review | +-------------------+-----------------------------+-----------------+ | Platform | Dual mode discrepancy | Design review | | compromise | detection | | +-------------------+-----------------------------+-----------------+ 4.4.2. Audit Simulation Tested capability: Reconstruct decision chain with only Receipts (simulating platform unavailability): +--------------------------+-------------+-------------------------+ | Task | Capability | Limitation | +--------------------------+-------------+-------------------------+ | Verify single event | Supported | Requires preserved | | authenticity | | Receipt | +--------------------------+-------------+-------------------------+ | Reconstruct full chain | Supported | Requires all Receipts | | | | in chain | +--------------------------+-------------+-------------------------+ | Detect missing events | Supported | Gap detection via | | | | sequence | +--------------------------+-------------+-------------------------+ | Verify timestamps | Supported | Depends on anchor type | | | | used | +--------------------------+-------------+-------------------------+ 4.5. Comparison to Alternative Approaches +--------------------+---------+----------------+-------------+------+ | Approach | Latency | Cross-Platform | Offline | Cost/| | | | | Verify | Event| +--------------------+---------+----------------+-------------+------+ | HJS (open mode) | Low | Yes | Yes | Low | | | | | | (com-| | | | | | pute | | | | | | only)| +--------------------+---------+----------------+-------------+------+ | HJS (dual mode) | Medium | Yes | Yes | Low +| | | | | | plat-| | | | | | form | | | | | | query| +--------------------+---------+----------------+-------------+------+ | Ethereum anchoring | High | Yes | Yes | High | | | | | | (gas | | | | | | fees)| +--------------------+---------+----------------+-------------+------+ | Platform API | Medium | No | No | None | | verification | | | | (but | | | | | | requ-| | | | | | ires | | | | | | inte-| | | | | | grat-| | | | | | ion) | +--------------------+---------+----------------+-------------+------+ | Traditional logs | Low | No | No | None | | | | | | (no | | | | | | veri-| | | | | | fic- | | | | | | ation| | | | | | ) | +--------------------+---------+----------------+-------------+------+ Positioning: HJS occupies a unique position in the design space— lightweight, cross-platform, offline-verifiable, with optional blockchain anchoring. 5. Regulatory and Deployment Context 5.1. Current Regulatory Landscape 5.1.1. Compliance Requirements Today Regulatory frameworks are actively evolving. HJS is designed to address requirements that are already specified, though implementation guidance remains incomplete: +-------------+---------------------+---------------------+----------+ | Regulation | Specified | Current Gap | HJS | | | Requirement | | Relevance| +-------------+---------------------+---------------------+----------+ | EU AI Act | Article 12: | No standard for | HJS | | (2024) | "technical | cross-platform | Receipt | | | documentation" | traceability format | as | | | including | | portable | | | "traceability" | | document-| | | | | ation | +-------------+---------------------+---------------------+----------+ | US NIST AI | "Accountability | No specific | HJS | | RMF | mechanisms" | mechanism defined | prim- | | | | | itives | | | | | as | | | | | implemen-| | | | | tation | | | | | option | +-------------+---------------------+---------------------+----------+ | UK ICO AI | "Explainability | No tools for | HJS | | Auditing | and transparency" | multi-system | Verify | | | | investigations | events | | | | | for | | | | | external | | | | | attest- | | | | | ation | +-------------+---------------------+---------------------+----------+ Observation: Regulators are specifying what must be achieved (traceability, accountability) but not how. This creates interoperability risk if each jurisdiction or vendor develops incompatible approaches. 5.1.2. Regulatory Compliance Support HJS provides technical capabilities that support compliance efforts: +-------------------------+------------------------------------------+ | Regulatory Requirement | HJS Technical Support | +-------------------------+------------------------------------------+ | Traceability | Cryptographically chained event records | +-------------------------+------------------------------------------+ | Accountability | Explicit Actor field and signatures | +-------------------------+------------------------------------------+ | Evidence preservation | Self-contained verifiable Receipts | +-------------------------+------------------------------------------+ | Cross-system audit | Platform-agnostic Receipt format | +-------------------------+------------------------------------------+ 5.2. Deployment Considerations 5.2.1. Multi-Platform AI Workflows Organizations deploying AI across multiple platforms face operational challenges: Observed Pattern (Healthcare): * Primary screening on Cloud Platform A * Specialist confirmation on Cloud Platform B * Final reporting on on-premise system * Regulatory audit requires reconciliation of three separate audit trails Current Friction: Manual reconciliation of incompatible logs; no cryptographic verification of cross-platform handoffs. HJS Application: Receipt-based verification of each handoff, enabling single-chain audit without platform-to-platform integration. 5.2.2. Autonomous Agent Delegation Emerging use case: Agent-to-agent responsibility transfer. Observed Pattern (Supply Chain): * Agent A (manufacturer system) negotiates with Agent B (logistics system) * Current practice: API calls with logged assertions * Gap: No cryptographic proof of delegation for post-hoc audit HJS Application: Delegate events with Receipts create portable, verifiable record of agent-to-agent responsibility transfer. Note: This is an emerging use case with limited production volume. 5.3. Technical Evolution Considerations 5.3.1. Integration with Developing Standards HJS is designed to integrate with standards that are currently in development: +------------------+----------------+-------------------------------+ | Standard | Current Status | HJS Relationship | +------------------+----------------+-------------------------------+ | AIP (Agent | Draft | HJS events as audit log format | | Identity) | | | +------------------+----------------+-------------------------------+ | VAP (Provenance) | Draft | HJS as integrity layer | | | | implementation | +------------------+----------------+-------------------------------+ | SEAT (Session | Draft | Session binding for replay | | Security) | | protection | +------------------+----------------+-------------------------------+ | SCITT | Draft | Optional anchor_proof type | | (Transparency) | | | +------------------+----------------+-------------------------------+ 5.4. Adoption Evaluation Framework Whether HJS provides value depends on observable outcomes: Minimum traction indicators: * Independent platform (non-Foundation) deploys to production with public documentation * Regulatory evaluation publishes findings * Additional platform vendors commit to integration timelines 5.5. Limitations and Uncertainties 5.5.1. Technical Limitations HJS is designed for specific constraints. It does not address: +-------------------+----------------------+-------------------------+ | Limitation | Rationale | Current Workaround | +-------------------+----------------------+-------------------------+ | No consensus | Avoids blockchain | Platform-specific | | mechanism | complexity | ordering for | | | | simultaneous events | +-------------------+----------------------+-------------------------+ | No real-time sync | Offline verification | Eventual consistency | | | priority | via Receipt propagation | +-------------------+----------------------+-------------------------+ | No built-in | Separation of | Integration with | | identity | concerns | DID/OIDC for actor | | | | verification | +-------------------+----------------------+-------------------------+ 5.5.2. Market Uncertainties Several factors could reduce or eliminate the need for HJS: +----------------------+--------------------------+-------------------+ | Factor | Observation | Impact on HJS | +----------------------+--------------------------+-------------------+ | Platform | If AI market | Cross-platform | | consolidation | consolidates to 2-3 | interoperability | | | vendors | becomes less | | | | relevant | +----------------------+--------------------------+-------------------+ | Regulatory | If jurisdictions mandate | HJS may not | | divergence | incompatible formats | satisfy all | | | | regional | | | | requirements | +----------------------+--------------------------+-------------------+ | Alternative | If existing standards | HJS becomes | | solutions | (DID, SCITT) extend to | redundant | | | cover judgment | | | | attribution | | +----------------------+--------------------------+-------------------+ 5.6. Success Criterion HJS provides value when a regulator can verify an AI decision chain without needing real-time access to the original platforms' proprietary systems or databases, and with cryptographic certainty of the decision's authenticity and chain of custody. 6. Technical Specification 6.1. Judgment Event Model 6.1.1. Event Types +---------------+-------------------+----------+--------+-----------+ | Event Type | Purpose | Modifies | Has | Portable | | | | State | prev- | Credential| | | | | hash | | +---------------+-------------------+----------+--------+-----------+ | Lifecycle | State transitions | Yes | Yes | Yes (via | | Event | | | | Receipt) | +---------------+-------------------+----------+--------+-----------+ | Verify Event | External | No | No | Yes | | | attestation | | | (independ-| | | | | | ent proof)| +---------------+-------------------+----------+--------+-----------+ 6.1.2. Lifecycle Events Lifecycle events form a cryptographically linked chain. Each event references its predecessor via prev_hash. Three lifecycle primitives: * Judge: Creates new judgment (genesis event) * Delegate: Transfers responsibility (enables cross-system handoff) * Terminate: Concludes judgment 6.1.3. Verify Events Verify events exist outside the lifecycle chain. They reference a specific lifecycle event via event_id and provide third-party attestation without modifying judgment state. 6.2. Common Fields Actor (lifecycle only) URI identifying the entity responsible for the judgment. Decision Cryptographic binding to decision content via decision_hash. Authority Scope URI referencing the policy or framework governing the judgment. Temporal Boundary Validity period via valid object with from and until timestamps. Proof Cryptographic signature with algorithm identification. 6.3. State Machine 6.3.1. States +------+-----------+-----------------------------------------------+ |Symbol| Name | Description | +------+-----------+-----------------------------------------------+ | A | Active | Judgment established; actor has control. | +------+-----------+-----------------------------------------------+ | D | Delegated | Responsibility transferred; new actor has | | | | control. | +------+-----------+-----------------------------------------------+ | P | Pending | Delegation initiated; awaiting acceptance. | +------+-----------+-----------------------------------------------+ | T | Terminal | Judgment concluded; no further lifecycle | | | | operations. | +------+-----------+-----------------------------------------------+ 6.3.2. State Transitions +-------+-------+----------------+-----------------------------------+ | From | To | Primitive | Condition | +-------+-------+----------------+-----------------------------------+ | null | A | Judge | Genesis (prev_hash = null) | +-------+-------+----------------+-----------------------------------+ | A | P | Delegate | Transfer initiated, awaiting | | | | | acceptance | +-------+-------+----------------+-----------------------------------+ | P | D | Delegate | Acceptance proof received | +-------+-------+----------------+-----------------------------------+ | P | A | [Timeout] | Auto-revert if acceptance timeout | +-------+-------+----------------+-----------------------------------+ | D | P | Delegate | Chained transfer initiated | +-------+-------+----------------+-----------------------------------+ | A/D | T | Terminate | Normal conclusion | +-------+-------+----------------+-----------------------------------+ | A/D/P | T | Terminate | Invalidation (with | | | | | authority_proof) | +-------+-------+----------------+-----------------------------------+ | A/D | T | Terminate | Timeout (system-triggered) | +-------+-------+----------------+-----------------------------------+ Invalid transitions (MUST be rejected): * Any transition from Terminal state * Judge with non-null prev_hash * Delegate without acceptance proof (unless policy waives requirement) 6.3.3. Delegation and Acceptance Flow Platform A (Delegator) Platform B (Delegatee) | | | 1. Create Delegate event | | State: A -> P (Pending) | | | | 2. Send Receipt + Request | |-------------------------------->| | | | | 3. Verify Receipt | | 4. Generate acceptance_proof | | | 5. Return acceptance_proof | |<--------------------------------| | | | 6. Update state: P -> D | | (Delegation complete) | Timeout Handling: If acceptance_proof is not received within policy- defined window (RECOMMENDED: 30 seconds to 5 minutes), the delegation MUST auto-revert to Active state (A). The Pending event remains in the chain as a tombstone for audit purposes. 6.4. Data Format 6.4.1. JSON Representation 6.4.1.1. Lifecycle Event Schema { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://hjs.org/schema/lifecycle-event-v1.json", "title": "HJS Lifecycle Event", "type": "object", "required": ["hjs", "id", "actor", "decision_hash", "authority_scope", "valid", "state", "prev_hash", "primitive", "proof"], "properties": { "hjs": {"type": "string", "const": "1.0"}, "id": {"type": "string", "format": "uuid"}, "actor": {"type": "string", "format": "uri"}, "decision_hash": { "type": "object", "required": ["hash", "alg"], "properties": { "hash": {"type": "string", "pattern": "^[a-f0-9]+$"}, "alg": {"enum": ["sha256", "sha3-256", "blake2b", "hmac-sha256", "sm3"]} } }, "authority_scope": {"type": "string", "format": "uri"}, "valid": { "type": "object", "required": ["from", "until"], "properties": { "from": {"type": "integer", "minimum": 0}, "until": {"type": "integer", "minimum": 0} } }, "state": {"enum": ["A", "D", "P", "T"]}, "prev_hash": { "oneOf": [ {"type": "object", "required": ["hash", "alg"]}, {"type": "null"} ] }, "primitive": { "type": "object", "required": ["type"], "properties": { "type": {"enum": ["J", "D", "T"]}, "payload": { "type": "object", "properties": { "to": {"type": "string", "format": "uri"}, "acceptance_proof": {"type": "string"}, "timeout_ms": {"type": "integer", "minimum": 0}, "reason": {"enum": ["completed", "cancelled", "voided_by_authority", "expired", "acceptance_timeout"]}, "authority_proof": {"type": "string"} } } } }, "extensions": {"type": "object"}, "proof": { "type": "object", "required": ["signature", "alg"], "properties": { "signature": {"type": "string"}, "alg": {"type": "string"}, "key_id": {"type": "string", "format": "uri"} } } } } 6.4.1.2. Verify Event Schema { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://hjs.org/schema/verify-event-v1.json", "title": "HJS Verify Event", "type": "object", "required": ["hjs", "verify", "proof"], "properties": { "hjs": {"type": "string", "const": "1.0"}, "verify": { "type": "object", "required": ["event_id", "method"], "properties": { "event_id": {"type": "string", "format": "uuid"}, "method": {"type": "string"}, "attestation": { "type": "object", "properties": { "format": {"enum": ["base64", "cbor", "jwt"]}, "data": {"type": "string"}, "alg": {"type": "string"} } }, "verifier": {"type": "string", "format": "uri"}, "timestamp": {"type": "integer"} } }, "proof": { "type": "object", "required": ["signature", "alg"], "properties": { "signature": {"type": "string"}, "alg": {"type": "string"}, "key_id": {"type": "string", "format": "uri"} } } } } 6.4.2. Serialization For signature generation and hash computation, events MUST be serialized using JSON Canonicalization Scheme (JCS) [RFC8785]. 6.4.3. Hash Computation // 1. Create a copy of the event const hashInput = { ...event }; // 2. Remove the proof field delete hashInput.proof; // 3. Canonicalize using JCS const canonical = jcs_canonicalize(hashInput); // 4. Compute SHA-256 (or SM3 for China-compliant deployments) const digest = sha256(canonical); // or sm3(canonical) // 5. Format as object const prev_hash = { "hash": hex_encode(digest), "alg": "sha256" // or "sm3" }; 6.5. HJS Receipt Format 6.5.1. Receipt Structure { "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://hjs.org/schema/receipt-v1.json", "title": "HJS Receipt", "type": "object", "required": ["hjs_receipt", "version", "event_id", "event_hash", "chain_proof", "anchor_proof", "verification_mode"], "properties": { "hjs_receipt": {"type": "string", "const": "1.0"}, "version": {"type": "string", "const": "1.0"}, "event_id": {"type": "string", "format": "uuid"}, "event_hash": { "type": "object", "required": ["hash", "alg"], "properties": { "hash": {"type": "string"}, "alg": {"enum": ["sha256", "sha3-256", "blake2b", "sm3"]} } }, "chain_proof": { "type": "object", "required": ["type", "anchor", "depth"], "properties": { "type": {"enum": ["linear", "merkle"]}, "anchor": { "type": "object", "required": ["hash", "alg"], "properties": { "hash": {"type": "string"}, "alg": {"type": "string"} } }, "depth": {"type": "integer", "minimum": 0}, "merkle_path": { "type": "array", "items": {"type": "string"} } } }, "anchor_proof": { "type": "object", "required": ["type", "timestamp"], "properties": { "type": { "enum": ["memory", "tsp", "ots", "scitt", "platform"] }, "timestamp": {"type": "integer"}, "data": {"type": "string"}, "uri": {"type": "string", "format": "uri"} } }, "verification_mode": {"enum": ["platform", "open", "dual"]}, "platform_attestation": { "type": "object", "properties": { "issuer": {"type": "string", "format": "uri"}, "issued_at": {"type": "integer"}, "signature": {"type": "string"}, "alg": {"type": "string"}, "key_id": {"type": "string", "format": "uri"} } }, "extensions": {"type": "object"} } } 6.5.2. Receipt Verification function verifyReceipt(receipt, event) { // 1. Verify event hash matches if (computeHash(event) !== receipt.event_hash.hash) { return {valid: false, reason: "hash_mismatch"}; } // 2. Verify chain integrity if (receipt.chain_proof.type === "linear") { // Verify linear chain } else if (receipt.chain_proof.type === "merkle") { // Verify Merkle path } // 3. Verify anchor proof switch(receipt.anchor_proof.type) { case "tsp": return verifyTSP(receipt.anchor_proof.data); case "ots": return verifyOTS(receipt.anchor_proof.data); case "scitt": return verifySCITT(receipt.anchor_proof.data); case "platform": return verifyPlatformSig(receipt.platform_attestation); default: return {valid: true}; // memory } } 6.6. Extensions Extensions use reverse domain notation with version suffix: { "extensions": { "org.veritaschain.vap.integrity@v1": { "merkle_root": "sha256:...", "inclusion_proof": ["0x1234...", "0x5678..."] }, "ietf.seat.binding@v1": { "session_id": "urn:uuid:...", "server_nonce": "...", "client_nonce": "..." } } } Guidelines: * Extensions MUST NOT alter core protocol semantics * Implementations SHOULD ignore unknown extensions * Version suffix enables evolution 7. HJS Verification Layer 7.1. Verification Modes +----------+--------------------+----------+--------------------------+ | Mode | Trust Root | Latency | Use Case | +----------+--------------------+----------+--------------------------+ | platform | HJS platform | <10ms | Real-time monitoring, | | | signature | | high-trust environments | +----------+--------------------+----------+--------------------------+ | open | Receipt | <1ms | Cross-platform | | | cryptographic proof| (local) | delegation, offline | | | | | audit, regulatory | | | | | verification | +----------+--------------------+----------+--------------------------+ | dual | Cross-confirmation | <100ms | High-value decisions, | | | | | maximum assurance | +----------+--------------------+----------+--------------------------+ 7.2. HTTP API 7.2.1. Event Retrieval GET /v1/events/{event_id} Retrieve a lifecycle or verify event. Response: LifecycleEvent | VerifyEvent 7.2.2. Chain Integrity Verification GET /v1/chains/{chain_id}/integrity Verify the integrity of a judgment lifecycle chain. Query params: * from: Starting event ID (optional) * to: Ending event ID (optional) * include_events: Boolean (default: false) { "chain_id": "...", "valid": true, "length": 3, "genesis": "...", "latest": "...", "events": [...], "platform_attestation": {...} } 7.2.3. Receipt Retrieval GET /v1/events/{event_id}/receipt Retrieve an HJS Receipt for offline verification. Query params: * mode: platform, open, or dual (default: open) * anchor_type: tsp, ots, scitt, or memory (optional) 7.2.4. Verification POST /v1/verify Verify an event using specified mode. Request: { "event": {...}, "receipt": {...}, "mode_preference": "dual", "require_receipt": true } Response (success): { "result": "valid", "mode_used": "dual", "checks": { "signature_valid": true, "chain_integrity": true, "anchor_verified": true, "platform_attestation": true }, "verified_at": 1712345678 } Response (disputed): { "result": "disputed", "mode_used": "dual", "dispute_details": { "platform_result": "valid", "open_result": "invalid", "reason": "receipt_chain_invalid", "platform_checks": { "signature_valid": true, "chain_integrity": true }, "open_checks": { "signature_valid": true, "chain_integrity": false, "chain_failure_reason": "prev_hash_mismatch" } }, "verified_at": 1712345678 } 8. Ecosystem Integration 8.1. Complementary Systems HJS provides judgment attribution that complements other systems in the accountability stack: +-----------+------------------------+-----------------------------+ | System | Their Contribution | HJS Contribution | +-----------+------------------------+-----------------------------+ | VAP | Data/model provenance | Decision attribution | | (Kamimura | | | | et al.) | | | +-----------+------------------------+-----------------------------+ | SEAT | Session security | Decision binding | | (Fossati | | | | et al.) | | | +-----------+------------------------+-----------------------------+ | Arize | Real-time monitoring | Tamper-proof decision logs | +-----------+------------------------+-----------------------------+ | WhyLabs | Data quality | Quality-event linkage | +-----------+------------------------+-----------------------------+ | Fiddler | Governance enforcement | Enforcement audit trail | +-----------+------------------------+-----------------------------+ 8.2. Complementary Relationship with SCITT 8.2.1. Core Differences +--------------+-----------------------------+-------------------------+ | Dimension | HJS | SCITT | +--------------+-----------------------------+-------------------------+ | Design Goal | Cross-platform responsibility| Global transparency | | | attribution | logging | +--------------+-----------------------------+-------------------------+ | State | Stateful (A/D/P/T states) | Stateless, append-only | | Semantics | | | +--------------+-----------------------------+-------------------------+ | Verification | Offline-first, self-contained| Requires querying | | Model | Receipt | transparency logs | +--------------+-----------------------------+-------------------------+ | Trust Model | No pre-trust required | Trust in log operator | | | between platforms | honesty | +--------------+-----------------------------+-------------------------+ 8.2.2. Complementary Usage Patterns +-----------------------+--------------------------+------------------+ | Integration Pattern | HJS Role | SCITT Role | +-----------------------+--------------------------+------------------+ | SCITT as Anchor Layer | Generate judgment events | Provide global | | | | transparency | | | | Receipt | +-----------------------+--------------------------+------------------+ | HJS as Semantic Layer | Provide state machine | Optional log | | | and Receipt format | storage | +-----------------------+--------------------------+------------------+ | Hybrid Mode | Core responsibility chain| Optional | | | | transparency | | | | enhancement | +-----------------------+--------------------------+------------------+ 8.3. Alignment with VAP Framework The Verifiable AI Provenance (VAP) Framework defines a layered architecture: +---------------+---------------------------------------------------+ | Layer | Description | +---------------+---------------------------------------------------+ | Integrity | Tamper-evident recording of events | +---------------+---------------------------------------------------+ | Provenance | Recording of decision inputs and contextual | | | factors | +---------------+---------------------------------------------------+ | Accountability| Attribution of responsibility and decision | | | authority | +---------------+---------------------------------------------------+ | Completeness | Guarantees against omission and selective | | | disclosure | +---------------+---------------------------------------------------+ 8.4. Integration with SEAT The Session Evidence Attestation Transport (SEAT) protocol prevents replay attacks. SEAT and HJS provide complementary security: * SEAT focuses on: "Is this communication session authentic?" * HJS focuses on: "Is this decision properly attributed?" 8.5. Relationship to RATS Architecture +------------------+-------------------------------------------------+ | RATS Concept | HJS Mapping | +------------------+-------------------------------------------------+ | Attester | The AI platform or agent generating a Lifecycle | | | Event | +------------------+-------------------------------------------------+ | Attestation | An HJS Lifecycle Event | | Evidence | | +------------------+-------------------------------------------------+ | Verifier | A relying party validating an HJS Receipt | +------------------+-------------------------------------------------+ | Attestation | The HJS Receipt | | Result | | +------------------+-------------------------------------------------+ 8.6. Integration with Monitoring Platforms +-----------+--------------------------+------------------------------+ | Platform | Primary Focus | HJS Complement | +-----------+--------------------------+------------------------------+ | Arize AI | Detecting model drift | Recording which decisions | | | and performance issues | triggered the drift | +-----------+--------------------------+------------------------------+ | WhyLabs | Profiling data quality | Linking quality issues to | | | and anomalies | responsible decision-makers | +-----------+--------------------------+------------------------------+ | Fiddler | Enforcing governance | Logging who made policy | | AI | policies | overrides | +-----------+--------------------------+------------------------------+ 8.7. Relationship to AIP (Agent Identity Protocol) +-------+-------------------+-----------------------------------------+ | Layer | AIP Focus | HJS Complement | +-------+-------------------+-----------------------------------------+ | Iden- | Who is the agent? | Records which agent made which decision | | tity | | | +-------+-------------------+-----------------------------------------+ | Gove- | What policies | Records which policies were invoked | | rnance| apply? | | +-------+-------------------+-----------------------------------------+ | Enfor-| How are policies | Records enforcement actions | | cement| enforced? | | +-------+-------------------+-----------------------------------------+ | Evide-| (AIP defers this) | Tamper-evident decision logs | | nce | | | +-------+-------------------+-----------------------------------------+ 8.8. HJS as Inter-Agent Communication Protocol 8.8.1. The Cross-System Delegation Problem Consider a multi-platform AI workflow: * Platform A: Medical AI system makes initial diagnosis * Need: Transfer to specialized system on Platform B for second opinion * Challenge: Platform B must accept responsibility transfer without trusting Platform A * Regulatory Requirement: External auditor must verify complete chain without platform access 8.8.2. Cross-System Delegation Flow CROSS-SYSTEM DELEGATION +--------------+ (1) Receipt +--------------+ | Platform A | -------> | Platform B | | (AWS) | (portable credential) | (Azure) | +--------------+ +--------------+ | | v v +---------+ +---------+ | Agent X | -----Delegate(Receipt)---> | Agent Y | +---------+ +---------+ | | v v +---------+ +---------+ | TSP/ | | TSP/ | | OTS | <------(2) Public Verify---| OTS | | Anchor | (Timestamping) | Anchor | +---------+ +---------+ 8.8.3. Receipt as Universal Credential +------------------+--------------------------------+------------------+ | Property | Mechanism | Benefit | +------------------+--------------------------------+------------------+ | Self-contained | Includes all proofs in single | No external | | | JSON object | dependencies for | | | | verification | +------------------+--------------------------------+------------------+ | Tamper-evident | Hash chain + cryptographic | Any modification | | | signatures | invalidates the | | | | proof | +------------------+--------------------------------+------------------+ | Time-bound | TSP/OTS/SCITT anchoring to | Independent | | | public ledgers | timestamp | | | | verification | +------------------+--------------------------------+------------------+ | Privacy- | Decision content hashed, | Reveal only | | preserving | metadata selective | necessary | | | | information | +------------------+--------------------------------+------------------+ | Extensible | Standard extension mechanism | Carry partner | | | | protocol data | +------------------+--------------------------------+------------------+ 8.9. What HJS Does NOT Do HJS intentionally does NOT provide: * Data provenance -> VAP, SCITT * Session security -> SEAT, TLS * Real-time monitoring -> Arize, WhyLabs * Governance policy engines -> Fiddler, organizational systems * Model explainability -> SHAP, LIME * Identity verification -> DID, SPIFFE, AIP * Regulatory compliance judgments -> Legal and compliance professionals 9. Security Considerations 9.1. Signature Validation All lifecycle transitions MUST be cryptographically signed by the responsible actor. 9.2. Chain Integrity Implementations MUST verify: * Each prev_hash matches the previous event's hash * No forks or gaps in the chain * Genesis event has prev_hash: null 9.3. Replay Attacks and Connection Binding To prevent relay attacks, implementations SHOULD bind HJS events to the connection context using mechanisms such as those defined in [I-D.fossati-seat-expat]. Proof that is not bound to the connection may be susceptible to replay across different sessions. Implementations SHOULD: * Use UUIDv7 for unique event IDs * Validate timestamps against acceptable skew * Bind events to domain-specific context * Use SEAT session binding for connection-oriented protocols 9.4. Delegation Security To prevent unauthorized delegation: * Implementations SHOULD require acceptance_proof in Delegate payload * Acceptance MUST be signed by the receiving actor * Timeout and auto-terminate if acceptance not received within policy window 9.5. Time Source Security Implementations MUST: * Use at least two independent time sources (e.g., NTP + TSP/OTS) * Validate time skew < 1000ms between sources * Reject future timestamps (> now + 60s) * Reject timestamps significantly in the past (< now - 86400s, i.e., 24 hours) * Include time attestations in Receipts when available 9.6. UUIDv7 Clock Dependency Implementations generating UUIDv7 for event id fields MUST ensure that the system clock is synchronized using a secure protocol (e.g., NTP with authentication) and is protected from unauthorized modification. In high-security environments where clock manipulation is a concern, implementations SHOULD consider using UUIDv4 instead, trading off time- sortability (a key feature of UUIDv7) for reduced reliance on clock integrity. The choice of UUID version is an implementation decision; the protocol supports both. 9.7. Trust Model Summary HJS provides cryptographic evidence of who said what when. The verification of whether they *should* have said it is addressed by governance systems and partner platforms. 9.8. Post-Quantum Cryptography Migration HJS is designed for long-term verifiability—a judgment Receipt created today may need verification in 10, 20, or 30 years. This requires consideration of quantum computing threats to current cryptographic algorithms. 9.8.1. Risk Assessment +-------------+------------------+------------------+-----------------+ | Algorithm | Classical | Quantum Threat | Estimated Risk | | | Security | | Timeline | +-------------+------------------+------------------+-----------------+ | Ed25519 | High | Shor's algorithm | 2030-2035 | +-------------+------------------+------------------+-----------------+ | SHA-256 | High | Grover's | Requires hash | | | | algorithm | length doubling | +-------------+------------------+------------------+-----------------+ | SM2/SM3 | High | Same as above | Same as above | +-------------+------------------+------------------+-----------------+ 9.8.2. Algorithm-Agnostic Design HJS data structures are designed for PQC migration: { "proof": { "alg": "ed25519", // Extensible to multiple algorithms "signature": "base64..." } } 9.8.3. Dual Signatures (High-Security Scenarios) For scenarios requiring long-term assurance, implementations can use both classical and PQC signatures: { "proof": [ { "alg": "ed25519", "signature": "base64-classic-sig" }, { "alg": "ml-dsa-65", // ML-DSA (FIPS 204) "signature": "base64-pqc-sig" } ] } 9.8.4. Migration Timeline (March 2026) +-------------+----------------+--------------------------------------+ | Phase | Timeframe | Recommended Actions | +-------------+----------------+--------------------------------------+ | Preparation | Current (2026) | Implement optional PQC support | | | | alongside classical signatures | +-------------+----------------+--------------------------------------+ | Transition | 2026-2028 | New systems enable PQC by default; | | | | critical systems require dual | | | | signatures | +-------------+----------------+--------------------------------------+ | Completion | 2028+ | Classical signatures marked as | | | | "legacy"; PQC becomes primary | +-------------+----------------+--------------------------------------+ 9.8.5. Long-Term Receipt Verification For Receipts that must remain verifiable for decades: 1. Periodic Re-anchoring: Re-anchor Receipt hashes to new timestamp services every 5-10 years 2. Signature Refresh: Re-sign old Receipts with newer algorithms (preserving original signatures) 3. Context Preservation: Save verification context (CA certificates, algorithm specifications) { "hjs_receipt": "1.0", "event_id": "2026-event", "proof_history": [ { "alg": "ed25519", "signature": "...", "valid_from": "2026-01-01" }, { "alg": "ml-dsa-65", "signature": "...", "valid_from": "2028-01-01", "re_signed_by": "original-platform" } ] } 10. Privacy Considerations 10.1. Decision Content Privacy Use HMAC or salted hashing for low-entropy decisions to prevent rainbow table attacks. 10.2. Metadata Leakage Event fields may reveal sensitive information. Implementations SHOULD: * Use pseudonymous identifiers for actor in public contexts * Encrypt sensitive extension fields * Minimize metadata disclosure 10.3. Data Minimization Implementations SHOULD only collect metadata essential for accountability, deferring domain-specific requirements to extensions. 10.4. GDPR and the "Right to be Forgotten" HJS events are designed to be immutable and tamper-evident, which creates tension with GDPR Article 17 ("right to erasure"). This specification does not resolve this tension but notes current practices: +----------------------+--------------------------+-------------------+ | Approach | Description | Trade-off | +----------------------+--------------------------+-------------------+ | Cryptographic | Key destruction rendering| Irreversible; may | | deletion | events undecryptable | violate audit | | | | requirements | +----------------------+--------------------------+-------------------+ | Redaction markers | Tombstone events marking | Maintains chain | | | data as "erased" | integrity; visible| | | | that data existed | +----------------------+--------------------------+-------------------+ | Off-chain data | Store sensitive data | HJS events remain;| | | externally, reference via| external data can | | | hash | be deleted | +----------------------+--------------------------+-------------------+ | Legal basis | Rely on "legitimate | Requires legal | | | interest" or "legal | assessment; not | | | obligation" | technical solution| +----------------------+--------------------------+-------------------+ 11. IANA Considerations 11.1. Media Types Type name: application Subtype name: hjs+json Required parameters: None Optional parameters: version (default: "1.0") type (values: "lifecycle", "verify") Encoding considerations: Binary Security considerations: See Section 9 Published specification: This document Contact: Yuqiang Wang Intended usage: COMMON Change controller: IETF Type name: application Subtype name: hjs-receipt+json Required parameters: None Optional parameters: version (default: "1.0") mode (values: "full", "existence", "selective") Encoding considerations: Binary Security considerations: See Section 9 Published specification: This document Contact: Yuqiang Wang Intended usage: COMMON Change controller: IETF 11.2. Well-Known URI URI suffix: hjs Change controller: IETF 12. 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, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9562] Davis, K., Peabody, B., and M. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . 13. Informative References [I-D.fossati-seat-expat] Fossati, T. and H. Tschofenig, "Session Evidence Attestation Transport (SEAT) and Exported Authenticators", Work in Progress, Internet-Draft, draft-fossati-seat-expat-00, 27 February 2026, . [I-D.ietf-scitt-architecture] Birkholz, H., Steele, O., Hoyland, J., Richardson, M., and S. Hunt, "An Architecture for Trustworthy Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt- architecture-04, 27 January 2026, . [I-D.kamimura-vap-framework] Kamimura, T., "Verifiable AI Provenance (VAP) Framework", Work in Progress, Internet-Draft, draft-kamimura-vap- framework-00, 23 February 2026, . Acknowledgments HJS was developed with input from protocol authors, platform teams, and industry experts who each contribute essential capabilities to AI accountability: Protocol Design Partners Tokachi Kamimura and the VAP team — Their work on provenance layers clarified the architectural boundary between integrity, provenance, and accountability. Thomas Fossati and the SEAT team — Their analysis of relay attacks informed the session binding mechanisms that protect HJS events in transit. James (yungcero) and the Agent Identity Protocol (AIP) team — Their work on agent identity and governance layers provided a concrete context for HJS's evidence layer. Platform Integration Partners Arize AI — Production requirements for real-time verification helped validate the dual verification mode. Fiddler AI — Governance enforcement use cases shaped the Terminate reason codes and authority validation logic. WhyLabs — Requirements for linking data quality events to decision attribution informed the extension design. Industry Experts Wang Aijun (DMSC) — Professional guidance and support that contributed to the technical development of HJS. Community Contributors Usama — Feedback on relay attacks and security considerations prompted stronger alignment with SEAT. Arnaud Taddei — Insights on SG17/RATS work helped clarify HJS's relationship to broader attestation frameworks. Appendix A. Reference Implementation A Rust-based reference implementation of the HJS protocol is planned and will be released as open source on GitHub. The repository URL will be provided in a future revision of this document. Appendix B. Dispute Handling Decision Framework B.1. Overview When dual mode verification returns disputed, the relying party must make a trust decision. This appendix provides a decision framework, not a normative protocol requirement. B.2. Risk Assessment Matrix +----+----------+---------+-----------+------------------------------+ | Sc | Platform | Open | Risk | Recommended Action | | en-| Result | Result | Level | | | a- | | | | | | rio| | | | | +----+----------+---------+-----------+------------------------------+ | 1 | valid | invalid | Critical | Reject event; alert security | | | | | | team; preserve evidence | +----+----------+---------+-----------+------------------------------+ | 2 | invalid | valid | High | Reject event; platform may | | | | | | be compromised or censored | +----+----------+---------+-----------+------------------------------+ | 3 | valid | valid | Medium | Clock skew or implementation | | | | (mismat-| | bug; retry with fresh data | | | | ch) | | | +----+----------+---------+-----------+------------------------------+ | 4 | timeout | valid | Low-Medium| Accept open result if | | | | | | platform unreachable; log | | | | | | anomaly | +----+----------+---------+-----------+------------------------------+ | 5 | timeout | invalid | High | Reject event; insufficient | | | | | | verification | +----+----------+---------+-----------+------------------------------+ B.3. Decision Tree DISPUTE RECEIVED | v Is platform_result = valid AND open_result = invalid? | +-- YES --> CRITICAL RISK | | | v | Platform may be compromised | OR Receipt has been tampered | | | v | ACTION: Reject, Alert, Preserve | +-- NO --> Is platform_result = invalid AND open_result = valid? | +-- YES --> HIGH RISK | | | v | Platform censorship | OR platform key compromise | | | v | ACTION: Reject, Investigate platform | +-- NO --> MEDIUM/LOW RISK | v Clock skew or transient error | v ACTION: Retry, then decide based on policy B.4. Implementation Recommendations Logging: All disputes MUST be logged with: * Full Receipt content * Platform attestation response (if any) * Local verification details * Timestamp and context Alerting: Critical and High risk disputes SHOULD trigger immediate alerts to security operations. Evidence Preservation: Dispute data may be required for forensic analysis. Implementations SHOULD retain dispute records for at least 90 days or per regulatory requirement. Appendix C. Implementation Risks and Mitigations C.1. Asynchronous Delegation Risks Risk: Delegate operation requires acceptance_proof from receiving platform, creating availability dependency. Mitigation: * Pending state with timeout (Section 6.3.3) * Idempotent acceptance handling for retries * Clear error semantics for timeout vs. rejection C.2. Clock Synchronization Risks Risk: UUIDv7 and timestamp validation depend on system clock accuracy. Mitigation: * Multi-source time validation (Section 9.5) * UUIDv4 fallback option (Section 9.6) * Tolerance windows for clock skew C.3. Platform Compromise Detection Risk: Dual mode detects compromise but creates false positives under benign conditions (clock skew, network issues). Mitigation: * Retry logic for transient failures * Dispute classification (Appendix B) * Graduated response rather than hard failure C.4. Adoption Dependencies Risk: HJS value depends on multi-platform adoption. Single-platform deployment provides limited benefit. Mitigation: * Reference implementation availability * Clear integration patterns with existing platforms C.5. Alternative Deployment Paths If broad IETF standardization does not achieve traction, HJS may provide value through: +------------------+----------------------+--------------------------+ | Path | Condition | Value Proposition | +------------------+----------------------+--------------------------+ | Vertical | Single industry | Deep integration with | | solution | (healthcare/finance) | sector-specific | | | adopts | compliance requirements | +------------------+----------------------+--------------------------+ | Open source | Apache 2.0 | Rapid iteration without | | project | governance, | standardization overhead | | | community-driven | | +------------------+----------------------+--------------------------+ | Regulatory | Direct engagement | Compliance tooling | | technology | with specific | rather than universal | | | regulators | standard | +------------------+----------------------+--------------------------+ Author's Address Yuqiang Wang HUMAN JUDGMENT SYSTEMS FOUNDATION LTD. Email: signal@humanjudgment.org GitHub: https://github.com/schchit