Network Working Group Y. Wang Internet-Draft 26 September 2026 Intended status: Experimental Expires: 30 March 2027 JEP Receipt Profile: Verifiable Behavior and Evidence Receipts draft-wang-jep-receipt-profile-00 Abstract This document defines JEP Receipt Profile 1 (JEP-RP-1), a minimal receipt and evidence profile for the Judgment Event Protocol (JEP) [JEP]. JEP-RP-1 binds a JEP event to one digest-addressed receipt record through a critical JEP extension. It defines a small behavior-record format, portable receipt manifests and bundles, and independent receipt-validation checks. JEP remains authoritative for event verbs, Event Identity, Event Hash, signature processing, references, extension processing, validation modes, and acceptance semantics. Receipt records are technical evidence about observable behavior and related artifacts. JEP-RP-1 does not assign legal liability, prove subjective intent, establish authorization validity, determine causality or factual truth, define governance outcomes, or establish regulatory compliance. 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 30 March 2027. Wang Expires 30 March 2027 [Page 1] Internet-Draft JEP Receipt Profile September 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Scope and Layering . . . . . . . . . . . . . . . . . . . . . 4 3.1. JEP-RP-1 Defines . . . . . . . . . . . . . . . . . . . . 4 3.2. JEP-RP-1 Does Not Define . . . . . . . . . . . . . . . . 4 3.3. JEP Ownership . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Actor, Signer, and Observed Agent . . . . . . . . . . . . 6 4. Profile and Extension Identifiers . . . . . . . . . . . . . . 6 4.1. Receipt Profile Identifier . . . . . . . . . . . . . . . 6 4.2. Receipt-Binding Extension Identifier . . . . . . . . . . 6 4.3. Version and Naming Boundary . . . . . . . . . . . . . . . 7 5. Receipt Event Model . . . . . . . . . . . . . . . . . . . . . 7 5.1. Receipt Event . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Use of J, D, T, and V . . . . . . . . . . . . . . . . . . 7 5.3. who . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. ref . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Receipt-Binding Extension . . . . . . . . . . . . . . . . . . 8 6.1. Extension Value . . . . . . . . . . . . . . . . . . . . . 8 6.2. Extension Example . . . . . . . . . . . . . . . . . . . . 9 6.3. One Primary Record . . . . . . . . . . . . . . . . . . . 9 7. Behavior Records . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Required Shape . . . . . . . . . . . . . . . . . . . . . 9 7.2. Evidence Descriptor . . . . . . . . . . . . . . . . . . . 10 7.3. Human Participant Reference . . . . . . . . . . . . . . . 11 7.4. Context and Redaction . . . . . . . . . . . . . . . . . . 12 7.5. Behavior Record Digest . . . . . . . . . . . . . . . . . 12 8. Receipt Manifests . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Manifest Shape . . . . . . . . . . . . . . . . . . . . . 12 8.2. Event Descriptor . . . . . . . . . . . . . . . . . . . . 13 8.3. Record Descriptor . . . . . . . . . . . . . . . . . . . . 14 8.4. Binding-Event Circularity Rule . . . . . . . . . . . . . 14 8.5. Manifest Digest . . . . . . . . . . . . . . . . . . . . . 14 Wang Expires 30 March 2027 [Page 2] Internet-Draft JEP Receipt Profile September 2026 9. Receipt Bundles and Export . . . . . . . . . . . . . . . . . 15 9.1. Bundle . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Partial and Redacted Export . . . . . . . . . . . . . . . 15 9.3. No Chain Inference . . . . . . . . . . . . . . . . . . . 15 10. Receipt Validation . . . . . . . . . . . . . . . . . . . . . 16 10.1. Layer Separation . . . . . . . . . . . . . . . . . . . . 16 10.2. Baseline Validation Mode . . . . . . . . . . . . . . . . 16 10.3. Receipt Profile Checks . . . . . . . . . . . . . . . . . 16 10.4. Receipt Profile Overall Status . . . . . . . . . . . . . 17 10.5. Validation Procedure . . . . . . . . . . . . . . . . . . 17 10.6. Receipt Validation Result Example . . . . . . . . . . . 18 11. Verification Events . . . . . . . . . . . . . . . . . . . . . 19 12. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. JEP-RP-1 Producer . . . . . . . . . . . . . . . . . . . 20 12.2. JEP-RP-1 Verifier . . . . . . . . . . . . . . . . . . . 20 12.3. Receipt Bundle Verifier . . . . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 15. Non-Inference Boundary . . . . . . . . . . . . . . . . . . . 23 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 17.1. Behavior Record . . . . . . . . . . . . . . . . . . . . 24 17.2. J Event Carrying a Receipt Binding . . . . . . . . . . . 24 17.3. Receipt Manifest . . . . . . . . . . . . . . . . . . . . 25 18. Transition from HJS-05 . . . . . . . . . . . . . . . . . . . 26 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 19.1. Normative References . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction AI agents and automated services increasingly act across platforms, organizations, tools, and jurisdictions. Operators, counterparties, auditors, and downstream systems may need a portable record showing that a specific JEP event was cryptographically bound to a specific behavior or receipt record. JEP-RP-1 provides that receipt layer. The narrow profile question is: Which JEP event was signed, which receipt record was bound to it, and can that binding be independently revalidated? The profile deliberately does not answer whether the recorded action was correct, authorized, fair, lawful, causally complete, or sufficient for an external policy. Wang Expires 30 March 2027 [Page 3] Internet-Draft JEP Receipt Profile September 2026 JEP Profiles [JEP-PROFILES] defines the general profile-selection and composition model. JEP Conformance [JEP-CONFORMANCE] defines executable Core validation-result and test-harness conventions used by Receipt Profile implementations. Earlier work used the technical name HJS in draft-wang-hjs- accountability. This document uses a new Internet-Draft filename and is intended to replace that draft series. The protocol component name is JEP Receipt Profile. Organizational names are outside the protocol namespace. Where this document conflicts with JEP-Core, JEP-Core controls. 2. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. Scope and Layering 3.1. JEP-RP-1 Defines JEP-RP-1 defines: * one explicit Receipt Profile identifier; * one critical receipt-binding extension; * one minimal behavior-record format; * one receipt-manifest format; * receipt-bundle packaging semantics; * independent receipt-validation checks; * privacy and non-inference requirements. 3.2. JEP-RP-1 Does Not Define JEP-RP-1 does not define: * new JEP verbs; * an independent signature format; Wang Expires 30 March 2027 [Page 4] Internet-Draft JEP Receipt Profile September 2026 * a replacement for Event Identity or Event Hash; * chain causality or complete-log semantics; * authorization or delegation validity; * legal liability, fault, intent, negligence, consent, fairness, or harm; * regulatory compliance; * monitoring duties, sanctions, remedies, or appeal rights; * a global identity or trust framework; * a mandatory archive format; * a global model, tool, risk, or policy taxonomy. 3.3. JEP Ownership JEP-Core is authoritative for: * J, D, T, and V semantics; * required Core event fields; * Event Identity (who,id); * Event Hash; * the JEP Signing Payload; * signature processing; * ref; * ext and ext_crit; * independent Core validation checks; * validation modes; * acceptance outcomes and idempotent acceptance. JEP-RP-1 MUST NOT redefine those semantics. Wang Expires 30 March 2027 [Page 5] Internet-Draft JEP Receipt Profile September 2026 3.4. Actor, Signer, and Observed Agent JEP-RP-1 distinguishes three concepts: * *JEP actor*: the actor claimed by the JEP who field; * *signer*: the key holder that produced the JEP signature; * *observed agent*: the AI agent, runtime, service, or automated component described by the behavior record. These MAY refer to the same entity, but JEP-RP-1 MUST NOT assume that they do. Actor/key binding is determined by the selected trust profile. The observed-agent identifier is evidence content. It does not establish that the observed agent controlled the signing key or emitted the JEP event. 4. Profile and Extension Identifiers 4.1. Receipt Profile Identifier The JEP-RP-1 profile identifier is: https://humanjudgment.org/jep/profiles/receipt/1 The human-readable label JEP-RP-1 MAY be used in documentation and user interfaces. The profile identifier is a publisher-controlled HTTPS URI. Dereferencing it is not required for validation. The publisher SHOULD keep the URI stable and SHOULD make profile documentation available there when practical. 4.2. Receipt-Binding Extension Identifier The JEP-RP-1 receipt-binding extension identifier is: https://humanjudgment.org/jep/extensions/receipt-binding/1 An event claiming JEP-RP-1 conformance MUST carry this extension under JEP ext and MUST list the identifier in ext_crit. A verifier that does not understand this critical extension cannot claim successful JEP-RP-1 validation. Wang Expires 30 March 2027 [Page 6] Internet-Draft JEP Receipt Profile September 2026 4.3. Version and Naming Boundary JEP-RP-1 is not wire-compatible with the HJS-Core-1 binding model used by draft-wang-hjs-accountability-05. HJS-Core-1 commonly placed an external record digest in JEP what. That model is not a valid generic binding rule for JEP-Core 0.7 because D, T, and V have verb-specific required what members. JEP-RP-1 therefore moves receipt binding into a critical JEP extension and leaves Core what semantics entirely under JEP-Core. Historical HJS-Core-1 receipts MUST NOT be silently rewritten as JEP- RP-1 receipts. 5. Receipt Event Model 5.1. Receipt Event A JEP-RP-1 Receipt Event is a JEP-Core event that: * validates under the requested JEP validation mode and selected profiles; * carries the JEP-RP-1 receipt-binding extension; * lists that extension in ext_crit; * binds exactly one primary receipt record by digest. The underlying JEP verb remains authoritative. 5.2. Use of J, D, T, and V JEP-RP-1 does not assign new meanings to J, D, T, or V. A producer MUST satisfy the JEP-Core requirements for the selected verb before receipt binding is considered. In particular: * a D event MUST retain the Core D what.delegatee and what.scope semantics; * a T event MUST retain the Core T what.termination_scope and ref semantics; Wang Expires 30 March 2027 [Page 7] Internet-Draft JEP Receipt Profile September 2026 * a V event MUST retain the Core V what.verification_scope, what.result, and ref semantics. Receipt metadata MUST NOT replace those Core fields. 5.3. who The JEP who field identifies the actor claimed by the Receipt Event. JEP-RP-1 MUST NOT describe who as a verified signer identity unless the applicable actor-binding check actually passed. who SHOULD NOT contain plaintext personal information unless the deployment requires that form and has an appropriate privacy basis. 5.4. ref JEP-RP-1 uses JEP ref exactly as defined by JEP-Core. A logical reference to another JEP event SHOULD use Event Identity. An optional Event Hash MAY pin an exact signed artifact. JEP-RP-1 MUST NOT use Event Hash as a substitute for stable Event Identity when the reference is logically about an event. The presence of a JEP reference does not establish causality, completeness, authorization, endorsement, or legal effect. 6. Receipt-Binding Extension 6.1. Extension Value The receipt-binding extension value MUST be a JSON object containing: * profile * record_type * record_digest * media_type profile MUST equal https://humanjudgment.org/jep/profiles/receipt/1. record_type MUST be one of: * behavior Wang Expires 30 March 2027 [Page 8] Internet-Draft JEP Receipt Profile September 2026 * receipt-manifest record_digest MUST be an algorithm-tagged digest string conforming to the JEP digest-string rules. media_type MUST be a non-empty string. JEP-RP-1 JSON records use application/json. The extension MAY additionally contain record_uri. If present, record_uri is a retrieval hint only. Validation MUST NOT depend solely on trusting the retrieved location. 6.2. Extension Example { "ext": { "https://humanjudgment.org/jep/extensions/receipt-binding/1": { "profile": "https://humanjudgment.org/jep/profiles/receipt/1", "record_type": "behavior", "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "media_type": "application/json" } }, "ext_crit": [ "https://humanjudgment.org/jep/extensions/receipt-binding/1" ] } The example digest is illustrative and is not a test vector. 6.3. One Primary Record Each JEP-RP-1 Receipt Event binds exactly one primary receipt record through the receipt extension. Additional evidence objects are referenced from that primary record or a receipt manifest. This rule avoids ambiguity about which object the Receipt Event primarily authenticates. 7. Behavior Records 7.1. Required Shape A JEP-RP-1 behavior record MUST be a JSON object containing: * jep_receipt_record * record_type Wang Expires 30 March 2027 [Page 9] Internet-Draft JEP Receipt Profile September 2026 * agent * action * created_at * evidence jep_receipt_record MUST equal "1". record_type MUST equal "behavior". agent MUST be a JSON object containing a non-empty string id. agent.role and agent.deployment_id MAY be present as non-empty strings. action MUST be a JSON object containing a non-empty string type. Additional action fields are deployment-defined. created_at MUST be a non-negative integer representing declared Unix seconds for record creation. It is not trusted time or proof of freshness. evidence MUST be a JSON array of zero or more Evidence Descriptors. The record MAY additionally contain: * human_participants * context * redaction No other top-level members are defined by JEP-RP-1. Additional structured content SHOULD be placed in evidence objects or defined by an explicitly selected companion profile. 7.2. Evidence Descriptor An Evidence Descriptor MUST be a JSON object containing: * kind * digest kind MUST be a non-empty string describing the evidence class. digest MUST be an algorithm-tagged digest string. Wang Expires 30 March 2027 [Page 10] Internet-Draft JEP Receipt Profile September 2026 An Evidence Descriptor MAY additionally contain: * media_type * uri * redaction media_type, when present, MUST be a non-empty string. uri, when present, is a retrieval hint. A verifier MUST NOT treat URI dereference success as evidence-integrity success. redaction, when present, SHOULD be one of: * none * partial * digest-only * withheld A companion profile MAY define additional redaction values. 7.3. Human Participant Reference human_participants, when present, MUST be an array of structured references. Each reference MUST contain: * role * reference_type role and reference_type MUST be non-empty strings. If reference_type is not withheld, the object MUST contain reference. If reference_type is withheld, reference MUST be absent. A reference MAY contain privacy_mode and salt_holder. JEP-RP-1 does not guarantee anonymity or unlinkability. Timing, metadata, content similarity, device identifiers, storage locations, or salt reuse can create linkability. Wang Expires 30 March 2027 [Page 11] Internet-Draft JEP Receipt Profile September 2026 7.4. Context and Redaction context, when present, MUST be a JSON object whose semantics are defined by the deployment or companion profile. redaction, when present, MUST be a JSON object describing minimization or redaction applied to the behavior record or its referenced evidence. The presence of a redaction descriptor does not prove that redaction was legally required, sufficient, complete, or correctly performed. 7.5. Behavior Record Digest For JEP-RP-1, the Behavior Record Digest uses JCS [RFC8785] and is: sha256(UTF8(JCS(behavior_record))) The textual digest is represented as a JEP algorithm-tagged digest string. JEP-RP-1 producers and verifiers MUST support sha256 for behavior- record digests. A companion profile MAY permit additional digest algorithms but MUST NOT change the meaning of the JEP-RP-1 baseline digest. A behavior record MUST NOT embed the Event Hash of the JEP event that binds it, because doing so would create a circular artifact dependency. 8. Receipt Manifests 8.1. Manifest Shape A JEP-RP-1 receipt manifest MUST be a JSON object containing: * jep_receipt_manifest * profile * root_event * events * records * created_at Wang Expires 30 March 2027 [Page 12] Internet-Draft JEP Receipt Profile September 2026 jep_receipt_manifest MUST equal "1". profile MUST equal https://humanjudgment.org/jep/profiles/receipt/1. root_event MUST be an Event Descriptor. events MUST be a non-empty array of Event Descriptors. records MUST be a non-empty array of Record Descriptors. created_at MUST be a non-negative integer representing declared Unix seconds for manifest creation. It is not trusted time. A receipt manifest MAY additionally contain: * external_refs * redaction 8.2. Event Descriptor An Event Descriptor MUST contain event_identity: { "event_identity": { "who": "did:example:agent-123", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" } } event_identity.who and event_identity.id MUST be non-empty strings. An Event Descriptor MAY additionally contain: * event_hash * uri event_hash, when present, pins one exact signed event artifact. uri, when present, is only a retrieval hint. Every Event Identity in events MUST be unique within the manifest. root_event.event_identity MUST equal one Event Identity listed in events. Wang Expires 30 March 2027 [Page 13] Internet-Draft JEP Receipt Profile September 2026 If root_event.event_hash is present, it MUST equal the Event Hash for the corresponding exact signed artifact, except as prohibited by Section 8.4. 8.3. Record Descriptor A Record Descriptor MUST contain: * record_type * digest record_type MUST be a non-empty string. digest MUST be an algorithm-tagged digest string. A Record Descriptor MAY additionally contain: * media_type * uri The digest, not the URI, is the integrity identity of the record. 8.4. Binding-Event Circularity Rule If a JEP Receipt Event binds a receipt manifest as its primary record, that manifest MUST identify the binding event by Event Identity and MUST NOT include the binding event's Event Hash anywhere in the manifest. This rule applies to both root_event and any corresponding entry in events. The manifest MAY include Event Hash values for other JEP events. A verifier MUST reject a manifest that includes the binding event's Event Hash, because the binding Event Hash depends on the signed extension containing the manifest digest and would create a circular artifact dependency. 8.5. Manifest Digest A JSON receipt manifest is digest-addressed using: sha256(UTF8(JCS(receipt_manifest))) Wang Expires 30 March 2027 [Page 14] Internet-Draft JEP Receipt Profile September 2026 A Receipt Event MAY bind a receipt manifest as its primary record by using record_type equal to receipt-manifest in the receipt-binding extension. 9. Receipt Bundles and Export 9.1. Bundle A JEP receipt bundle is a packaging concept containing zero or more: * signed JEP events; * behavior records; * receipt manifests; * validation reports; * external evidence objects. JEP-RP-1 does not define a validation-report primary record type. Validation reports MAY appear as bundle artifacts, but their structure and semantics are outside the JEP-RP-1 baseline. JEP-RP-1 does not define a mandatory ZIP, CBOR, JSON, archive, transport, or storage container. Packaging MUST NOT alter signed JEP event bytes or misrepresent digest-bound record content. 9.2. Partial and Redacted Export A bundle MAY contain only a subset of available evidence. A partial or redacted export MUST NOT present omitted material as nonexistent, unchanged, irrelevant, agreed, waived, or verified. Where omission could affect interpretation, the export SHOULD include an explicit withheld, redacted, or partial-view indication. 9.3. No Chain Inference A bundle containing multiple events is not, merely by being a bundle, a causal chain, responsibility chain, authorization chain, or complete event history. Wang Expires 30 March 2027 [Page 15] Internet-Draft JEP Receipt Profile September 2026 Chain reconstruction, cycle analysis, termination cascade, complete- log assumptions, and causal interpretation belong to a selected chain profile or external system. 10. Receipt Validation 10.1. Layer Separation Receipt validation reports separately: * JEP-Core validation status; * Receipt Profile checks; * Receipt Profile overall status. JEP-RP-1 MUST NOT replace or overwrite the underlying JEP validation result. 10.2. Baseline Validation Mode A JEP-RP-1 Verifier MUST support JEP archival validation mode. If no JEP validation mode is explicitly requested, receipt validation MUST use archival mode. Archival receipt validation MUST NOT consume JEP acceptance state. A deployment MAY additionally request acceptance, chain, or policy mode when those semantics are required. Those modes remain JEP modes and MUST NOT be redefined by this profile. 10.3. Receipt Profile Checks The initial JEP-RP-1 check identifiers are: * https://humanjudgment.org/jep/profiles/receipt/1#profile-binding * https://humanjudgment.org/jep/profiles/receipt/1#receipt-extension * https://humanjudgment.org/jep/profiles/receipt/1#record-binding * https://humanjudgment.org/jep/profiles/receipt/1#record-structure * https://humanjudgment.org/jep/profiles/receipt/1#manifest- structure * https://humanjudgment.org/jep/profiles/receipt/1#bundle-integrity Wang Expires 30 March 2027 [Page 16] Internet-Draft JEP Receipt Profile September 2026 * https://humanjudgment.org/jep/profiles/receipt/1#privacy- reference-format Check statuses use the JEP conformance vocabulary: * pass * fail * not_checked * not_applicable * unsupported * indeterminate A verifier MUST NOT report an unperformed Receipt Profile check as pass. 10.4. Receipt Profile Overall Status The Receipt Profile overall status is one of: * valid * invalid * indeterminate For the requested Receipt Profile validation context: * invalid means the underlying required JEP validation is invalid or at least one required Receipt Profile check failed; * indeterminate means no required check failed, but the underlying required JEP validation is indeterminate or at least one required Receipt Profile check is unsupported, not checked, or indeterminate; * valid means the underlying required JEP validation is valid and every required Receipt Profile check passed or was not applicable. 10.5. Validation Procedure A verifier SHOULD: Wang Expires 30 March 2027 [Page 17] Internet-Draft JEP Receipt Profile September 2026 * validate the JEP event under the requested JEP mode and selected profiles; * verify that the receipt extension is present and listed in ext_crit; * verify that the extension profile equals the JEP-RP-1 profile identifier; * obtain the primary receipt record; * canonicalize and hash the record according to the applicable Receipt Profile record rules; * compare the recomputed digest with record_digest; * validate the record structure for the declared record_type; * if a manifest is the bound primary record, enforce the binding- event circularity rule in Section 8.4; * if a manifest or bundle is evaluated, verify Event Identity and optional Event Hash bindings independently; * verify all required external evidence digests that are available in the requested validation context; * return the JEP result, Receipt Profile check results, and Receipt Profile overall status separately. A successful Receipt Profile result proves the checked cryptographic and structural bindings. It does not prove the external truth or completeness of the recorded behavior. 10.6. Receipt Validation Result Example Wang Expires 30 March 2027 [Page 18] Internet-Draft JEP Receipt Profile September 2026 { "receipt_status": "valid", "profile": "https://humanjudgment.org/jep/profiles/receipt/1", "jep": { "status": "valid", "mode": "archival", "event_identity": { "who": "did:example:receipt-service", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" }, "event_hash": "sha256:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" }, "checks": { "https://humanjudgment.org/jep/profiles/receipt/1#profile-binding": "pass", "https://humanjudgment.org/jep/profiles/receipt/1#receipt-extension": "pass", "https://humanjudgment.org/jep/profiles/receipt/1#record-binding": "pass", "https://humanjudgment.org/jep/profiles/receipt/1#record-structure": "pass", "https://humanjudgment.org/jep/profiles/receipt/1#manifest-structure": "not_applicable", "https://humanjudgment.org/jep/profiles/receipt/1#bundle-integrity": "not_applicable", "https://humanjudgment.org/jep/profiles/receipt/1#privacy-reference-format": "not_applicable" }, "record": { "record_type": "behavior", "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" }, "warnings": [], "errors": [] } The example is illustrative and is not a test vector. 11. Verification Events A JEP V event MAY record a Receipt Profile evaluation. The V event MUST satisfy JEP-Core V requirements. JEP-RP-1 defines the following provisional profile-specific verification scopes: * https://humanjudgment.org/jep/profiles/receipt/1#receipt- validation * https://humanjudgment.org/jep/profiles/receipt/1#record-binding * https://humanjudgment.org/jep/profiles/receipt/1#bundle-integrity A V event MUST identify its target through JEP ref. Wang Expires 30 March 2027 [Page 19] Internet-Draft JEP Receipt Profile September 2026 A V event's what.result reports the semantic result of its declared verification scope. It MUST NOT be confused with the independent per-check status vocabulary used by a Receipt Profile verifier. A V event MUST NOT imply evaluation beyond its declared scope. 12. Conformance 12.1. JEP-RP-1 Producer A conforming JEP-RP-1 Producer MUST: * produce a JEP event conforming to the applicable JEP Producer requirements; * preserve the selected JEP verb semantics; * include the receipt-binding extension; * list the extension in ext_crit; * use the JEP-RP-1 profile identifier; * bind exactly one primary receipt record by digest; * produce the bound record according to the applicable Receipt Profile record format; * avoid rewriting Event Identity or Event Hash semantics. 12.2. JEP-RP-1 Verifier A conforming JEP-RP-1 Verifier MUST: * perform or consume an actual JEP validation result; * support JEP archival validation mode; * process the critical receipt extension; * support JEP-RP-1 behavior-record and manifest digest calculation; * support the required Receipt Profile checks for its claimed validation context; * preserve independent check statuses; * distinguish Event Identity from Event Hash; Wang Expires 30 March 2027 [Page 20] Internet-Draft JEP Receipt Profile September 2026 * distinguish JEP validity from Receipt Profile validity; * enforce the binding-event circularity rule for bound manifests; * return indeterminate rather than success when a required check cannot be completed. 12.3. Receipt Bundle Verifier An implementation claiming Receipt Bundle Verifier capability MUST additionally: * validate manifest structure when a manifest is present; * verify Event Identity descriptors; * verify every required Event Hash pin; * verify every required record digest for available records; * report missing required bundle components as failure or indeterminate according to the requested validation context; * avoid inferring causal-chain completeness from bundle membership. 13. Security Considerations A valid JEP-RP-1 receipt does not prove that the described behavior actually occurred as represented. It proves only the properties that were actually validated. Implementations MUST consider: * actor/signer confusion; * observed-agent/actor confusion; * Event Identity/Event Hash confusion; * substitution of an unbound receipt record; * circular binding between a manifest digest and the binding event's Event Hash; * URI substitution when a verifier trusts location instead of digest; * omitted or selectively exported evidence; Wang Expires 30 March 2027 [Page 21] Internet-Draft JEP Receipt Profile September 2026 * misleading redaction; * fabricated but correctly hashed behavior content; * unsupported critical extensions; * profile confusion; * false chain or completeness inference. A verifier MUST compare the recomputed primary-record digest with the digest inside the signed critical receipt extension. A verifier MUST enforce Section 8.4 when a Receipt Event binds a receipt manifest. A verifier MUST NOT claim actor binding unless the applicable trust- profile check passed. A verifier MUST NOT infer authorization, causality, truth, completeness, liability, or policy compliance from successful Receipt Profile structural validation. 14. Privacy Considerations Receipt records can expose: * actor identifiers; * observed-agent identifiers; * behavior timing; * action categories; * tool or evidence relationships; * human participant roles; * organizational or workflow structure; * storage and retrieval locations. Implementations SHOULD minimize plaintext personal data. Human participant references SHOULD use opaque, pseudonymous, rotating, digest-only, or withheld representations when direct identity is unnecessary. Wang Expires 30 March 2027 [Page 22] Internet-Draft JEP Receipt Profile September 2026 Digest-based references can still enable correlation or dictionary attacks, especially when the underlying value has low entropy. A receipt bundle SHOULD disclose only the evidence required for its intended validation purpose. Receipt Profile privacy mechanisms do not themselves establish consent, lawful basis, data-subject rights compliance, confidentiality obligations, or entitlement to disclosure. 15. Non-Inference Boundary JEP-RP-1 is a technical receipt profile. A successful Receipt Profile validation MUST NOT be presented, by itself, as proof: * that an external factual claim is true; * that an AI output is correct or safe; * that the behavior record is complete; * that the observed agent caused a downstream outcome; * that a delegation or tool call was authorized; * that a human participant consented; * that a process was fair; * that a policy was adequate; * that an explanation was sufficient; * that a legal duty was satisfied; * that any person or organization is liable or not liable; * that a regulatory requirement was met. External profiles and policies MAY use receipt evidence when making such determinations, but those conclusions remain external to JEP-RP- 1. Wang Expires 30 March 2027 [Page 23] Internet-Draft JEP Receipt Profile September 2026 16. IANA Considerations This document requests no IANA actions. The JEP-RP-1 profile identifier, receipt-extension identifier, Receipt Profile check identifiers, and Receipt Profile verification- scope identifiers defined by this document are publisher-controlled HTTPS URI identifiers. Future specifications MAY define registries if stable interoperable deployment requires them. 17. Examples 17.1. Behavior Record { "jep_receipt_record": "1", "record_type": "behavior", "agent": { "id": "did:example:agent-789", "role": "planner", "deployment_id": "runtime-42" }, "action": { "type": "tool_call", "name": "calendar.create_event" }, "created_at": 1790424000, "evidence": [ { "kind": "tool_request", "digest": "sha256:1111111111111111111111111111111111111111111111111111111111111111", "media_type": "application/json", "redaction": "digest-only" }, { "kind": "tool_response", "digest": "sha256:2222222222222222222222222222222222222222222222222222222222222222", "media_type": "application/json", "redaction": "partial" } ] } 17.2. J Event Carrying a Receipt Binding Wang Expires 30 March 2027 [Page 24] Internet-Draft JEP Receipt Profile September 2026 { "jep": "1", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0", "verb": "J", "who": "did:example:receipt-service", "when": 1790424000, "what": { "claim": "agent-behavior-recorded" }, "ext": { "https://humanjudgment.org/jep/extensions/receipt-binding/1": { "profile": "https://humanjudgment.org/jep/profiles/receipt/1", "record_type": "behavior", "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "media_type": "application/json" } }, "ext_crit": [ "https://humanjudgment.org/jep/extensions/receipt-binding/1" ], "sig": "..." } The J what object remains a JEP-Core judgment claim. The receipt- record binding is carried only in the critical receipt extension. 17.3. Receipt Manifest Wang Expires 30 March 2027 [Page 25] Internet-Draft JEP Receipt Profile September 2026 { "jep_receipt_manifest": "1", "profile": "https://humanjudgment.org/jep/profiles/receipt/1", "root_event": { "event_identity": { "who": "did:example:receipt-service", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" } }, "events": [ { "event_identity": { "who": "did:example:receipt-service", "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0" } } ], "records": [ { "record_type": "behavior", "digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", "media_type": "application/json" } ], "created_at": 1790424010 } This example is suitable for a manifest that is itself bound by the root Receipt Event; therefore the binding event is identified by Event Identity without its Event Hash, avoiding a circular dependency. 18. Transition from HJS-05 This Internet-Draft is intended to replace draft-wang-hjs- accountability. The following summarizes the technical transition from draft-wang-hjs-accountability-05: * renamed the technical protocol component from HJS to *JEP Receipt Profile* and started a new Internet-Draft filename for the renamed component; * aligned the profile with JEP-Core 0.7, JEP Profiles-01, and JEP Conformance-01; * introduced JEP-RP-1 as the initial profile version under the new JEP Receipt Profile namespace; Wang Expires 30 March 2027 [Page 26] Internet-Draft JEP Receipt Profile September 2026 * moved primary receipt-record binding from generic use of JEP what to a critical JEP extension so D, T, and V retain their required Core what semantics; * made the receipt-binding extension mandatory and critical for JEP- RP-1; * defined publisher-controlled HTTPS identifiers for the profile and extension; * separated JEP actor, signer, and observed AI agent; * changed logical event references from Event Hash to Event Identity; * retained Event Hash only for exact signed-artifact pinning; * changed receipt-manifest root_event and event descriptors to carry Event Identity plus optional Event Hash; * prohibited a manifest from embedding the Event Hash of the JEP event that binds that manifest, eliminating a circular hash dependency; * removed validation-report as a baseline primary record type; validation reports may remain bundle artifacts; * made JEP archival mode the required and default repeatable receipt validation mode when no other mode is explicitly requested; * removed assumptions that a bundle is a causal or responsibility chain; * replaced cumulative or implicit validation assumptions with independent Receipt Profile checks and valid / invalid / indeterminate status; * made receipt validation preserve the underlying JEP validation result rather than replacing it; * defined exact baseline JSON shapes for behavior records, evidence descriptors, manifests, event descriptors, and record descriptors; * defined JCS plus SHA-256 baseline digest rules for JEP-RP-1 records; * removed the under-specified set of HJS-Core-1 optional extension identifiers from the narrow waist; Wang Expires 30 March 2027 [Page 27] Internet-Draft JEP Receipt Profile September 2026 * moved model, tool, policy, risk, explanation, multi-party, identity-rotation, and other specialized semantics to companion or deployment profiles; * tightened privacy and non-inference language; * changed IANA language to request no action. 19. References 19.1. Normative References [JEP] Wang, Y., "Judgment Event Protocol (JEP)", Work in Progress, Internet-Draft, draft-wang-jep-judgment-event- protocol-07, 26 September 2026, . [JEP-CONFORMANCE] Wang, Y., "JEP Conformance and Test Suite", Work in Progress, Internet-Draft, draft-wang-jep-conformance-01, 26 September 2026, . [JEP-PROFILES] Wang, Y., "JEP Profiles and Interoperability", Work in Progress, Internet-Draft, draft-wang-jep-profiles-01, 26 September 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erlandsson, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . Author's Address Yuqiang Wang Email: signal@humanjudgment.org URI: https://github.com/hjs-spec Wang Expires 30 March 2027 [Page 28]