Deterministic Conformance Profile and Test Vectors for Evidence Qualification Receipts

Introduction Evidence Qualification Receipts are described in . 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.

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

The eqr-core-1 Profile An eqr-core-1 object is a JSON object as defined by . Duplicate JSON member names MUST cause non-conformance. SHA-256 is the only digest algorithm in this profile . Digest values MUST be exactly 32 octets represented using unpadded base64url . A producer that hashes a JSON object MUST first apply the JSON Canonicalization Scheme . All timestamps in this profile MUST be UTC Internet timestamps ending in Z and conforming to .

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;
evidence; and
supersedes, which can be null.

The strict member set is intentional for this conformance profile. Other EQR profiles can define extensions.

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.

Deterministic Status Derivation The status derivation function is: 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.

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.

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.

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.

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.

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.

Relationship to Other Work This document is a conformance companion to and follows the non-collapse distinction described in . It does not replace executor-side action/evidence processing such as , evidence challenge protocols such as , claim-preserving evidence exchange such as , or runtime conformance receipts such as .

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.

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.

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.