| Internet-Draft | Verifiable Evidence Records | October 2026 |
| Watts | Expires 19 April 2027 | [Page] |
This document specifies a minimal JSON evidence-record profile for checking artifact digests and separating integrity verification from scientific assessment. It defines an interoperable record structure, validation algorithm, and negative test cases. It does not assert that an integrity-checked scientific claim is true.¶
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 19 April 2027.¶
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.¶
Research artifacts can be transferred among archives, laboratories, and automated pipelines. A digest can establish byte equality with a declared value, but not authenticity of its origin or scientific truth. This profile makes that boundary explicit and defines a small interoperable verification result.¶
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.¶
This profile is restricted to JSON records and SHA-256 digests of externally supplied artifact octets. It does not define signatures, identity authentication, scientific peer review, content retrieval, or an Internet media type.¶
A record MUST be a JSON object conforming to the JSON syntax defined by [RFC8259]. It MUST have exactly the following required members: profile, record_id, artifact, and assertion. Additional members MUST be rejected in version 1 to avoid ambiguous extension semantics. Duplicate JSON member names MUST be rejected.¶
The profile member MUST equal the string "vser-1". The record_id member MUST be a nonempty ASCII string consisting only of letters, digits, hyphens, underscores, and periods, with a maximum of 128 characters. This identifier is local to the producer and does not prove global uniqueness.¶
The artifact member MUST be an object containing exactly digest_algorithm and digest_hex. digest_algorithm MUST equal "sha-256". digest_hex MUST consist of exactly 64 lowercase ASCII hexadecimal characters and denotes the SHA-256 digest of the original artifact octets without transformation.¶
The assertion member MUST equal the string "integrity-only". This string explicitly disclaims scientific validity, authorship authentication, and provenance verification.¶
A verifier MUST parse the record as UTF-8 JSON, reject duplicate keys at every nesting level, reject nonconforming field types and values, and reject unknown fields. It MUST obtain the artifact octets through a separately trusted local mechanism; this profile does not authorize network fetching.¶
The verifier MUST compute SHA-256 as specified in [RFC6234] over the exact supplied octets and compare the resulting 32-octet digest with the 32 octets decoded from digest_hex. On equality it MUST return INTEGRITY_MATCH; otherwise it MUST return INTEGRITY_MISMATCH. Malformed records MUST produce INVALID_RECORD and MUST NOT produce INTEGRITY_MATCH. The result MUST NOT be labeled SCIENTIFICALLY_VERIFIED.¶
A verifier MUST impose locally appropriate limits on record size and artifact size. The protocol intentionally makes no claim about content authenticity, source authority, or temporal ordering.¶
Implementations MUST accept the positive example and MUST reject the altered artifact, invalid digest length, uppercase digest, duplicate member, unknown member, and incorrect assertion examples provided in the companion test package. The tests establish only this profile's specified behavior.¶
SHA-256 integrity comparison does not authenticate the entity supplying the expected digest. An attacker able to substitute both record and artifact can create a matching pair. The profile MUST NOT be presented as an authenticity or provenance guarantee. Artifact bytes may contain sensitive information; implementations SHOULD avoid logging their contents and SHOULD use least-privilege local access. Scientific validity, research ethics, and licensing remain separate review obligations.¶
This document requests no IANA actions.¶