Add verifier perspective as a distinct conceptual element

[Jenziner]

Part of: #1

Problem

The RWC concept paper is written almost entirely from the perspective
of the entity that creates, versions, and finalizes a Record. Sections
4–7 describe in detail what makes a Record trustworthy from the
issuer/owner side (identity, schema governance, finalization, version
graph). What is missing is an explicit treatment of the verifier
perspective: the party that receives or looks up a Record it did not
create, and must decide whether to accept it as valid.

Suzuki & Abe (2026) argue that interoperability and trust problems
mostly occur at exactly this point — not at data-model or format level,
but at the point where a third party asks "what do I need to obtain,
and what do I need to trust, before I accept this?"

Why this matters for RecordWeb specifically

RecordWeb is explicitly designed for cross-organizational and
cross-jurisdictional use (see RWC section 8 "Related Concepts and
Demarcation", and the federation model in RWP Ch. 12). This means
verification will routinely be performed by parties outside the
originating organization. The concept currently gives no answer to:

• What must a verifier be able to resolve/retrieve before it can
  evaluate a Record (DID document, schema version, owner key,
  federation namespace registration)?
• What assumptions is the verifier implicitly required to trust
  (e.g. that the namespace registry is authoritative, that the DID
  method resolver has not been compromised)?
• Is there a minimal "verification contract" that any RecordWeb-
  compliant Record implicitly offers to any verifier, regardless of
  ecosystem?

Proposed direction (open for discussion)

Introduce a new section in RWC (suggested location: after section 7
"Accountability and Trust") that explicitly describes Record
verification from the perspective of a third party, distinguishing at
least:

1. What the verifier must be able to resolve (identity resolution)
2. What the verifier must be able to check (integrity/signature)
3. What the verifier must accept on trust, and on what basis
   (trust assumptions)

This does not need to duplicate the technical detail already in RWP —
it should establish the conceptual vocabulary that RWP can then make
normative.

Reference

Suzuki, S. & Abe, R. (2026). A Verifier-Centric Conceptual Model for
Digital Credential Ecosystems. Preprint. https://arxiv.org/abs/2607.10747