[CfC] Conformance, Security and Merkle Integrity (deadline: 2026-08-21)

This tracking issue records the formal Call for Consensus (CfC) of the RecordWeb Community Group, announced to the mailing list on 2026-08-07.

Source: [CfC] Call for Consensus: Conformance, Security and Merkle Integrity (deadline: 2026-08-28), Nik Jenzer, 2026-08-14, public-recordweb@w3.org

Scope

The primary purpose of this batch is to establish a coherent model for RecordWeb conformance: what an implementation claims, which profiles and roles it may claim, how requirements are made testable, and how conformance evidence can be expressed as a durable Record.

The batch also includes two protocol topics that are important for deployable and interoperable implementations: consolidated Privacy and Security Considerations, and a fully canonical Merkle-root construction.

The 14-day discussion period under GOVERNANCE.md §4.1 starts with this issue.

Proposal: Adopt the following issues as currently drafted, subject to discussion and any edits agreed during this CfC.

Conformance model

• RWC#12 — Define conformance as an accountable implementation claim
  Defines conformance as a profile-, role-, and version-specific implementation claim. It identifies the component that creates or asserts an RWP representation as the relevant trust boundary, requires an identifiable implementation and inspectable attestation, and distinguishes validation, assessment, attestation, and certification.

• RWP#5 — Add an explicit Conformance section to RWP
  Adds a dedicated protocol Conformance section, formally references RFC 2119 terminology, and identifies the requirements and extensions relevant to an RWP conformance claim.

• RWP#12 — Define modular conformance profiles and implementation roles
  Defines initial conformance profiles for Information Records, Case Records, and Source Integration, plus the roles producer, custodian, consumer, resolver, and source-adapter.

• RWP#13 — Define profile and role conformance requirements
  Adds a normative matrix linking profiles and roles to required capabilities, applicable SystemRecords, and testable requirements. It replaces an overbroad assumption that every conformant implementation must support every core Record type.

• RWP#14 — Define ConformanceRecord as a SystemRecord
  Defines a machine-readable, versioned, and independently inspectable attestation Record, including implementation and product version, claimed profiles and roles, assessment method, evidence, attester, expiry, and immutable supersession history.

• RWP#15 — Define the RWP Source Integration Conformant profile
  Defines a profile for source adapters and connectors that provide source provenance without necessarily creating an RWP Record. It specifies a minimum source-provenance statement and controlled source-integrity levels.

Related protocol clarifications

• RWP#6 — Add a Privacy and Security Considerations section to RWP
  Adds a consolidated, jurisdiction-neutral section addressing cryptographic integrity, key-management expectations, persistent identifiers and personal data, payload deletion, consent implications of Solid Pod delivery, and data minimisation.

• RWP#19 — Define canonical Merkle hash inputs and domain separation
  Defines a single canonical and byte-level Merkle-root algorithm for Case snapshots. The work includes canonical digest representation, ordering, odd-element behaviour, leaf/node domain separation, algorithm versioning, compatibility treatment, and test vectors.

Deadline

2026-08-21

How to participate

• Substantive discussion, concerns, and suggested edits belong in comments on the relevant issue. That is where the specification text is developed.
• On this issue, react with 👍 if you support closing this CfC with the current or consensus-amended text of all eight issues once the deadline passes.
• If you object to adopting one or more issues, a 👍/👎 reaction alone is not sufficient. Please add a comment on this issue before the deadline that identifies the affected issue or issues and explains the technical rationale. Detailed proposed edits should be made on the respective issue.
• The conformance issues are intentionally presented as one architectural set. Comments that affect profiles, roles, the conformance matrix, ConformanceRecords, or Source Integration should identify consequences for the other issues in that set.
• Silence is not treated as an objection. Active review is particularly welcome from implementers, records and case-management practitioners, connector developers, procurement specialists, security experts, and institutional adopters.

What happens next

After the deadline has passed, the Editor (or a Chair, if no Editor is assigned) will summarise the outcome here.

If consensus is reached, the proposed text is merged. If consensus cannot be reached, the Chairs will decide and document the reasoning in the relevant issue, per GOVERNANCE.md §4.1.