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 21 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. Deterministic Processing Order

An implementation can perform checks in any internal order, but its externally observable result MUST be equivalent to the following logical sequence:¶

1. strict JSON parsing, including rejection of duplicate member names;¶

2. top-level and nested shape validation;¶

3. profile, version, digest, and timestamp validation;¶

4. evidence identifier and freshness validation;¶

5. requirement-state and evidence-reference validation;¶

6. deterministic status derivation;¶

7. declared-status equality check; and¶

8. supersession self-reference check.¶

A later semantic check MUST NOT convert an earlier non-conformant input into a conformant qualification result. Implementations can report diagnostics from the earliest detected error or aggregate diagnostics, but they must agree on the conformance Boolean and, for conformant inputs, the derived status.¶

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

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

9. Deterministic Verifier Result

A verifier implementation claiming eqr-core-1 semantic conformance MUST expose, directly or through an equivalent API, the following logical result:¶

{
  "profile_id": "eqr-core-1",
  "conformant": true,
  "derived_status": "pass"
}

conformant is a Boolean. derived_status is one of pass, fail, or indeterminate only when conformant is true. For a non-conformant object, a verifier MUST NOT assign a qualification status; the logical value of derived_status is null or absent.¶

Implementations MAY expose additional diagnostic reason codes. Diagnostic strings are not evidence status and are not part of the qualification lattice defined by this document.¶

10. Conformance Claim Levels

To prevent overbroad or false-positive conformance claims, this document distinguishes four claim levels. An implementation MUST NOT claim a stronger level merely because a weaker level has passed.¶

Syntax Conformance

The input is accepted under the strict JSON and field constraints of this profile.¶

Semantic Conformance

The implementation derives PASS, FAIL, and INDETERMINATE exactly as specified and enforces the evidence-reference, time, digest, and supersession rules.¶

Vector-Profile Conformance

The implementation produces the expected conformance Boolean and derived status for every normative vector identified by the declared vector-corpus digest.¶

Independent Reproduction

A separately implemented verifier, under independently controlled source and execution conditions, reproduces the declared vector-profile results. Running two code paths in the same package or environment is not sufficient by itself.¶

Syntax Conformance does not imply Semantic Conformance. Semantic Conformance does not imply complete Vector-Profile Conformance. Complete Vector-Profile Conformance does not imply Independent Reproduction.¶

11. Conformance Claim Report

A published claim of complete Vector-Profile Conformance SHOULD identify:¶

• the profile identifier;¶
• the exact SHA-256 digest of the vector corpus;¶
• the implementation name and version or source digest;¶
• the execution environment sufficient to reproduce the test;¶
• the number of vectors attempted, passed, and failed; and¶
• whether the result is local execution evidence or independent reproduction.¶

A report MUST NOT omit failed vectors while claiming complete vector-profile conformance. A report for a different vector-corpus digest is a different conformance claim.¶

{
  "profile_id": "eqr-core-1",
  "vector_corpus_sha256": "8d8832b5de8c12393f47be3a7067ecd69edfc26822441595318e72e77ea923df",
  "implementation": {
    "name": "example-verifier",
    "version": "1.0"
  },
  "execution": {
    "attempted": 21,
    "passed": 21,
    "failed": 0,
    "independent_reproduction": false
  }
}

The example report is non-normative. In particular, setting independent_reproduction to true is a provenance assertion that requires evidence external to the conformance algorithm itself.¶

12. 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, a raw JSON duplicate-member case, 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.¶

13. Conformance Artifact Set

The author-maintained conformance package for this revision contains the normative vector corpus, a JSON Schema, an executable reference verifier, a separately written local oracle, and machine-readable execution reports. These artifacts are provided to make implementation disagreements observable and reproducible.¶

In the author's local execution environment, the primary vector runner produced 21/21 passing vectors with 0 failures. The second local oracle agreed with the primary verifier on 20/20 object-based comparisons, and 7/7 expected-conformant object vectors validated against the JSON Schema.¶

These local results are implementation evidence only. They are not independent reproduction and do not establish substantive validity of any evidence, proposition, authorization decision, or deployment.¶

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

A single normative vector for which a claimed complete Vector-Profile Conformance implementation produces the wrong conformance Boolean or wrong derived status is a sufficient counterexample to that implementation's complete conformance claim. A single independently reproduced disagreement between reasonable implementations can also indicate an ambiguity in this specification and should be treated as a specification defect until resolved.¶

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

16. Changes from -01

Revision -02 keeps the eqr-core-1 data model, status lattice, and normative vector-corpus digest unchanged. It adds explicit conformance claim levels, a canonical logical verifier result, a reproducible conformance-claim report, and deterministic processing-order requirements. These additions are intended to prevent a parser-only success, partial vector run, or same-environment cross-check from being presented as complete or independently reproduced conformance.¶

Revision -02 also refreshes the informative Correctover CCS citation to revision -10. No scientific truth, authorization, issuer trust, or independent-reproduction claim is added by this revision.¶

17. Changes from -00

Revision -01 preserves the eqr-core-1 status-derivation semantics and the published vector-corpus digest. It adds explicit documentation of the raw duplicate-JSON-member test, publishes additional artifact digests, records local dual-oracle and JSON-Schema cross-check results, and more clearly separates local conformance evidence from independent reproduction or substantive truth.¶

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

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

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