JEP Receipt Profile: Verifiable Behavior and Evidence Receipts
draft-wang-jep-receipt-profile-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | yuqiang wang | ||
| Last updated | 2026-10-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-jep-receipt-profile-01
Network Working Group Y. Wang
Internet-Draft 5 October 2026
Intended status: Experimental
Expires: 8 April 2027
JEP Receipt Profile: Verifiable Behavior and Evidence Receipts
draft-wang-jep-receipt-profile-01
Abstract
This document defines JEP Receipt Profile 1 (JEP-RP-1), a minimal
receipt and evidence profile for the Judgment Event Protocol (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 8 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 8 April 2027 [Page 1]
Internet-Draft JEP Receipt Profile October 2026
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 . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . 7
4.3. Version and Naming Boundary . . . . . . . . . . . . . . . 7
5. Receipt Event Model . . . . . . . . . . . . . . . . . . . . . 8
5.1. Receipt Event . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Use of J, D, T, and V . . . . . . . . . . . . . . . . . . 9
5.3. who . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. ref . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Receipt-Binding Extension . . . . . . . . . . . . . . . . . . 10
6.1. Extension Value . . . . . . . . . . . . . . . . . . . . . 10
6.2. Extension Example . . . . . . . . . . . . . . . . . . . . 11
6.3. One Primary Record . . . . . . . . . . . . . . . . . . . 11
6.4. JSON Input and Digest Rules . . . . . . . . . . . . . . . 11
7. Behavior Records . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Required Shape . . . . . . . . . . . . . . . . . . . . . 13
7.2. Evidence Descriptor . . . . . . . . . . . . . . . . . . . 14
7.3. Human Participant Reference . . . . . . . . . . . . . . . 15
7.4. Context and Redaction . . . . . . . . . . . . . . . . . . 16
7.5. Behavior Record Digest . . . . . . . . . . . . . . . . . 16
8. Receipt Manifests . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Manifest Shape . . . . . . . . . . . . . . . . . . . . . 16
8.2. Event Descriptor . . . . . . . . . . . . . . . . . . . . 17
8.3. Record Descriptor . . . . . . . . . . . . . . . . . . . . 18
8.4. Binding-Event Circularity Rule . . . . . . . . . . . . . 19
8.5. Manifest Digest . . . . . . . . . . . . . . . . . . . . . 19
9. Receipt Bundles and Export . . . . . . . . . . . . . . . . . 19
9.1. Bundle . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Partial and Redacted Export . . . . . . . . . . . . . . . 20
9.3. No Chain Inference . . . . . . . . . . . . . . . . . . . 20
Wang Expires 8 April 2027 [Page 2]
Internet-Draft JEP Receipt Profile October 2026
9.4. External Artifact Digest Input . . . . . . . . . . . . . 21
10. Receipt Validation . . . . . . . . . . . . . . . . . . . . . 21
10.1. Layer Separation . . . . . . . . . . . . . . . . . . . . 21
10.2. Baseline Validation Mode . . . . . . . . . . . . . . . . 22
10.3. Receipt Profile Checks . . . . . . . . . . . . . . . . . 22
10.3.1. Required Checks and Context . . . . . . . . . . . . 23
10.4. Receipt Profile Overall Status . . . . . . . . . . . . . 25
10.5. Validation Procedure . . . . . . . . . . . . . . . . . . 26
10.6. Portable Validation Result . . . . . . . . . . . . . . . 28
10.6.1. Complete Primary-Receipt Result Example . . . . . . 31
11. Verification Events . . . . . . . . . . . . . . . . . . . . . 33
12. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. JEP-RP-1 Producer . . . . . . . . . . . . . . . . . . . 33
12.2. JEP-RP-1 Verifier . . . . . . . . . . . . . . . . . . . 34
12.3. Receipt Bundle Verifier . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
15. Non-Inference Boundary . . . . . . . . . . . . . . . . . . . 37
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
17.1. Behavior Record . . . . . . . . . . . . . . . . . . . . 38
17.2. J Event Carrying a Receipt Binding . . . . . . . . . . . 39
17.3. Receipt Manifest . . . . . . . . . . . . . . . . . . . . 40
18. Transition from HJS-05 . . . . . . . . . . . . . . . . . . . 41
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
19.1. Normative References . . . . . . . . . . . . . . . . . . 43
19.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Changes from Revision -00 . . . . . . . . . . . . . 44
Appendix B. Canonicalization and Rejection Test Vectors . . . . 47
B.1. minimal-behavior . . . . . . . . . . . . . . . . . . . . 47
B.2. minimal-manifest . . . . . . . . . . . . . . . . . . . . 48
B.3. unicode-null-array-number-boundaries . . . . . . . . . . 49
B.4. Rejection and Status Cases . . . . . . . . . . . . . . . 51
Appendix C. Signed Receipt and Validation Cases . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58
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:
Wang Expires 8 April 2027 [Page 3]
Internet-Draft JEP Receipt Profile October 2026
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.
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], 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, as shown here.
Some examples use the single-backslash line-folding convention in
[RFC8792]. A displayed folding header and continuation backslashes
are presentation only and MUST be removed by unfolding before parsing
an example as JSON.
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;
Wang Expires 8 April 2027 [Page 4]
Internet-Draft JEP Receipt Profile October 2026
* 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;
* 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;
Wang Expires 8 April 2027 [Page 5]
Internet-Draft JEP Receipt Profile October 2026
* ref;
* ext and ext_crit;
* independent Core validation checks;
* validation modes;
* acceptance outcomes and idempotent acceptance.
JEP-RP-1 MUST NOT redefine those semantics.
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/draft-01
The human-readable label JEP-RP-1 identifies the record-format
family. The URI above identifies the specific experimental semantic
contract first defined in this revision. The suffix draft-01 is a
literal part of that identifier, not a negotiation parameter or an
instruction to fetch the latest draft.
Wang Expires 8 April 2027 [Page 6]
Internet-Draft JEP Receipt Profile October 2026
The profile identifier is a publisher-controlled HTTPS URI.
Implementations MUST compare it as an exact string. Dereferencing it
is not required for validation and MUST NOT select different rules.
Documentation at the URI SHOULD remain available; redirects or
document updates MUST NOT change the identified semantic contract.
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.
Unknown critical-extension handling remains a JEP-Core requirement:
an unknown critical receipt extension causes extension_processing to
fail. It MUST NOT be downgraded to a successful Core result or
merely ignored.
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.
The Receipt Profile identifier is distinct from the optional HJS
Archive and Privacy Profile family identifier jep-profile:hjs-
archive:1 in [JEP-PROFILES]. Neither identifier is an alias for, or
implicitly selects, the other.
Wang Expires 8 April 2027 [Page 7]
Internet-Draft JEP Receipt Profile October 2026
Revision -00 used https://humanjudgment.org/jep/profiles/receipt/1.
This revision uses the distinct identifier in Section 4.1 because it
adds constraints and resolves previously unspecified behavior. The
two identifiers MUST NOT be treated as aliases. The receipt-binding
extension identifier remains unchanged; its signed profile member
selects the contract. The record-format markers "1" do not
independently select a profile.
A verifier MUST explicitly select the supported Receipt Profile
contract in its validation context and compare it with the signed
extension value. The selected identifier determines these rules
without a separate agreement on an Internet-Draft revision. An
absent selection leaves profile-binding indeterminate; an explicit
selection that conflicts with the signed value makes it fail.
Independently established failures retain precedence. A verifier
MUST NOT try older profiles after failure, infer a version from the
first passing rule set, or fetch an identifier and execute newly
supplied rules.
A handler that recognizes the receipt extension but cannot process
its selected profile contract MUST NOT mark critical-extension
processing successful. An unsupported profile contract leaves that
processing unresolved under JEP-Core; an unknown critical extension
itself still fails as required by JEP-Core. When validation
explicitly requests this profile, a different signed profile value
fails profile-binding. These cases MUST remain distinguishable in
the report.
Once published, this identifier MUST retain the semantic contract
defined here. An editorial revision that preserves that contract MAY
keep the identifier. A materially incompatible contract MUST use a
new profile identifier, including during experimentation. A later
stable specification MUST NOT silently redirect, alias, or
reinterpret older identifiers. This follows the versioning model in
[JEP-PROFILES].
Historical artifacts and reports MUST retain their original bytes,
identifiers, and declared rules. Implementations MAY separately
support -00. Migrating to this profile requires a new binding event
carrying its identifier and a conforming primary record; the old
event is not edited or relabeled. A behavior record already meeting
these rules may retain its content and digest. A manifest contains
the profile identifier, so migration changes its content and digest.
An evaluation of old record content against new rules is not proof
that the old signed event claimed the new profile. See Table 3.
5. Receipt Event Model
Wang Expires 8 April 2027 [Page 8]
Internet-Draft JEP Receipt Profile October 2026
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;
* 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.
Wang Expires 8 April 2027 [Page 9]
Internet-Draft JEP Receipt Profile October 2026
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/
draft-01.
record_type MUST be one of:
* behavior
* receipt-manifest
record_digest MUST be the sha256: digest string defined in
Section 6.4 for the entire primary record. Other algorithms require
a separately selected specification and are not baseline JEP-RP-1
conformance.
media_type MUST equal the string application/json for either baseline
primary record type. The declared record_type MUST agree with the
supplied record format; a verifier MUST NOT infer a different type to
make a record pass.
Wang Expires 8 April 2027 [Page 10]
Internet-Draft JEP Receipt Profile October 2026
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.
record_uri, when present, MUST be a non-empty string containing a URI
as defined in [RFC3986]. Retrieval is optional and subject to local
access policy; the URI is not an integrity substitute.
6.2. Extension Example
NOTE: '\' line wrapping per RFC 8792
{
"ext": {
"https://humanjudgment.org/jep/extensions/receipt-binding/1": {
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/\
draft-01",
"record_type": "behavior",
"record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"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.
6.4. JSON Input and Digest Rules
The rules in this section apply to complete behavior-record and
receipt-manifest JSON values, including all nested values and any
additional members. The JEP event itself remains subject to the JEP-
Core input and signing rules.
Wang Expires 8 April 2027 [Page 11]
Internet-Draft JEP Receipt Profile October 2026
Serialized record input MUST be UTF-8 JSON conforming to [RFC8259],
the I-JSON restrictions in [RFC7493], and the input requirements of
[RFC8785]. The top-level value MUST be an object. An implementation
MUST reject an input that cannot be processed in this domain; it MUST
NOT repair an invalid input and then report the original input as
valid.
Duplicate object member names MUST be rejected at every nesting level
during parsing, before constructing a map that could discard
duplicates. Name comparison takes place after JSON escape decoding:
"a" and "\u0061" are the same name. A parsed-object API MUST require
an equivalent guarantee from its input parser; a map alone cannot
establish that the original input had no duplicates.
Invalid UTF-8, invalid Unicode data such as an unpaired surrogate,
Unicode noncharacters prohibited by I-JSON, invalid JSON number
syntax, and non-finite numbers MUST be rejected. Numeric values MUST
be handled using the IEEE 754 binary64 model required by JCS. Inputs
that overflow that finite domain MUST be rejected. Implementations
MUST NOT substitute an arbitrary-precision JSON serializer for the
JCS number serialization rules.
The digest input is the complete top-level record JSON value, not a
named subobject and not a serialization containing only recognized
members. Every accepted member and value contributes to the digest.
Structural validation MUST NOT mutate this value. Implementations
MUST NOT remove members, insert defaults, omit explicit null values,
change array order, normalize Unicode, coerce strings to numbers, or
otherwise transform the value before hashing, except for processing
prescribed by RFC 8785.
This rule does not preserve JSON whitespace, escape spelling, object
member order, or number spelling. JCS specifies their serialization,
including UTF-16 code-unit ordering of object names, the
serialization of negative zero as 0, and the binary64 handling and
serialization of numbers. It preserves array order and performs no
Unicode normalization. A need to preserve precision beyond binary64
must be addressed when constructing the record, for example with an
application-defined string representation; a verifier MUST NOT
silently convert a numeric member to a string.
Wang Expires 8 April 2027 [Page 12]
Internet-Draft JEP Receipt Profile October 2026
An optional member that is absent is different from a present member
with the value null. If the declared type of a member excludes null,
its presence with that value is a structure error, not a request to
remove the member. Additional members are permitted unless an
explicitly selected companion profile restricts them. A baseline
verifier MUST retain them for canonicalization, MUST NOT assign them
unstated baseline semantics, and MUST NOT claim that companion
semantics were checked when they were not.
The baseline calculation is:
canonical_bytes = UTF8(RFC8785(record))
digest_bytes = SHA-256(canonical_bytes)
digest_text = "sha256:" + lowercase_hex(digest_bytes)
canonical_bytes is exactly the UTF-8 output of JCS, with no byte
order mark, trailing newline, length prefix, or additional envelope.
An API that already returns the JCS UTF-8 octets MUST NOT UTF-8
encode those octets a second time. The textual representation MUST
contain exactly the sha256: prefix followed by 64 lowercase
hexadecimal digits. A verifier MUST compare the recomputed digest,
not the source JSON text or a retrieval URI.
These rules specify an algorithm, not an implementation dependency.
A conforming implementation can use any implementation that produces
the required bytes and rejects invalid inputs.
7. Behavior Records
7.1. Required Shape
A JEP-RP-1 behavior record MUST be a JSON object containing:
* jep_receipt_record
* record_type
* agent
* action
* created_at
* evidence
jep_receipt_record MUST equal "1".
record_type MUST equal "behavior".
Wang Expires 8 April 2027 [Page 13]
Internet-Draft JEP Receipt Profile October 2026
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.
An Evidence Descriptor MAY additionally contain:
* media_type
* uri
* redaction
media_type, when present, MUST be a non-empty string.
Wang Expires 8 April 2027 [Page 14]
Internet-Draft JEP Receipt Profile October 2026
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.
Each descriptor is an object. Its digest identifies the exact
evidence artifact octets under Section 9.4. For the baseline it MUST
use sha256: followed by 64 lowercase hexadecimal digits. uri MUST be
a non-empty URI string if present. redaction MUST be a non-empty
string if present. Additional redaction labels require an explicitly
selected companion profile for their interpretation; a label alone
does not verify a redaction operation.
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 8 April 2027 [Page 15]
Internet-Draft JEP Receipt Profile October 2026
Each reference MUST be an object. reference, when required, MUST be a
non-empty string. privacy_mode and salt_holder, when present, MUST be
non-empty strings. Their presence describes a reference method or
salt custodian; it is not evidence that an identity, privacy claim,
or salt-management procedure has been verified.
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
The Behavior Record Digest MUST be calculated using the complete
behavior-record value and the exact input, canonicalization, SHA-256,
and textual-encoding rules in Section 6.4. In particular, evidence,
human_participants, context, redaction, and accepted additional
fields are included when present.
The receipt-binding extension is part of the JEP event, not a wrapper
to add to the behavior record. The behavior-record digest MUST NOT
be calculated by applying the JEP signing-payload rule that omits
sig; there is no such field exclusion for receipt records.
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
Wang Expires 8 April 2027 [Page 16]
Internet-Draft JEP Receipt Profile October 2026
* records
* created_at
jep_receipt_manifest MUST equal "1".
profile MUST equal https://humanjudgment.org/jep/profiles/receipt/1/
draft-01.
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
external_refs, when present, MUST be an array of Evidence Descriptors
as defined in Section 7.2. redaction, when present, MUST be an object
with the limitations in Section 7.4. Additional members follow
Section 6.4.
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"
}
}
The Event Descriptor and its event_identity member MUST each be
objects. The who and id values MUST satisfy the corresponding JEP-
Core field rules, including a non-empty ASCII id. Comparison uses
the exact JEP Event Identity values; a verifier MUST NOT normalize,
case-fold, or substitute an Event Hash for them.
An Event Descriptor MAY additionally contain:
Wang Expires 8 April 2027 [Page 17]
Internet-Draft JEP Receipt Profile October 2026
* 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.
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.
event_hash, when present, MUST be a JEP algorithm-tagged Event Hash.
Baseline implementations MUST support JEP-Core sha256. uri, when
present, MUST be a non-empty URI string. If both the root descriptor
and its matching entry in events include an Event Hash, their values
MUST agree. A supplied event MUST match its descriptor's Event
Identity as well as any Event Hash pin.
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.
A Record Descriptor MUST be an object. media_type, when present, MUST
be a non-empty string, and uri, when present, MUST be a non-empty URI
string. For behavior and receipt-manifest, digest MUST be the
baseline JCS/SHA-256 digest of that record type, and a present
Wang Expires 8 April 2027 [Page 18]
Internet-Draft JEP Receipt Profile October 2026
media_type MUST equal application/json. Other record_type values
identify opaque artifacts whose baseline digest is defined in
Section 9.4; additional structure semantics require a selected
companion profile.
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
The Manifest Digest MUST be calculated over the complete receipt-
manifest value according to Section 6.4. The root_event, events,
records, created_at, and all present optional or additional members
are included without field exclusions.
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. The circularity constraint in Section 8.4 is checked
without deleting any member from the digest input.
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;
Wang Expires 8 April 2027 [Page 19]
Internet-Draft JEP Receipt Profile October 2026
* external evidence objects.
JEP-RP-1 does not define a validation-report primary record type.
Reports MAY appear as bundle artifacts. The portable result object
in Section 10.6 describes a verifier observation; it does not make a
report a receipt, a signature, or a new primary-record format.
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.
A digest of an original artifact does not verify a different redacted
artifact. If only a redacted artifact is supplied, its bytes can be
verified only against a digest that commits to those bytes, unless an
explicitly selected specification defines and verifies a separate
disclosure proof. If the original is required but unavailable, its
integrity check is indeterminate; a redaction label cannot make it
pass.
A producer exporting a modified behavior record or manifest MUST
calculate its new digest and, if claiming a receipt binding for that
modified record, obtain a new binding event. It MUST NOT reuse the
original binding as if the modified value were the original. The
original artifact and its historical binding remain unchanged.
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.
Chain reconstruction, cycle analysis, termination cascade, complete-
log assumptions, and causal interpretation belong to a selected chain
profile or external system.
Wang Expires 8 April 2027 [Page 20]
Internet-Draft JEP Receipt Profile October 2026
9.4. External Artifact Digest Input
The digest in an Evidence Descriptor commits to the exact octet
sequence of one identified evidence artifact. The digest in a Record
Descriptor with a record_type other than the reserved values behavior
and receipt-manifest has the same octet-sequence meaning. The
baseline is SHA-256 over those octets with the textual representation
specified in Section 6.4.
These opaque-artifact digests MUST NOT apply JCS, whitespace removal,
newline conversion, Unicode normalization, decompression, redaction,
or a format conversion as an implicit preprocessing step. A JSON
media type does not select JCS. If a producer wants to commit to a
transformed representation, that representation is a distinct
artifact whose exact bytes are the digest input.
The packaging or retrieval mechanism MUST identify the artifact
octets supplied to the verifier, separately from transport framing or
an archive container. If transfer or content coding is used, the
mechanism MUST specify how the identified artifact octets are
recovered. In the absence of that agreement a verifier MUST report
the affected required integrity check as indeterminate, rather than
trying transformations until a digest matches.
A descriptor for a JEP-RP-1 behavior record or manifest in the
manifest's records array uses its reserved record_type and the JCS
record-digest rule. An Evidence Descriptor always uses the opaque-
artifact rule, even if its artifact happens to contain a JSON receipt
record. A verifier MUST select the rule from the descriptor's
defined context, not from filename, URI, or media type.
The JEP-RP-1 baseline digest fields in this document use sha256. A
different algorithm label in one of those fields violates the
selected baseline and MUST fail the applicable descriptor or
extension structure check; it is not merely an unsupported
implementation feature. A companion specification can define
separately identified fields or a different profile contract for
additional algorithms, but MUST NOT change the meaning of a baseline
field under the same selected rules.
10. Receipt Validation
10.1. Layer Separation
Receipt validation reports separately:
* JEP-Core validation status;
Wang Expires 8 April 2027 [Page 21]
Internet-Draft JEP Receipt Profile October 2026
* Receipt Profile checks;
* Receipt Profile overall status.
JEP-RP-1 MUST NOT replace or overwrite the underlying JEP validation
result.
Receipt binding is processed by the handler for the critical receipt
extension during JEP validation. Implementations MAY perform local
parsing, structure, and cryptographic checks separately, but MUST NOT
finalize an overall JEP success while mandatory critical-extension
processing remains unresolved. They MUST preserve the independent
Core check results.
For a recognized receipt extension, the required primary-record
binding and structure checks are part of processing that extension.
Failure of those checks makes the extension fail; inability to obtain
required input leaves that processing indeterminate. This does not
change the Core rule that an unknown critical extension fails.
Supplemental bundle checks do not redefine the Core extension result
when the primary binding itself has been completely checked.
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.
A requested but unsupported mode MUST NOT be silently replaced with
archival. The default applies only when the request omits a mode.
The verifier MUST report the effective mode, including a mode
selected by default.
10.3. Receipt Profile Checks
The initial JEP-RP-1 check identifiers are:
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#profile-
binding
Wang Expires 8 April 2027 [Page 22]
Internet-Draft JEP Receipt Profile October 2026
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#receipt-
extension
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#record-
binding
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#record-
structure
* https://humanjudgment.org/jep/profiles/receipt/1/draft-
01#manifest-structure
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#bundle-
integrity
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#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.3.1. Required Checks and Context
A validation request MUST identify its target event and explicitly
selected profiles, using the semantic identifier in Section 4.1. It
MAY omit the JEP validation mode, in which case the verifier MUST use
archival. It MAY omit an inventory request, in which case the scope
is the target event and its primary record. Before evaluation, the
verifier MUST resolve the effective mode, scope, and required checks
and report them under Section 10.6. The signed identifier selects
the Receipt rules; the report also names the specification used.
Context defaults do not insert or change a member of a signed event
or digest-bound record.
Wang Expires 8 April 2027 [Page 23]
Internet-Draft JEP Receipt Profile October 2026
The following minimum set is mandatory for primary receipt
validation. The table uses the check-identifier suffixes listed
above.
+==========================+======================================+
| Check | Applicability and condition for pass |
+==========================+======================================+
| profile-binding | The requested profile and extension |
| | profile are JEP-RP-1. |
+--------------------------+--------------------------------------+
| receipt-extension | The extension is present, critical, |
| | and well formed under Section 6. |
+--------------------------+--------------------------------------+
| record-binding | The complete supplied primary value |
| | has the digest in the signed |
| | extension. |
+--------------------------+--------------------------------------+
| record-structure | A behavior primary record satisfies |
| | Section 7, including its descriptors |
| | and the circularity constraint. |
+--------------------------+--------------------------------------+
| manifest-structure | A manifest primary record satisfies |
| | Section 8, including identity |
| | consistency and the circularity |
| | constraint. |
+--------------------------+--------------------------------------+
| privacy-reference-format | Present human participant references |
| | satisfy Section 7.3; this does not |
| | verify identities or privacy |
| | outcomes. |
+--------------------------+--------------------------------------+
Table 1: Minimum Primary-Receipt Checks
For a behavior primary record, manifest-structure is not_applicable.
For a manifest primary record, record-structure is not_applicable.
privacy-reference-format is not_applicable only if the assessed
records have no human participant references to check. An absent or
unreadable primary record does not make its applicable structure
check not_applicable.
bundle-integrity is required if inventory verification is requested.
If no inventory is in scope it is not_applicable. Primary-only
success authenticates the embedded descriptors as record content; it
does not verify the artifacts those descriptors describe. Such a
result MUST state that external artifact integrity was outside its
scope.
Wang Expires 8 April 2027 [Page 24]
Internet-Draft JEP Receipt Profile October 2026
For inventory verification the request MUST identify a finite set of
required descriptors. If a manifest is supplied and no narrower set
is explicitly selected, this set is its root_event descriptor and all
entries in its events, records, and external_refs, plus the Evidence
Descriptors of the behavior records in that set. Nested receipt
manifests are verified as records; their inventories are not
recursively traversed unless the request explicitly includes them.
Reports MUST disclose any narrower selection and omitted components.
Each required event artifact MUST match its Event Identity and every
applicable Event Hash pin, including a pin in root_event, and undergo
JEP validation in the declared context. An event appearing in more
than one descriptor can be checked once if all descriptor constraints
are evaluated. Its critical receipt extension requires its own
primary record; this does not implicitly request recursive inventory
verification. Each required record or evidence artifact MUST be
obtained and its digest checked. Required behavior records and
manifests MUST also pass their structure checks; companion semantics
are checked only when explicitly selected. For bundle-integrity, a
failed required component produces fail; otherwise any required
component that is unsupported, not_checked, or indeterminate produces
indeterminate; otherwise every required component must pass or be
legitimately not applicable. Component statuses MUST be retained. A
verifier MUST NOT report complete inventory verification after
silently discarding a required descriptor.
A request without a manifest MUST enumerate its required descriptors
or provide an explicitly selected packaging-profile rule that does
so. An undefined inventory scope is indeterminate. A malformed
manifest is fail; it is not an empty inventory. Extra, unreferenced
bundle files do not become authenticated by being packaged next to a
receipt.
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;
Wang Expires 8 April 2027 [Page 25]
Internet-Draft JEP Receipt Profile October 2026
* 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.
Failure takes precedence over an unresolved check. A required check
can be not_applicable only under a stated applicability rule; a
verifier MUST NOT use that status to bypass missing evidence.
Missing required input produces indeterminate when no required check
has failed. An explicit companion policy MAY reject unavailable
evidence, but the policy outcome MUST be identified separately and
MUST NOT be described as an observed digest mismatch.
10.5. Validation Procedure
A verifier MUST perform the applicable operations below before
reporting success. It SHOULD follow the ordering shown, integrated
with JEP-Core critical-extension processing:
1. Fix the validation context, selected profiles, target event, and
required inventory, if any.
2. Parse and validate the JEP event and its signature under JEP-Core
and the selected signature profile. Preserve each Core check
result. Do not finalize critical-extension processing or
acceptance while receipt checks required by the extension are
pending.
3. Check the profile identifier, presence and criticality of the
receipt extension, and all required extension member types and
values.
4. Obtain the primary receipt record from supplied data or an
allowed retrieval mechanism. Missing data is not a successful
binding.
5. Parse that complete record using Section 6.4, without discarding
duplicates or changing its value. Validate the structure for the
declared record type. Calculate and compare its JCS/SHA-256
digest without excluding members.
6. Enforce the relevant circularity rule, and check any human
participant reference formats. Record structural and
cryptographic outcomes separately when both can be determined.
Wang Expires 8 April 2027 [Page 26]
Internet-Draft JEP Receipt Profile October 2026
7. If inventory verification is requested, perform all required
component checks described in Section 10.3.1 and report which
components were missing, failed, or omitted from scope.
8. Complete the critical-extension handler, retain the resulting
JEP-Core status, and calculate Receipt Profile status with the
aggregation rules in Section 10.4. In acceptance mode, follow
Core acceptance-state rules only after the checks required by
that context have completed successfully.
9. Return the context, underlying JEP result, Receipt Profile
checks, component results when applicable, and Receipt Profile
overall status. Do not represent a partial result as a completed
result.
A syntax, duplicate-name, or JCS-domain error in a supplied primary
record makes record-binding fail because no valid canonical input
exists. It also fails the applicable structure check. A well-formed
JCS value with an incorrect digest makes record-binding fail even if
structure passes. A digest match with an invalid record shape makes
the applicable structure check fail even though record-binding
passes. Missing primary input leaves both applicable checks
indeterminate unless an independent failure is already established.
A required external artifact that is unavailable is indeterminate. A
supplied artifact that does not match its declared digest is fail.
An unsupported required mechanism is unsupported. An optional,
applicable check that was not performed is not_checked. These
statuses MUST NOT be relabeled pass.
A successful Receipt Profile result establishes the cryptographic and
structural properties actually checked. It does not prove the
external truth or completeness of the recorded behavior, nor
interoperability of untested protocol or application semantics.
fail describes a violation of the selected rules that the verifier
has established. unsupported describes an implementation capability
that is required by those rules but is unavailable. For example, a
sha512: value in a baseline record_digest makes receipt-extension
fail. An allowed, explicitly selected companion check that the
verifier does not implement is unsupported. An implementation unable
to compute mandatory SHA-256 MUST NOT claim conforming verifier
capability or report success; that limitation alone does not prove
the artifact invalid. Unknown critical extensions still fail
according to JEP-Core.
Wang Expires 8 April 2027 [Page 27]
Internet-Draft JEP Receipt Profile October 2026
10.6. Portable Validation Result
A conforming Receipt Profile Verifier MUST be able to produce the
JSON result object defined here. This is a minimum exchange contract
for validation results, not an archive container, network API, new
signature format, or replacement for the JEP Conformance result.
Field names and value semantics below are normative; member order and
JSON whitespace are not.
The object MUST contain profile, specification, receipt_status, jep,
record, checks, context, warnings, and errors. Additional members
MAY be included but MUST NOT redefine these members or widen the
stated scope. Duplicate names MUST be rejected. Unknown additional
members MUST NOT be used to infer successful checks.
+==============+===================================================+
|Member | Meaning |
+==============+===================================================+
|profile | The exact identifier |
| | https://humanjudgment.org/jep/profiles/receipt/1/ |
| | draft-01, identifying the Receipt contract this |
| | report evaluates; it is not a claim that the |
| | input event carries that identifier. |
+--------------+---------------------------------------------------+
|specification | A non-empty string naming the exact specification |
| | revision used, initially draft-wang-jep-receipt- |
| | profile-01. This is audit metadata, not an |
| | override of the signed semantic identifier. |
+--------------+---------------------------------------------------+
|receipt_status| valid, invalid, or indeterminate, aggregated only |
| | as specified in Section 10.4. |
+--------------+---------------------------------------------------+
|jep | The underlying JEP validation-result object |
| | described in [JEP-CONFORMANCE], with its status, |
| | effective mode, selected Core contract, |
| | independent checks, warnings, errors, and |
| | applicable acceptance result preserved. It MUST |
| | include asserted event_identity when available |
| | and event_hash when calculated. Unavailable |
| | identity or hash is null; it is not a fabricated |
| | identifier. For a successful Receipt result the |
| | Event Hash MUST have been calculated. This |
| | member does not reclassify unperformed Core |
| | checks as passing. |
+--------------+---------------------------------------------------+
|record | An object containing record_type and |
| | record_digest, copied from the signed extension |
| | when those values satisfy its field rules; |
Wang Expires 8 April 2027 [Page 28]
Internet-Draft JEP Receipt Profile October 2026
| | otherwise the affected member is null. A |
| | syntactically valid declared digest can be |
| | reported even if its comparison or the event |
| | signature fails. An optional |
| | computed_record_digest reports the actual |
| | calculated digest, including on mismatch. These |
| | fields identify input and computation, not their |
| | validity. |
+--------------+---------------------------------------------------+
|checks | An object mapping every Receipt check identifier |
| | in Section 10.3 to its check-status string. All |
| | seven baseline entries MUST be present, including |
| | unperformed or inapplicable checks. Additional |
| | profile checks use their own identifiers. |
| | Detailed diagnostics supplement, and MUST NOT |
| | contradict, these values. |
+--------------+---------------------------------------------------+
|context | The effective evaluation context defined below, |
| | including the selected profiles, requested mode, |
| | scope, and required Receipt checks. |
+--------------+---------------------------------------------------+
|warnings and | Arrays of diagnostic objects, empty when none. |
|errors | Each entry SHOULD identify the affected check or |
| | component and provide an explanatory message. |
| | Diagnostics MUST NOT contradict the structured |
| | statuses. No new global error-code registry is |
| | defined. |
+--------------+---------------------------------------------------+
Table 2: Required Result Members
The context object MUST contain: profiles, a duplicate-free array of
the explicitly selected profile identifiers; requested_mode, the
requested JEP mode string or null when omitted; scope, either
primary-receipt or inventory; and required_checks, a duplicate-free
array of the full Receipt check identifiers required in that context.
The effective mode is reported in jep.mode. The six minimum primary
checks MUST be included in required_checks; bundle-integrity MUST
additionally be included for inventory scope. Removing a required
check from the array does not change its normative requirement.
Wang Expires 8 April 2027 [Page 29]
Internet-Draft JEP Receipt Profile October 2026
Any explicitly selected companion rules, signature class, trust/key
source, historical-state assumptions, or policy parameters needed to
interpret the result MUST be identified in the report, using
additional context members or the underlying JEP result as
appropriate. Sensitive evidence can be referenced through immutable
identifiers rather than disclosed. If the necessary context cannot
be reproduced, a consumer MUST NOT treat equal overall status strings
as evidence of equivalent validation. This profile does not define
or authenticate trust roots.
For primary-receipt scope, context.external_artifact_integrity MUST
be not_checked and context.inventory MUST be absent. The bundle-
integrity check is not_applicable. This combination explicitly
states that descriptor content, but not the referenced external
artifacts, was assessed.
For inventory scope, context.external_artifact_integrity MUST be
see_inventory and context.inventory MUST be an object with selection,
complete, components, and omitted. selection is manifest-default for
the default finite inventory in Section 10.3.1 or explicit for an
explicitly selected set. complete is a boolean stating whether that
required set was fully determined, not whether its artifacts were all
available or valid. It MUST be false if missing input prevents
enumeration of required descriptors. An incomplete required set
cannot produce a passing inventory result.
Each components entry MUST be an object with kind (event, record, or
evidence), descriptor (the corresponding complete descriptor object),
and status (the check-status vocabulary in Section 10.3). It MUST
preserve the results of the component checks actually performed,
using a checks object and, for an event, its underlying JEP result.
A wholly unavailable artifact can be represented by indeterminate
plus an explanatory diagnostic and an empty checks object. All
required descriptors MUST be represented; identical descriptors MAY
share one entry, but distinct pins or constraints MUST NOT be
discarded.
The omitted array MUST list known descriptors excluded by an
explicitly narrower scope, each as an object with kind, descriptor,
and a non-empty reason string. It is empty when no known descriptors
were excluded. A missing artifact that is required belongs in
components with an unresolved status, not in omitted. Unreferenced
packaged files need not be enumerated and acquire no authenticated
status. Reported component outcomes MUST aggregate to bundle-
integrity using Section 10.3.1; a required failure takes precedence
even when complete is false.
Wang Expires 8 April 2027 [Page 30]
Internet-Draft JEP Receipt Profile October 2026
A consumer MUST check the report target, profile, effective context,
required-check set, and aggregation consistency before relying on its
outcome. An incomplete or internally inconsistent report is not a
successful result under this exchange contract; that defect alone
does not prove the underlying receipt invalid. Reports MUST NOT be
compared solely by receipt_status. This result object is an
unauthenticated verifier observation unless a separately selected
mechanism authenticates it. The Receipt Event signature does not
authenticate a later report, and a report never substitutes for
validation of the underlying evidence.
10.6.1. Complete Primary-Receipt Result Example
This example is the portable result for the signed test receipt in
Appendix C under its stated fixture context. It reports a local
verifier observation; its Event Hash identifies the target event, not
a signature on this report.
NOTE: '\' line wrapping per RFC 8792
{
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
"specification": "draft-wang-jep-receipt-profile-01",
"receipt_status": "valid",
"jep": {
"status": "valid",
"mode": "archival",
"profile": "jep-core-0.7",
"event_identity": {
"who": "urn:example:receipt-signer",
"id": "receipt-test-1"
},
"event_hash": "sha256:d8522307eec9432c1e6b9ee56c2d6c8ed3bcd8f3d\
3584d87092fd85d946ac429",
"checks": {
"syntax": "pass",
"cryptographic": "pass",
"event_identity": "pass",
"reference_integrity": "not_applicable",
"extension_processing": "pass",
"actor_binding": "not_applicable",
"freshness": "not_applicable",
"audience": "not_applicable",
"chain_integrity": "not_checked",
"policy": "not_checked"
},
"warnings": [],
Wang Expires 8 April 2027 [Page 31]
Internet-Draft JEP Receipt Profile October 2026
"errors": []
},
"record": {
"record_type": "behavior",
"record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e72374\
5586aac1caa8004c00e013cd6b",
"computed_record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298\
123e723745586aac1caa8004c00e013cd6b"
},
"checks": {
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#prof\
ile-binding": "pass",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#rece\
ipt-extension": "pass",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#reco\
rd-binding": "pass",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#reco\
rd-structure": "pass",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#mani\
fest-structure": "not_applicable",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#priv\
acy-reference-format": "not_applicable",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#bund\
le-integrity": "not_applicable"
},
"context": {
"profiles": [
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01"
],
"requested_mode": null,
"scope": "primary-receipt",
"required_checks": [
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#pr\
ofile-binding",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
ceipt-extension",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
cord-binding",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
cord-structure",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#ma\
nifest-structure",
"https://humanjudgment.org/jep/profiles/receipt/1/draft-01#pr\
ivacy-reference-format"
],
"signature_class": "JEP-Baseline-Ed25519-JWS-JCS-0.7",
"key_source": "public deterministic fixture key",
"key_fingerprint": "sha256:56475aa75463474c0285df5dbf2bcab73da6\
Wang Expires 8 April 2027 [Page 32]
Internet-Draft JEP Receipt Profile October 2026
51358839e9b77481b2eab107708c",
"identity_scope": "identifier syntax; no historical state",
"external_artifact_integrity": "not_checked"
},
"warnings": [],
"errors": []
}
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/draft-01#receipt-
validation
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#record-
binding
* https://humanjudgment.org/jep/profiles/receipt/1/draft-01#bundle-
integrity
A V event MUST identify its target through JEP ref.
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;
Wang Expires 8 April 2027 [Page 33]
Internet-Draft JEP Receipt Profile October 2026
* 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.
A producer MUST apply the complete-input and rejection rules in
Section 6.4, and MUST identify external artifact octets according to
Section 9.4. No alternative canonicalization algorithm is permitted
for baseline records.
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;
* distinguish JEP validity from Receipt Profile validity;
* enforce the binding-event circularity rule for bound manifests;
* return indeterminate when a required check cannot be completed and
no required check has failed.
A verifier MUST implement the minimum applicable checks and scope
reporting in Section 10.3.1. If a required failure is already
established, the overall result remains invalid even when another
check cannot be completed. Merely supporting a digest library does
not constitute full Receipt Profile verifier conformance.
Wang Expires 8 April 2027 [Page 34]
Internet-Draft JEP Receipt Profile October 2026
A verifier MUST support the portable result contract in Section 10.6.
Inventory verification remains the additional capability in
Section 12.3; primary-receipt conformance does not imply retrieval,
complete inventories, actor authentication, or acceptance processing.
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 and report any required
missing artifact;
* report missing required bundle components as indeterminate, with
any independent companion-policy rejection stated separately;
* 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 8 April 2027 [Page 35]
Internet-Draft JEP Receipt Profile October 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.
Parsers, canonicalizers, and schema validators can disagree about
duplicate names, Unicode, or numeric representations.
Implementations MUST enforce the input rules before a lossy parser or
validation pass can conceal an error. Tests SHOULD cover UTF-16 name
ordering, number serialization boundaries, explicit nulls, array
order, unknown members, and malformed serialized JSON.
Digest matching does not make a retrieval URI safe. Verifiers SHOULD
restrict URI schemes and network destinations, avoid sending ambient
credentials, and bound input size, nesting depth, retrieval count,
and processing time. A resource limit MUST NOT be reported as
successful verification or a digest mismatch; if it prevents a
required check, that check remains unresolved.
14. Privacy Considerations
Receipt records can expose:
* actor identifiers;
* observed-agent identifiers;
* behavior timing;
* action categories;
Wang Expires 8 April 2027 [Page 36]
Internet-Draft JEP Receipt Profile October 2026
* 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.
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;
Wang Expires 8 April 2027 [Page 37]
Internet-Draft JEP Receipt Profile October 2026
* 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.
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
The examples in this section illustrate field placement only.
Repeated-digit digests and the signature placeholder are not
executable test values. The executable record-digest examples are in
Appendix B.
17.1. Behavior Record
Wang Expires 8 April 2027 [Page 38]
Internet-Draft JEP Receipt Profile October 2026
NOTE: '\' line wrapping per RFC 8792
{
"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:1111111111111111111111111111111111111111111\
111111111111111111111",
"media_type": "application/json",
"redaction": "digest-only"
},
{
"kind": "tool_response",
"digest": "sha256:2222222222222222222222222222222222222222222\
222222222222222222222",
"media_type": "application/json",
"redaction": "partial"
}
]
}
17.2. J Event Carrying a Receipt Binding
Wang Expires 8 April 2027 [Page 39]
Internet-Draft JEP Receipt Profile October 2026
NOTE: '\' line wrapping per RFC 8792
{
"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/\
draft-01",
"record_type": "behavior",
"record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
"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 8 April 2027 [Page 40]
Internet-Draft JEP Receipt Profile October 2026
NOTE: '\' line wrapping per RFC 8792
{
"jep_receipt_manifest": "1",
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
"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:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaa",
"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;
Wang Expires 8 April 2027 [Page 41]
Internet-Draft JEP Receipt Profile October 2026
* introduced JEP-RP-1 as the initial profile version under the new
JEP Receipt Profile namespace;
* 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;
Wang Expires 8 April 2027 [Page 42]
Internet-Draft JEP Receipt Profile October 2026
* removed the under-specified set of HJS-Core-1 optional extension
identifiers from the narrow waist;
* 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,
<https://www.ietf.org/archive/id/draft-wang-jep-judgment-
event-protocol-07.html>.
[JEP-CONFORMANCE]
Wang, Y., "JEP Conformance and Test Suite", Work in
Progress, Internet-Draft, draft-wang-jep-conformance-02,
30 September 2026, <https://www.ietf.org/archive/id/draft-
wang-jep-conformance-02.html>.
[JEP-PROFILES]
Wang, Y., "JEP Profiles and Interoperability", Work in
Progress, Internet-Draft, draft-wang-jep-profiles-01, 26
September 2026, <https://www.ietf.org/archive/id/draft-
wang-jep-profiles-01.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, March
2015, <https://www.rfc-editor.org/rfc/rfc7493>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Wang Expires 8 April 2027 [Page 43]
Internet-Draft JEP Receipt Profile October 2026
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
19.2. Informative References
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, June 2020,
<https://www.rfc-editor.org/rfc/rfc8792>.
Appendix A. Changes from Revision -00
This appendix records changes to a work in progress; it does not
assert that implementations of -00 already meet -01.
* Specified the complete top-level digest input, lowercase SHA-256
text, and RFC 8785 processing without field exclusions, defaults,
or implicit transformations.
* Made duplicate-name rejection, Unicode validity, binary64
processing, optional-null handling, and additional-member
treatment explicit.
* Specified the types of participant references and optional
manifest and descriptor members, and required baseline primary
media type and digest values.
* Specified opaque external-artifact digests separately from JCS
record digests, including transport and redaction boundaries.
* Defined the minimum required checks, primary-only scope, inventory
scope, missing-input behavior, and integration with critical-
extension processing. Preserved fail precedence and independent
Core checks.
* Added reproducible canonical-byte, digest, and rejection examples;
updated the JEP Conformance reference to revision -02.
* Assigned a distinct signed semantic profile identifier, preserved
the -00 identifier, and removed reliance on an external draft-
revision agreement for selecting these Receipt rules.
Wang Expires 8 April 2027 [Page 44]
Internet-Draft JEP Receipt Profile October 2026
* Defined the minimum portable validation-result contract using
existing JEP Conformance statuses, with explicit target, required
checks, scope, inventory components, and omissions.
Potential interoperability changes for -00 implementations include
rejecting previously accepted duplicate names or invalid field types;
retaining previously stripped members in digest input; requiring
baseline sha256 and application/json for primary records; and no
longer reporting unavailable required evidence as verified.
Previously unspecified evidence transformations MUST NOT be guessed
or retrospectively assigned to historical receipts. Historical
validation reports retain their original scope and revision.
Wang Expires 8 April 2027 [Page 45]
Internet-Draft JEP Receipt Profile October 2026
+===================+==============================================+
| Change | Classification and handling |
+===================+==============================================+
| Complete-record | Clarifies the already specified record |
| JCS and SHA-256; | algorithm and its input domain. An |
| duplicate and | implementation bug is fixed without |
| Unicode rules | rewriting historical artifacts or claiming |
| | that earlier reports performed new checks. |
+-------------------+----------------------------------------------+
| Types of | New explicit constraints where -00 left |
| participant | types unspecified. Producers targeting -01 |
| reference values | construct new records accordingly. An old |
| and optional | record outside these constraints is not |
| manifest members | silently repaired or relabeled. |
+-------------------+----------------------------------------------+
| Opaque evidence | New explicit conventions where -00 was |
| octets, | incomplete. Historical digests are |
| descriptor digest | interpreted under their original documented |
| algorithm, and | convention, if known. A byte transformation |
| transport | creates a new artifact and digest; a missing |
| recovery | convention is not guessed. |
+-------------------+----------------------------------------------+
| Default mode, | The archival default already existed. The |
| required checks, | required-check and result rules are made |
| missing input, | explicit. New validation can be performed |
| and capability | and separately reported without modifying an |
| reporting | earlier result. |
+-------------------+----------------------------------------------+
| Signed profile | New -01 contract. Preserve old identifiers, |
| identifier and | events, and reports. A producer creates a |
| portable result | new signed binding selecting the new |
| contract | identifier. A verifier reports exactly the |
| | rules and scope evaluated; a new report |
| | cannot retroactively change the old signed |
| | claim. |
+-------------------+----------------------------------------------+
Table 3: Compatibility and Migration from -00
Migration to -01 requires the new signed identifier and applicable
record constraints; changing a report label is insufficient. A
historical behavior record whose content meets these rules can be
bound by a new event without changing that content. A manifest MUST
carry the new profile identifier and therefore receives a new digest.
The historical event and reports remain unchanged. A diagnostic
evaluation of old record content under new rules MUST NOT be reported
as successful profile binding of an event carrying the old
identifier.
Wang Expires 8 April 2027 [Page 46]
Internet-Draft JEP Receipt Profile October 2026
Appendix B. Canonicalization and Rejection Test Vectors
This appendix supplies deterministic tests for the record
canonicalization and digest rules. A signed receipt example is
provided in Appendix C. Neither appendix establishes full-protocol
conformance. The normative requirements in the body of this document
take precedence over examples and derived test files.Appendix C.
Neither appendix establishes full-protocol conformance. The
normative requirements in the body of this document take precedence
over examples and derived test files.
For each positive example, canonical-byte hexadecimal is wrapped for
presentation only. Concatenate the hex lines, decode pairs of
hexadecimal digits to octets, and apply SHA-256 to those octets. Do
not hash the hex characters or the display newlines. The lowercase
digest text consists of sha256: followed immediately by the displayed
hash.
B.1. minimal-behavior
Input JSON:
{
"jep_receipt_record": "1",
"record_type": "behavior",
"agent": {
"id": "agent:example"
},
"action": {
"type": "observe"
},
"created_at": 0,
"evidence": []
}
Canonical UTF-8 bytes (139 octets), expressed in hexadecimal:
7b22616374696f6e223a7b2274797065223a226f627365727665227d2c226167
656e74223a7b226964223a226167656e743a6578616d706c65227d2c22637265
617465645f6174223a302c2265766964656e6365223a5b5d2c226a65705f7265
63656970745f7265636f7264223a2231222c227265636f72645f74797065223a
226265686176696f72227d
SHA-256, in lowercase hexadecimal:
e0d6b6bc6cf76a33e9124a4bd7298123e723745586aac1caa8004c00e013cd6b
Wang Expires 8 April 2027 [Page 47]
Internet-Draft JEP Receipt Profile October 2026
B.2. minimal-manifest
Input JSON:
NOTE: '\' line wrapping per RFC 8792
{
"jep_receipt_manifest": "1",
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
"root_event": {
"event_identity": {
"who": "did:example:receipt-service",
"id": "receipt-1"
}
},
"events": [
{
"event_identity": {
"who": "did:example:receipt-service",
"id": "receipt-1"
}
}
],
"records": [
{
"record_type": "behavior",
"digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e723745586a\
ac1caa8004c00e013cd6b",
"media_type": "application/json"
}
],
"created_at": 0
}
Canonical UTF-8 bytes (439 octets), expressed in hexadecimal:
Wang Expires 8 April 2027 [Page 48]
Internet-Draft JEP Receipt Profile October 2026
7b22637265617465645f6174223a302c226576656e7473223a5b7b226576656e
745f6964656e74697479223a7b226964223a22726563656970742d31222c2277
686f223a226469643a6578616d706c653a726563656970742d73657276696365
227d7d5d2c226a65705f726563656970745f6d616e6966657374223a2231222c
2270726f66696c65223a2268747470733a2f2f68756d616e6a7564676d656e74
2e6f72672f6a65702f70726f66696c65732f726563656970742f312f64726166
742d3031222c227265636f726473223a5b7b22646967657374223a2273686132
35363a6530643662366263366366373661333365393132346134626437323938
3132336537323337343535383661616331636161383030346330306530313363
643662222c226d656469615f74797065223a226170706c69636174696f6e2f6a
736f6e222c227265636f72645f74797065223a226265686176696f72227d5d2c
22726f6f745f6576656e74223a7b226576656e745f6964656e74697479223a7b
226964223a22726563656970742d31222c2277686f223a226469643a6578616d
706c653a726563656970742d73657276696365227d7d7d
SHA-256, in lowercase hexadecimal:
c7a9e369784ffefbe3ea2c51abac214010dbe6c48efb64a92568bd1448368c78
This manifest can be the primary record of an event whose Event
Identity is (did:example:receipt-service, receipt-1). It omits that
binding event's Event Hash and references the behavior record in
Appendix B.1. No event signature or inventory validation result is
implied.
B.3. unicode-null-array-number-boundaries
Input JSON:
Wang Expires 8 April 2027 [Page 49]
Internet-Draft JEP Receipt Profile October 2026
{
"jep_receipt_record": "1",
"record_type": "behavior",
"agent": {
"id": "agent:example"
},
"action": {
"type": "observe"
},
"created_at": 0,
"evidence": [],
"context": {
"n": null,
"array": [
null,
{},
[]
],
"numbers": [
-0.0,
1e-07,
1e-06,
1e+20,
1e+21
],
"names": {
"\ue000": "bmp",
"\ud83d\ude00": "non-bmp"
},
"strings": [
"\u00e9",
"e\u0301"
]
}
}
Canonical UTF-8 bytes (299 octets), expressed in hexadecimal:
7b22616374696f6e223a7b2274797065223a226f627365727665227d2c226167
656e74223a7b226964223a226167656e743a6578616d706c65227d2c22636f6e
74657874223a7b226172726179223a5b6e756c6c2c7b7d2c5b5d5d2c226e223a
6e756c6c2c226e616d6573223a7b22f09f9880223a226e6f6e2d626d70222c22
ee8080223a22626d70227d2c226e756d62657273223a5b302c31652d372c302e
3030303030312c3130303030303030303030303030303030303030302c31652b
32315d2c22737472696e6773223a5b22c3a9222c2265cc81225d7d2c22637265
617465645f6174223a302c2265766964656e6365223a5b5d2c226a65705f7265
63656970745f7265636f7264223a2231222c227265636f72645f74797065223a
226265686176696f72227d
Wang Expires 8 April 2027 [Page 50]
Internet-Draft JEP Receipt Profile October 2026
SHA-256, in lowercase hexadecimal:
41bfc5f24cfea4da326b1a5e37778db049f9d1cc41db1c07d46e4f261fb06259
This input exercises explicit nulls, nested arrays, UTF-16 member-
name ordering, canonically distinct Unicode strings, negative zero,
and exponent-format boundaries. Removing a null or additional
member, reordering an array, or normalizing the two strings before
JCS would change the record value and violate the digest-input rules.
B.4. Rejection and Status Cases
The following raw JSON snippets are invalid input for
canonicalization. They are parser tests, not complete behavior
records. A test harness MUST preserve the raw JSON text so that
duplicate names are not removed before testing. Each snippet MUST be
rejected:
{"a":1,"a":2}
{"outer":{"a":1,"\u0061":2}}
{"s":"\ud800"}
{"n":NaN}
{"n":1e400}
A serialized record containing invalid UTF-8 octets is likewise
rejected. A parser must not replace the invalid octets with
replacement characters.
The following cases apply to the complete records above. Other
required checks are assumed to pass unless stated otherwise; the
examples specify Receipt Profile check results, not signature test
vectors.
Wang Expires 8 April 2027 [Page 51]
Internet-Draft JEP Receipt Profile October 2026
+================================+===============================+
| Condition | Result |
+================================+===============================+
| The primary record is | record-binding and its |
| unavailable. | applicable structure check |
| | are indeterminate; receipt |
| | status is indeterminate. |
+--------------------------------+-------------------------------+
| A well-formed record does not | record-binding fails; receipt |
| match record_digest. | status is invalid. |
+--------------------------------+-------------------------------+
| The minimal behavior record | record-binding passes; |
| has evidence set to null, and | record-structure fails; |
| record_digest is recomputed | receipt status is invalid. |
| over that exact changed value. | |
+--------------------------------+-------------------------------+
| A required opaque artifact is | Its component integrity |
| unavailable. | result is indeterminate, |
| | never pass. |
+--------------------------------+-------------------------------+
| Required inventory has one | bundle-integrity fails; |
| digest mismatch and one | receipt status is invalid. |
| missing artifact. | Fail takes precedence. |
+--------------------------------+-------------------------------+
| A behavior record contains an | The additional member is |
| additional null-valued member | preserved. The baseline does |
| and its digest includes it. | not reject solely because the |
| | name is unrecognized. |
+--------------------------------+-------------------------------+
Table 4: Required Result Distinctions
Implementers SHOULD additionally test invalid field types,
inconsistent record-type declarations, absent critical markers, Event
Identity and Event Hash mismatches, circular manifest bindings,
unknown critical extensions, unperformed checks, and historical
revision selection. Digest agreement alone does not test these
properties.
Appendix C. Signed Receipt and Validation Cases
This appendix exercises the existing JEP-Baseline-Ed25519-JWS-JCS-0.7
signature class in [JEP-CONFORMANCE] together with the receipt-
binding extension. It defines no new signature mechanism. The
portable result contract is specified in Section 10.6; the JSON below
is test-vector notation.
Wang Expires 8 April 2027 [Page 52]
Internet-Draft JEP Receipt Profile October 2026
The example uses a fixed public test key, the explicitly selected
signed profile identifier in Section 4.1, and primary-receipt scope.
The request omits the mode, so the effective mode is archival. No
acceptance state, historical Event Identity database, audience
restriction, freshness rule, actor/key binding, or external evidence
assessment is selected. Signature success means validation with the
supplied test public key; it does not authenticate an external person
or organization. Event Identity checking here is limited to the
identifier rules for the supplied event.
The deterministic private seed below is public test material and MUST
NOT be used for production signing. The primary record is exactly
the minimal behavior record in Appendix B.1.
Ed25519 test private seed, in hexadecimal:
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
Corresponding raw Ed25519 public key, in hexadecimal:
03a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc8664125531b8
Unsigned event:
Wang Expires 8 April 2027 [Page 53]
Internet-Draft JEP Receipt Profile October 2026
NOTE: '\' line wrapping per RFC 8792
{
"jep": "1",
"id": "receipt-test-1",
"verb": "J",
"who": "urn:example:receipt-signer",
"when": 0,
"what": {
"claim": "test-observation"
},
"ext": {
"https://humanjudgment.org/jep/extensions/receipt-binding/1": {
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/\
draft-01",
"record_type": "behavior",
"record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e723\
745586aac1caa8004c00e013cd6b",
"media_type": "application/json"
}
},
"ext_crit": [
"https://humanjudgment.org/jep/extensions/receipt-binding/1"
]
}
Exact protected header UTF-8 text, with no trailing newline:
{"alg":"Ed25519"}
Protected-header base64url segment:
eyJhbGciOiJFZDI1NTE5In0
The JEP Signing Payload is the JCS UTF-8 serialization of the
unsigned event. Its octets, expressed as hexadecimal using the
display convention in Appendix B, are:
Wang Expires 8 April 2027 [Page 54]
Internet-Draft JEP Receipt Profile October 2026
7b22657874223a7b2268747470733a2f2f68756d616e6a7564676d656e742e6f
72672f6a65702f657874656e73696f6e732f726563656970742d62696e64696e
672f31223a7b226d656469615f74797065223a226170706c69636174696f6e2f
6a736f6e222c2270726f66696c65223a2268747470733a2f2f68756d616e6a75
64676d656e742e6f72672f6a65702f70726f66696c65732f726563656970742f
312f64726166742d3031222c227265636f72645f646967657374223a22736861
3235363a65306436623662633663663736613333653931323461346264373239
3831323365373233373435353836616163316361613830303463303065303133
63643662222c227265636f72645f74797065223a226265686176696f72227d7d
2c226578745f63726974223a5b2268747470733a2f2f68756d616e6a7564676d
656e742e6f72672f6a65702f657874656e73696f6e732f726563656970742d62
696e64696e672f31225d2c226964223a22726563656970742d746573742d3122
2c226a6570223a2231222c2276657262223a224a222c2277686174223a7b2263
6c61696d223a22746573742d6f62736572766174696f6e227d2c227768656e22
3a302c2277686f223a2275726e3a6578616d706c653a726563656970742d7369
676e6572227d
The JWS Signing Input is the ASCII protected-header segment, a dot,
and the unpadded base64url encoding of the JEP Signing Payload. The
transmitted detached form has an empty middle segment; the verifier
reconstructs that segment for the signing input as required by
[JEP-CONFORMANCE].
Detached signature string (unfold before use):
NOTE: '\' line wrapping per RFC 8792
eyJhbGciOiJFZDI1NTE5In0..3zdRKrT2dWuSffGaTeo0jDo7UeUCBelAFfuHSSMAqp\
F1_3W7kLxOuc3NzD377iIGzMFyXHHE3IWKSOVfFC4jBg
Complete signed event:
Wang Expires 8 April 2027 [Page 55]
Internet-Draft JEP Receipt Profile October 2026
NOTE: '\' line wrapping per RFC 8792
{
"jep": "1",
"id": "receipt-test-1",
"verb": "J",
"who": "urn:example:receipt-signer",
"when": 0,
"what": {
"claim": "test-observation"
},
"ext": {
"https://humanjudgment.org/jep/extensions/receipt-binding/1": {
"profile": "https://humanjudgment.org/jep/profiles/receipt/1/\
draft-01",
"record_type": "behavior",
"record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e723\
745586aac1caa8004c00e013cd6b",
"media_type": "application/json"
}
},
"ext_crit": [
"https://humanjudgment.org/jep/extensions/receipt-binding/1"
],
"sig": "eyJhbGciOiJFZDI1NTE5In0..3zdRKrT2dWuSffGaTeo0jDo7UeUCBelA\
FfuHSSMAqpF1_3W7kLxOuc3NzD377iIGzMFyXHHE3IWKSOVfFC4jBg"
}
The Event Hash uses the complete signed event, including sig,
according to JEP-Core. It is sha256: followed by:
d8522307eec9432c1e6b9ee56c2d6c8ed3bcd8f3d3584d87092fd85d946ac429
The expected results for this context are cryptographic: pass,
extension_processing: pass, record-binding: pass, record-structure:
pass, and Receipt Profile status valid. Manifest, inventory, and
participant-reference checks are not applicable. This result does
not establish any unselected trust, historical, or policy property.
The following mutations define negative cases. When an event member
changes, the event is re-signed with the test key unless the row
explicitly changes the signature. Re-signing isolates the receipt
rule under test from signature failure. The private seed, exact
header, and rules above make the re-signed variants reproducible.
Wang Expires 8 April 2027 [Page 56]
Internet-Draft JEP Receipt Profile October 2026
+==========================+=====================================+
| Change | Required result |
+==========================+=====================================+
| Withhold the primary | Signature passes. Binding, |
| record; keep the event | applicable structure, and extension |
| unchanged. | processing are indeterminate; |
| | receipt status is indeterminate. |
+--------------------------+-------------------------------------+
| Change action.type to | Signature and record structure |
| "modified" in the | pass. Binding fails; receipt |
| record; keep the event | status is invalid. |
| unchanged. | |
+--------------------------+-------------------------------------+
| Change the extension | Signature and digest comparison |
| record_type to "receipt- | pass. Manifest structure fails; |
| manifest" and re-sign; | receipt status is invalid. |
| supply the original | |
| behavior record. | |
+--------------------------+-------------------------------------+
| Set evidence to null; | Signature and binding pass. |
| recompute record_digest | Behavior-record structure fails; |
| over the changed value | receipt status is invalid. |
| and re-sign. | |
+--------------------------+-------------------------------------+
| Decode the signature | Cryptographic fails; receipt status |
| bytes, flip bit 0 of the | is invalid regardless of digest |
| first byte, and re- | agreement. |
| encode. | |
+--------------------------+-------------------------------------+
| Remove the receipt | Receipt-extension fails; receipt |
| identifier from ext_crit | status is invalid. |
| and re-sign. | |
+--------------------------+-------------------------------------+
| Use sha512: plus the | Receipt-extension fails under the |
| SHA-512 lowercase hex of | selected baseline; this is not an |
| the primary canonical | unsupported-algorithm success or |
| bytes in record_digest, | indeterminate result. |
| and re-sign. | |
+--------------------------+-------------------------------------+
| Add an unknown critical | JEP extension_processing fails; |
| extension and re-sign. | receipt status is invalid. |
+--------------------------+-------------------------------------+
| Omit the Receipt Profile | Profile-binding is indeterminate. |
| selection from the | The signed value is not an |
| validation context. | instruction to enable an unselected |
| | profile. |
+--------------------------+-------------------------------------+
| Use the -00 profile | Profile-binding and receipt- |
Wang Expires 8 April 2027 [Page 57]
Internet-Draft JEP Receipt Profile October 2026
| identifier in the | extension fail. The old identifier |
| extension and re-sign, | is not an alias for this contract. |
| while requesting this | |
| profile. | |
+--------------------------+-------------------------------------+
| Omit a separate | The original positive result is |
| specification-revision | unchanged. The signed semantic |
| hint while explicitly | identifier determines the Receipt |
| selecting the signed | contract. |
| profile identifier. | |
+--------------------------+-------------------------------------+
| Explicitly request | The requested mode is unsupported; |
| acceptance from a | the verifier does not substitute |
| verifier implementing | archival or claim valid acceptance. |
| only archival mode. | |
+--------------------------+-------------------------------------+
Table 5: Signed Receipt Negative Cases
Derived executable fixtures MAY include additional manifest and
inventory cases. Such fixtures MUST state the context and scope
actually tested. Passing this appendix is not sufficient evidence of
support for every JEP verb, companion profile, trust model, or
acceptance mode.
Author's Address
Yuqiang Wang
Email: signal@humanjudgment.org
URI: https://github.com/hjs-spec
Wang Expires 8 April 2027 [Page 58]