Web4 Assessment Assertions
draft-jacobs-web4-assessment-assertions-00

Internet Engineering Task Force                                T. Jacobs
Internet-Draft                                                KTS Global
Intended status: Experimental                          12 September 2026
Expires: 16 March 2027

                       Web4 Assessment Assertions
               draft-jacobs-web4-assessment-assertions-00

Abstract

   This document defines an implementation-neutral envelope for
   externally presented assessment results, including subject, issuer,
   policy, result, validity, evidence commitments, proof, and current
   status, while protected methods remain confidential.

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 Assessment Assertions         September 2026

Table of Contents

   1.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   2
   4.  Assessment Assertion  . . . . . . . . . . . . . . . . . . . .   3
   5.  Evaluator Requirements  . . . . . . . . . . . . . . . . . . .   3
   6.  Verifier Requirements . . . . . . . . . . . . . . . . . . . .   3
   7.  Status Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  Conformance . . . . . . . . . . . . . . . . . . . . . . . . .   4
   9.  Relationship to Research Artifacts  . . . . . . . . . . . . .   4
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   4
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   13. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   14. 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 an implementation-neutral envelope for an
   externally presented assessment result.  It standardizes the
   verification surface, not the method used to calculate the result.

   A Conforming Evaluator MAY use a public, proprietary, confidential,
   automated, human-mediated, cryptographic, mathematical, geometric,
   statistical, or machine-learning method.  KCoordinate and KQAS are
   possible implementations but are neither required nor specified here.

3.  Scope and Non-Goals

   This document defines assertion syntax, issuer accountability, policy
   context, temporal validity, evidence commitments, proof carriage, and
   status resolution.  It does not define coordinate spaces, transforms,
   metrics, mappings, derivations, score equations, weights, thresholds,
   calibration, features, training inputs, or private evidence.

Jacobs                    Expires 16 March 2027                 [Page 2]
Internet-Draft         Web4 Assessment Assertions         September 2026

4.  Assessment Assertion

   An Assessment Assertion MUST identify the assertion, subject,
   accountable issuer, applicable policy or profile, outcome, issuance
   time, temporal validity, proof mechanism, and current-status
   mechanism.  A profile MAY require an assurance-class reference and
   evidence commitments.

   {
     "assertion_id": "urn:web4:assertion:01JEXAMPLE",
     "assertion_type": "assessment",
     "subject_id": "did:example:node-842",
     "issuer_id": "did:example:evaluator-1",
     "policy_id": "urn:web4:policy:admission:v1",
     "outcome": "conformant",
     "issued_at": "2026-09-12T13:59:00Z",
     "valid_until": "2026-12-12T13:59:00Z",
     "status_uri": "https://status.example/assertions/01JEXAMPLE",
     "proof": {
       "type": "ExampleProof",
       "verification_method": "did:example:evaluator-1#key-1",
       "value": "BASE64URL-SIGNATURE"
     }
   }

5.  Evaluator Requirements

   A Conforming Evaluator MUST expose sufficient information to verify
   issuer, subject, policy context, temporal validity, integrity
   protection, and current status.  It MUST retain records required by
   policy and support correction, supersession, suspension, expiration,
   or revocation where applicable.

   Conformance MUST NOT require disclosure of protected inputs,
   coordinate representations, model parameters, inference processes,
   private evidence, calibration material, scoring functions, or trade-
   secret methods.

6.  Verifier Requirements

   A Verifier MUST validate issuer authority, subject binding, policy
   identity and version, temporal validity, proof integrity, and current
   status before treating an assertion as active.  Unresolved status
   MUST be treated as indeterminate.

Jacobs                    Expires 16 March 2027                 [Page 3]
Internet-Draft         Web4 Assessment Assertions         September 2026

7.  Status Model

   The base status vocabulary is active, suspended, superseded, revoked,
   expired, and indeterminate.

8.  Conformance

   Conformance does not establish that an assessment conclusion is true
   or that its subject is secure, lawful, or suitable for a particular
   purpose.

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

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

Jacobs                    Expires 16 March 2027                 [Page 4]
Internet-Draft         Web4 Assessment Assertions         September 2026

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

   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.

12.  IANA Considerations

   This document requests no IANA actions.

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

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