Context
Suzuki & Abe (2026), "A Verifier-Centric Conceptual Model for Digital
Credential Ecosystems" (Preprint, submitted to IEEE Access,
https://arxiv.org/abs/2607.10747), propose a model that decomposes
credential verification into three layers (L1 signature verification,
L2 semantic interpretation, L3 validation) and models the supply of
verification materials through two orthogonal planes: Constitution
(ecosystem-level arrangements and trust declarations) and Logistics
(how verification materials are stored and delivered).
Their core thesis: interoperability failures are not primarily caused
by format incompatibility, but by the fact that it remains unclear what
a verifier actually needs to obtain, and what it must trust, before it
can accept a credential.
Why this matters for RecordWeb
RecordWeb has so far been conceived largely from the creator/issuer
perspective (how is a provable Record produced?). The Logistics plane
is already well developed (DID resolver, federation, version graph).
The verifier perspective and an explicit Constitution plane
(trust rules — who trusts whom, under what conditions) are largely
missing.
Purpose of this tracking issue
This issue bundles the discussion so that the individual changes remain
consistent with each other. Please discuss cross-cutting/architectural
questions here; implementation-level details belong in the linked issues.
Sub-issues
Open guiding question
Does adding a verifier perspective fit within the existing eight design
principles of the RWC, or does it require extending/amending those
principles themselves (e.g. a ninth principle "Verifiability by third
parties")?
Reference
Suzuki, S. & Abe, R. (2026). A Verifier-Centric Conceptual Model for
Digital Credential Ecosystems. Preprint. https://arxiv.org/abs/2607.10747
Context
Suzuki & Abe (2026), "A Verifier-Centric Conceptual Model for Digital
Credential Ecosystems" (Preprint, submitted to IEEE Access,
https://arxiv.org/abs/2607.10747), propose a model that decomposes
credential verification into three layers (L1 signature verification,
L2 semantic interpretation, L3 validation) and models the supply of
verification materials through two orthogonal planes: Constitution
(ecosystem-level arrangements and trust declarations) and Logistics
(how verification materials are stored and delivered).
Their core thesis: interoperability failures are not primarily caused
by format incompatibility, but by the fact that it remains unclear what
a verifier actually needs to obtain, and what it must trust, before it
can accept a credential.
Why this matters for RecordWeb
RecordWeb has so far been conceived largely from the creator/issuer
perspective (how is a provable Record produced?). The Logistics plane
is already well developed (DID resolver, federation, version graph).
The verifier perspective and an explicit Constitution plane
(trust rules — who trusts whom, under what conditions) are largely
missing.
Purpose of this tracking issue
This issue bundles the discussion so that the individual changes remain
consistent with each other. Please discuss cross-cutting/architectural
questions here; implementation-level details belong in the linked issues.
Sub-issues
Open guiding question
Does adding a verifier perspective fit within the existing eight design
principles of the RWC, or does it require extending/amending those
principles themselves (e.g. a ninth principle "Verifiability by third
parties")?
Reference
Suzuki, S. & Abe, R. (2026). A Verifier-Centric Conceptual Model for
Digital Credential Ecosystems. Preprint. https://arxiv.org/abs/2607.10747