Skip to main content

Web4 Claims and Verification
draft-jacobs-web4-claims-verification-00

Document Type Active Internet-Draft (individual)
Author Tim Jacobs
Last updated 2026-09-12
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jacobs-web4-claims-verification-00
Internet Engineering Task Force                                T. Jacobs
Internet-Draft                                                KTS Global
Intended status: Experimental                          12 September 2026
Expires: 16 March 2027

                      Web4 Claims and Verification
                draft-jacobs-web4-claims-verification-00

Abstract

   This document distinguishes claims, evidence, assessments,
   assertions, verification events, challenges, supersession,
   suspension, expiration, revocation, and receipts without
   standardizing private scoring internals.

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

Jacobs                    Expires 16 March 2027                 [Page 1]
Internet-Draft        Web4 Claims and Verification        September 2026

Table of Contents

   1.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Core Distinctions . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Claim Assertion . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Verification Events . . . . . . . . . . . . . . . . . . . . .   3
   6.  Challenges  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Correction and Supersession . . . . . . . . . . . . . . . . .   3
   8.  Suspension, Expiration, and Revocation  . . . . . . . . . . .   3
   9.  Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   10. Conformance . . . . . . . . . . . . . . . . . . . . . . . . .   4
   11. Relationship to Research Artifacts  . . . . . . . . . . . . .   4
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   4
   13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   15. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   16. Informative References  . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Conventions and Terminology

   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, as shown here.

2.  Introduction

   This document defines distinctions and lifecycle rules for claims,
   evidence, assessments, assertions, verification events, challenges,
   supersession, suspension, expiration, revocation, and receipts.

3.  Core Distinctions

   A Claim is a proposition about a subject.  Evidence supports or
   opposes a claim.  An Assessment is an evaluation under policy.  An
   Assertion is an accountable signed statement.  A Verification Event
   records checks.  A Receipt records that an event occurred.

   Signed, verified, conformant, high assurance, and currently valid are
   distinct properties and MUST NOT be treated as synonyms.

Jacobs                    Expires 16 March 2027                 [Page 2]
Internet-Draft        Web4 Claims and Verification        September 2026

4.  Claim Assertion

   A claim assertion MUST identify the claim, subject, issuer, claim
   type or proposition, issuance time, policy context, status mechanism,
   and proof.

   {
     "assertion_id": "urn:web4:claim:01JEXAMPLE",
     "assertion_type": "claim",
     "subject_id": "did:example:node-842",
     "issuer_id": "did:example:issuer-1",
     "claim_type": "urn:example:claim:operational-state",
     "claim_value": "active",
     "status_uri": "https://status.example/claims/01JEXAMPLE",
     "proof": {
       "type": "ExampleProof",
       "verification_method": "did:example:issuer-1#key-1",
       "value": "BASE64URL-SIGNATURE"
     }
   }

5.  Verification Events

   A verification event MUST identify the verifier, object checked,
   checks performed, policy, time, result, and proof.  Success MUST NOT
   imply checks outside declared scope.

6.  Challenges

   A challenge MUST identify the challenged assertion, challenger,
   grounds, issue time, evidence where permitted, status, and proof.

7.  Correction and Supersession

   Correction MUST preserve the original and issue a linked replacement.
   Supersession MUST NOT erase historical status or receipts.

8.  Suspension, Expiration, and Revocation

   Suspension, expiration, and revocation are distinct.  Verifiers MUST
   treat unresolved status as indeterminate.

9.  Lifecycle

   Material transitions MUST be authorized, integrity-protected, and
   recorded by a receipt.

Jacobs                    Expires 16 March 2027                 [Page 3]
Internet-Draft        Web4 Claims and Verification        September 2026

10.  Conformance

   Conformance does not require publication of a trust vector,
   reputation function, confidence graph, scoring model, or protected
   assessment method.

11.  Relationship to Research Artifacts

   Broader Web4 architectural work is described informatively in
   [I-D.reilly-web4].  Informative research materials MAY be published
   as versioned scholarly artifacts, including DOI-addressable records.

   A research artifact is not required for conformance unless expressly
   incorporated as a Normative Reference by a named profile.
   Referencing or verifying an artifact does not establish the truth of
   its conclusions, regulatory approval, certification, security, legal
   compliance, or IETF endorsement.

   A Conforming Implementation MUST NOT require access to KCoordinate,
   KQAS, or another protected internal assessment method unless a
   separate deployment agreement selects that implementation.

12.  Security Considerations

   Implementations MUST authenticate issuers, validate proof integrity,
   check proof purpose, enforce temporal validity, and resolve current
   status before relying on an object.

   Implementations MUST address identifier confusion, issuer
   impersonation, key compromise, algorithm downgrade, replay, stale
   status, unauthorized supersession, cross-policy confusion,
   canonicalization ambiguity, denial of service, and fail-open handling
   of indeterminate validity.

   Evidence commitments can confirm correspondence with committed bytes
   but do not prove truth, completeness, legality, provenance, or
   fitness for purpose.  Profiles SHOULD define privacy-preserving
   commitment procedures for low-entropy artifacts.

   Proof verification establishes integrity and control of a
   verification method; it does not establish substantive truth.

13.  Privacy Considerations

   Persistent identifiers, status queries, proofs, policy references,
   and linked receipts can enable correlation.  Implementations MUST
   minimize disclosed data and SHOULD use unlinkable or pairwise
   identifiers where they satisfy policy.

Jacobs                    Expires 16 March 2027                 [Page 4]
Internet-Draft        Web4 Claims and Verification        September 2026

   Private evidence MAY remain undisclosed and be represented by a
   cryptographic commitment.  Retention and erasure requirements MUST be
   specified by policy and account for applicable obligations.

14.  IANA Considerations

   This document requests no IANA actions.

15.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

16.  Informative References

   [I-D.reilly-web4]
              Reilly, L. J., "Web4: A Verifiable, Agent-Native
              Architecture for the World Wide Web", Work in Progress,
              Internet-Draft, draft-reilly-web4-00, 26 August 2026,
              <https://datatracker.ietf.org/doc/draft-reilly-web4/>.

Author's Address

   Tim Jacobs
   KTS Global
   United Arab Emirates
   Email: tim@ktsglobal.live

Jacobs                    Expires 16 March 2027                 [Page 5]