Network Working Group D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Experimental 14 October 2026 Expires: 17 April 2027 Deterministic Conformance Profile and Test Vectors for Evidence Qualification Receipts draft-watts-eqr-conformance-00 Abstract This document defines a deterministic conformance profile and test- vector corpus for Evidence Qualification Receipts (EQRs). The profile, named eqr-core-1, makes receipt conformance mechanically reproducible: strict JSON structure, SHA-256 digest encoding, UTC timestamp handling, evidence-reference integrity, requirement-state derivation, and three-valued PASS, FAIL, or INDETERMINATE results are checked by a closed algorithm. The profile is intentionally narrow. Conformance does not establish that evidence is true, that a proposition is scientifically valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics, not promotion of conformance into substantive truth. 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 17 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Watts Expires 17 April 2027 [Page 1] Internet-Draft EQR Conformance 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The eqr-core-1 Profile . . . . . . . . . . . . . . . . . . . 3 3.1. Required Members . . . . . . . . . . . . . . . . . . . . 3 3.2. Requirement States . . . . . . . . . . . . . . . . . . . 4 4. Deterministic Status Derivation . . . . . . . . . . . . . . . 4 5. Time and Freshness Rules . . . . . . . . . . . . . . . . . . 5 6. Append-Only Supersession . . . . . . . . . . . . . . . . . . 5 7. Conformance Outcome . . . . . . . . . . . . . . . . . . . . . 5 8. Normative Test Vectors . . . . . . . . . . . . . . . . . . . 5 9. Falsifiability and Limits . . . . . . . . . . . . . . . . . . 6 10. Relationship to Other Work . . . . . . . . . . . . . . . . . 6 11. Security Considerations . . . . . . . . . . . . . . . . . . . 6 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 14. Normative References . . . . . . . . . . . . . . . . . . . . 7 15. Informative References . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Evidence Qualification Receipts are described in [I-D.watts-eqr]. Their central requirement is that unresolved required evidence remain distinguishable from both satisfied and failed evidence, and that qualification remain distinct from authorization. That architectural distinction is useful only if independent implementations derive the same status from the same declared requirement states. This document therefore defines a strict conformance profile, eqr- core-1, plus executable test vectors. The profile does not attempt to determine whether evidence corresponds to reality. It determines whether an EQR object is structurally and semantically self- consistent under a fully specified finite rule set. A receipt can be conformant and still contain evidence from an issuer a relying party does not trust. A conformant PASS result is not permission to execute an action. Watts Expires 17 April 2027 [Page 2] Internet-Draft EQR Conformance October 2026 2. Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Conformance Agreement with the finite syntactic and semantic rules of this profile. Substantive validity Whether the underlying evidence and proposition are actually correct. This document does not establish it. Requirement state One of satisfied, failed, missing, unresolved, or stale. Derived status The PASS, FAIL, or INDETERMINATE result computed from the requirement states. 3. The eqr-core-1 Profile An eqr-core-1 object is a JSON object as defined by [RFC8259]. Duplicate JSON member names MUST cause non-conformance. SHA-256 is the only digest algorithm in this profile [RFC6234]. Digest values MUST be exactly 32 octets represented using unpadded base64url [RFC4648]. A producer that hashes a JSON object MUST first apply the JSON Canonicalization Scheme [RFC8785]. All timestamps in this profile MUST be UTC Internet timestamps ending in Z and conforming to [RFC3339]. 3.1. Required Members The profile requires exactly the following top-level members: * version, whose value is "1"; * profile_id, whose value is "eqr-core-1"; * receipt_id and issuer; * issued_at, expires_at, and evaluation_time; * profile and claim SHA-256 digest objects; * requirements; * evaluation; Watts Expires 17 April 2027 [Page 3] Internet-Draft EQR Conformance October 2026 * evidence; and * supersedes, which can be null. The strict member set is intentional for this conformance profile. Other EQR profiles can define extensions. 3.2. Requirement States Each requirement has a unique id, one state, and an optional array of evidence_ids. The only states are: * satisfied; * failed; * missing; * unresolved; and * stale. A satisfied requirement MUST name at least one evidence object. Every named evidence identifier MUST resolve within the same receipt. Evidence used by a satisfied requirement MUST NOT be stale at evaluation_time. 4. Deterministic Status Derivation The status derivation function is: def derive_status(requirements): if not requirements: return "indeterminate" states = [r["state"] for r in requirements] if any(s == "failed" for s in states): return "fail" if all(s == "satisfied" for s in states): return "pass" return "indeterminate" Watts Expires 17 April 2027 [Page 4] Internet-Draft EQR Conformance October 2026 FAIL has precedence over missing or unresolved information. PASS is possible only for a non-empty requirement set in which every requirement is satisfied. In every other valid case the result is INDETERMINATE. The receipt's declared evaluation.status MUST equal the derived status. A mismatch is non-conformant; a verifier MUST NOT rewrite the declaration to make it conform. 5. Time and Freshness Rules expires_at MUST be later than issued_at. evaluation_time MUST fall within the inclusive receipt validity interval. An evidence object has a fresh_until timestamp. A requirement declared satisfied is non-conformant if any evidence object it relies on has fresh_until earlier than evaluation_time. This rule checks self-consistency only. It does not establish that the chosen freshness interval is appropriate for a relying party's risk or policy. 6. Append-Only Supersession supersedes can identify a predecessor receipt. It MUST NOT equal the current receipt_id. This profile does not mutate predecessor state. New evidence is represented by a new receipt. 7. Conformance Outcome A verifier returns two logically separate outputs: * *conformant*: whether the object satisfies this profile; and * *derived_status*: pass, fail, or indeterminate when the object is conformant. Non-conformance MUST NOT be reported as PASS, FAIL, or INDETERMINATE. Those values describe evidence qualification semantics, not parser or profile validity. 8. Normative Test Vectors The companion corpus contains twenty-one vectors covering valid PASS, FAIL, and INDETERMINATE cases plus malformed or internally inconsistent inputs. The SHA-256 digest of the UTF-8 vector file eqr-core-1-vectors.json in the author's published package is: Watts Expires 17 April 2027 [Page 5] Internet-Draft EQR Conformance October 2026 8d8832b5de8c12393f47be3a7067ecd69edfc26822441595318e72e77ea923df The corpus includes empty requirements, FAIL precedence, missing and stale evidence, duplicate requirement identifiers, unsupported hash algorithms, invalid digest encodings, expired receipts, unknown evidence references, invalid state values, self-supersession, and declared-status mismatch. An implementation claiming conformance to the vector profile MUST produce the expected conformance Boolean and derived status for every vector. Failure of one vector is sufficient to reject a claim of complete vector-profile conformance. 9. Falsifiability and Limits This specification is intentionally falsifiable at the implementation layer. If two purportedly conformant implementations produce different outputs for the same normative vector, at least one implementation is non-conformant or the specification is ambiguous and requires revision. Passing all vectors does not establish truth of the evidence, scientific validity of the proposition, honesty of the issuer, appropriateness of the profile, authorization to act, successful execution, or safety. Those are different claims requiring different evidence. 10. Relationship to Other Work This document is a conformance companion to [I-D.watts-eqr] and follows the non-collapse distinction described in [I-D.watts-noncollapse]. It does not replace executor-side action/ evidence processing such as [I-D.schrock-aeb], evidence challenge protocols such as [I-D.schrock-aec], claim-preserving evidence exchange such as [I-D.abak-claim-preservation], or runtime conformance receipts such as [I-D.correctover-ccs]. 11. Security Considerations Strict parsing prevents duplicate-member substitution and status laundering through ambiguous JSON. Digest and timestamp checks prevent several classes of malformed or stale self-consistency claims, but this profile provides no key management, issuer authentication, revocation, trust-anchor selection, or policy decision. Watts Expires 17 April 2027 [Page 6] Internet-Draft EQR Conformance October 2026 A malicious issuer can create a perfectly conformant receipt containing false evidence. Therefore conformant MUST NOT be interpreted as truthful, trusted, authorized, or safe. 12. Privacy Considerations Evidence identifiers and digests can still act as correlators. Implementations should minimize externally exposed evidence metadata and avoid placing sensitive plaintext into receipts when a scoped digest or protected reference is sufficient. 13. IANA Considerations This document has no IANA actions. The string eqr-core-1 is a profile label defined by this experimental document and is not an IANA registration. 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . 15. Informative References Watts Expires 17 April 2027 [Page 7] Internet-Draft EQR Conformance October 2026 [I-D.watts-eqr] Watts, D., "Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts", Work in Progress, Internet-Draft, draft-watts-agent-evidence- boundary-00, September 2026, . [I-D.watts-noncollapse] Watts, D. O., "Non-Collapse Requirements for Evidence- Bearing Agent Systems", Work in Progress, Internet-Draft, draft-watts-agent-noncollapse-requirements-00, October 2026, . [I-D.schrock-aeb] Schrock, I., "The Action Evidence Boundary for Consequential Agent Effects", Work in Progress, Internet- Draft, draft-schrock-action-evidence-boundary-07, September 2026, . [I-D.schrock-aec] Schrock, I., "An Authorization Evidence Challenge for High-Risk Agent Actions", Work in Progress, Internet- Draft, draft-schrock-ae-challenge-08, September 2026, . [I-D.abak-claim-preservation] Abak, A. T., "Claim-Preserving Exchange of AI Evaluation Evidence", Work in Progress, Internet-Draft, draft-abak- ai-evaluation-claim-preservation-00, September 2026, . [I-D.correctover-ccs] Wang, G., "Correctover Conformance Shape: A Receipt and Binding Specification for Agent Runtime Verification", Work in Progress, Internet-Draft, draft-correctover-ccs- 10, September 2026, . Author's Address Watts Expires 17 April 2027 [Page 8] Internet-Draft EQR Conformance October 2026 Deonté O’dell Watts GoodShyt Group Inc. San Francisco, CA United States Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 17 April 2027 [Page 9]