Deterministic Conformance Profile and Test Vectors for Evidence Qualification Receipts

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.¶

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

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.¶

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].¶

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"

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:¶

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.¶

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.¶

Author's Address