Web4 Claims and Verification
draft-jacobs-web4-claims-verification-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| 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]