CfC8: Optional service Block

CHANGELOG.md

@@ -6,6 +6,15 @@ Versioning follows [Semantic Versioning](https://semver.org/).
 
 ---
 
+## [0.0.9] – 2026-10-06
+
+Implemented CfC 8 outcomes. See 
+Optional Service-Block:
+- [RWP#28](https://github.com/recordweb/rwp/issues/28)
+
+Editorial:
+- Version update, wording, syntax
+
 ## [0.0.8] – 2026-10-05
 
 Implemented CfC 6 outcomes. See 

chapters/accountability-trust.bs

@@ -128,6 +128,7 @@ Open Government Data principles provide a useful model for this approach: inform
 
 Nanopublications or comparable citable publication mechanisms MAY be used to publish atomic assertions, provenance information, and publication information. They are optional publication mechanisms and are not required by the RWP core.
 
+
 ## Trust Assumptions ## {#section-accountability-trust-assumptions}
 
 Every verification rests on trust assumptions. Integrity validation shows that an obtained object matches its RecordWeb hash. It does not show who controls an identifier, how that identifier was obtained, or under which rules a schema was published. RecordWeb distinguishes four trust assumptions:

chapters/conformance.bs

@@ -7,7 +7,7 @@ Conceptually, the relevant trust boundary is the software component that creates
 
 A source system does not, merely because another implementation creates an RWP representation from information obtained from it, thereby become the subject of that implementation's conformance claim. This holds independently of whether the source system also transfers its underlying content, or provides only provenance information about it while the content itself remains outside RWP's reach, for instance where the content is confidential and must not leave the source system. The allocation of conformance responsibility is defined by [[RWP]].
 
-## Validation, Assessment, Attestation, and Certification
+## Validation, Assessment, Attestation, and Certification ## {#section-conformance-validation}
 
 The following distinctions explain how conformance claims can be understood; they do not introduce additional protocol requirements.
 

chapters/reference-architecture.bs

@@ -141,6 +141,8 @@ This layer includes service discovery and technical resolution mechanisms. Such
 
 A DID Resolver and a namespace-resolution mechanism are therefore infrastructure functions. They support the resolution of persistent Record identity to current technical information without making the Record identical to a resolver, repository, URL, or endpoint.
 
+Beyond the mandatory Record endpoint, a DID Document can declare optional service entries, for example a restricted view of a Record or a list of the functions supported for it (see [[RWP]]). Such entries describe the technical availability of access channels. They do not grant access, which is decided at the governance level, and they are not part of the integrity evidence of a Record.
+
 
 ### Information Package and Representation ### {#subsection-rwra-information-representation}
 
@@ -265,7 +267,7 @@ Relevant mechanisms include:
 
 These mechanisms answer different questions and should not be conflated.
 
-A Record validation result concerns whether a specific Record or snapshot satisfies applicable requirements. An implementation assessment concerns whether an identified implementation version fulfils the requirements of claimed RWP profiles and roles. An attestation is a signed statement by an identifiable attester about such an assessment. Certification is an institutional process that remains outside the RWP base protocol.
+A Record validation result concerns whether a specific Record or version satisfies applicable requirements. An implementation assessment concerns whether an identified implementation version fulfils the requirements of claimed RWP profiles and roles. An attestation is a signed statement by an identifiable attester about such an assessment. Certification is an institutional process that remains outside the RWP base protocol.
 
 A ConformanceRecord is a RecordWeb SystemRecord that can preserve a durable, machine-readable conformance attestation. Its presence does not by itself establish that a claim is true, independently assessed, or certified. A verifier evaluates the identity of the attester, the claimed scope, the assessment method, the evidence, and the applicable trust policy.
 
@@ -279,7 +281,7 @@ Possible publication mechanisms include:
 - an organisational website or service endpoint;
 - a procurement or audit evidence repository;
 - an institutional registry;
-- a DID-related service endpoint;
+- a service entry in a DID Document (see [[RWP]]);
 - a signed Nanopublication; or
 - direct provision to an auditor, procuring organisation, or other verifier.
 
@@ -312,7 +314,7 @@ RWP primarily specifies the Record and Evidence layer. It also defines selected
     </tr>
     <tr>
       <td>DID and DID resolution</td>
-      <td>Connect persistent identity in the Record and Evidence layer with technical resolution and infrastructure functions in the Carrier and Infrastructure layer.</td>
+      <td>Connect persistent identity in the Record and Evidence layer with technical resolution and infrastructure functions in the Carrier and Infrastructure layer. They can also carry optional service entries that declare additional access channels and, derived from SchemaRecords, the functions supported for a Record.</td>
     </tr>
     <tr>
       <td>Global Namespace Registry and DID Resolver</td>

chapters/roadmap.bs

@@ -19,12 +19,15 @@ A concrete pilot use case is needed: a real [=Case=] from a public authority, mo
 
 RecordWeb has the potential to contribute to international standardisation processes. This path is long. It begins with the concept, proceeds through the specification, and is validated through implementations.
 
+
 ## Open Questions ## {#open-questions}
 
 The following questions are explicitly offered for community contribution:
 
 **Access control**: RecordWeb deliberately defines no authorisation model. Data security and information protection are delegated to the implementing systems. The specification provides an optional `accessPolicy` block in the minimum metadata set.
 
+**Capability discovery**: RWP offers optional service entries in the DID Document and capability declarations in SchemaRecords, so that a party, including an automated agent, can learn from resolution alone which access channels and functions exist for a Record [[DIDCOMM-DISCOVER-FEATURES]]. Open questions are how rich such declarations should be (for example with input and output descriptions), whether declared capabilities should become binding for resolvers, and how details are negotiated at runtime once a channel exists. The Discover Features protocol of DIDComm Messaging [[DIDCOMM-MESSAGING]] is a related mechanism for the last point. It works only after a connection is established, is best effort, and describes protocol support between agents rather than operations on a specific Record. It therefore complements, but does not replace, declaration at resolution time.
+
 **Federation**: RecordWeb offers a directional answer inspired by DNS architecture. DID resolvers function like DNS servers: federated, replicated, without a single point of failure. The Nanopublication network [[NANOPUB]] offers a working reference model: a decentralised peer-to-peer server network in which each node holds cryptographically signed, immutable micro-assertions identified by Trusty URIs. RecordWeb [=Records=] in their finalised state share the same structural properties (immutable, hash-identified, independently verifiable) and could be published and queried across a Nanopub-inspired federation layer. The complete federation architecture is the subject of [[RWP]].
 
 **Deletion obligations**: The tension between RecordWeb's immutability and the data protection right to erasure (GDPR, Swiss DSG) is resolved through *payload deletion while retaining structure*. On a legal requirement, the payload is deleted; the DID, the [=metadata=], and the graph structure are retained. The [=Record=] continues to exist as a provable "empty shell", its former existence is documented, its content is gone.
@@ -46,6 +49,7 @@ The applicable mode is declared in the `deletionRegime` field of the [=Record=]'
 
 **Platform adoption**: The actual adoption task lies not with the end user, but with the platform providers: Microsoft, Google, SAP, and others must integrate RWP as a native layer into their products.
 
+
 ## An Invitation ## {#invitation}
 
 RecordWeb is a thesis, not a doctrine. It is an invitation to think together about the foundations of institutional information architecture, and in doing so, to question old assumptions.

chapters/source-integration.bs

@@ -3,7 +3,7 @@ Source Integration: From Domain Content to a Record {#chapter-sourceintegration}
 
 A Source Application remains responsible for the domain object that it creates, manages, or interprets. A conversation in a collaboration platform, a case in a specialist application, or a document in a business system remains a source object in that application's domain. RecordWeb does not require such a system to adopt RWP's identity, versioning, or storage model.
 
-A source-adapter can expose content and provenance from such a source object to an RWP producer. The source-adapter does not thereby need to implement the RWP DID method, snapshot graph, storage model, or Case model. The form of the exchange is a matter for the participating implementations: it may be an API, an event, a file transfer, a queue, or another agreed mechanism. This exchange mechanism is deliberately outside the scope of [[RWP]] and is not expected to be standardised by a future protocol version without a dedicated specification effort.
+A source-adapter can expose content and provenance from such a source object to an RWP producer. The source-adapter does not thereby need to implement the RWP DID method, version graph, storage model, or Case model. The form of the exchange is a matter for the participating implementations: it may be an API, an event, a file transfer, a queue, or another agreed mechanism. This exchange mechanism is deliberately outside the scope of [[RWP]] and is not expected to be standardised by a future protocol version without a dedicated specification effort.
 
 The boundary of RWP responsibility is the producer that creates the RWP representation. From that point, the information becomes a Record only when it has received an RWP identity, has been associated with an applicable schema, and has been created and, where applicable, finalised according to the RWP rules. The producer, and not the source application merely providing content, is accountable for the resulting RWP Record.
 
@@ -36,11 +36,11 @@ ChatAdapter
   ▼
 SoX
   │ applies its own applicable RWP production and finalization process
-  │ creates and retains the resulting RWP snapshots
+  │ creates and retains the resulting RWP versions
   ▼
 RWP-compliant system
   │ resolves the Record DID
-  │ verifies a finalized snapshot and snapshotHash
+  │ verifies a finalized version and versionHash
   ▼
 CaseRecord hard link
 ```

chapters/the-record.bs

@@ -11,7 +11,8 @@ A single database field is not a Record. An email attachment is not a Record. A
 
 A [=Record=], by contrast, is: a decision of a public authority; an application submitted by a citizen; minutes of a meeting; an expert opinion; a contract. Each of these objects carries its meaning within itself.
 
-## Conceptual Taxonomy of Records {#section-record-taxonomy}
+
+## Conceptual Taxonomy of Records ## {#section-record-taxonomy}
 
 For the purposes of the RecordWeb conceptual model, [=Record|Records=] can be distinguished by their primary purpose:
 
@@ -38,10 +39,13 @@ Every [=Record=] in RecordWeb consists of three inseparable components: its <dfn
 
 **[=Metadata=]** are the dimensions along which a [=Record=] can be found, linked, and classified. They describe the [=Record=] from the outside without needing to know its content. The minimum set is deliberately kept small: type, timestamp, responsible parties, state, provenance references, classification, and a free tag field.
 
+
 ## Type and Schema: The Record's Contract ## {#record-type-schema}
 
 Every [=Record=] has a type. And every type has a schema. A [=Record=]'s type is not merely a label, it is a statement about which rules apply to this [=Record=]. In RecordWeb, a schema is itself a [=Record=]: a SchemaRecord with its own type, its own [=version graph=], and its own history. This guarantees backward compatibility structurally: every version of a [=Record=] remains permanently linked to the schema version that was valid at the time of its creation.
 
+A SchemaRecord can also declare which functions apply to Records of its type, for example retrieving, comparing, validating or publishing. This declaration is descriptive: it states what a Record type supports, not who may use it. Keeping it at the type level means it is governed, versioned and auditable once, instead of being repeated in every Record.
+
 
 ## States: The Liveliness of the Record ## {#section-record-states}
 
@@ -66,12 +70,12 @@ RecordWeb does not prescribe a mandatory lifecycle for Records. A Record remains
 
 Nevertheless, organisations may apply an established records lifecycle where this supports their operational, governance, archival, or legal requirements. In particular, a progression from a **System of Work (SoW)** to a **System of Record (SoR)** and subsequently to a **System of Archive (SoA)** remains possible within the RecordWeb approach.
 
-The transition between lifecycle stages does not require creating a new Record or discarding information about its previous context. Instead, the organisation transfers the Records digital representation to the appropriate target system and updates the Records DID Document accordingly.
+The transition between lifecycle stages does not require creating a new Record or discarding information about its previous context. Instead, the organisation transfers the Record's digital representation to the appropriate target system and updates the Record's DID Document accordingly.
 
 A lifecycle transition therefore consists principally of two coordinated activities:
 
 1. The Record, including the relevant content and associated representations, is physically transferred and made available in the target system.
-2. The DID Document is updated to reflect the current location, service endpoint, access method, or other technical information required to retrieve or interact with the Record in its new environment.
+2. The DID Document is updated to reflect the current location (the Record endpoint) and, where used, optional service entries that describe further access channels or other technical information required to retrieve or interact with the Record in its new environment.
 
 The DID Document may retain references to previous locations, services, or lifecycle events where this is required for traceability, auditability, or preservation purposes. This allows an organisation to document that a Record was previously managed in a SoW or SoR while making its authoritative representation available from a SoR or SoA.  This is not currently part of RWP; the [DID document](https://recordweb.github.io/rwp/#did-document) can be supplemented according the organisations requirements.
 

index.bs

@@ -15,7 +15,7 @@ Previous Version: https://doi.org/10.5281/zenodo.20475343
 </pre>
 
 <div class="copyright">
-<p>Copyright © 2026 the Contributors to the RecordWeb Concept (RWC) v0.0.8, published by the <a href="https://www.w3.org/community/recordweb/">RecordWeb Community Group</a> under the <a href="https://www.w3.org/community/about/process/cla/">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/process/cla-deed/">summary</a> is available.</p>
+<p>Copyright © 2026 the Contributors to the RecordWeb Concept (RWC) v0.0.9, published by the <a href="https://www.w3.org/community/recordweb/">RecordWeb Community Group</a> under the <a href="https://www.w3.org/community/about/process/cla/">W3C Community Contributor License Agreement (CLA)</a>. A human-readable <a href="https://www.w3.org/community/about/process/cla-deed/">summary</a> is available.</p>
 </div>
 
 <pre class="biblio">
@@ -26,6 +26,16 @@ Previous Version: https://doi.org/10.5281/zenodo.20475343
       "href": "https://www.w3.org/History/1989/proposal.html",
       "date": "1989"
   },
+  "DIDCOMM-MESSAGING": {
+      "title": "DIDComm Messaging v2.1",
+      "href": "https://identity.foundation/didcomm-messaging/spec/v2.1/",
+      "publisher": "Decentralized Identity Foundation"
+  },
+  "DIDCOMM-DISCOVER-FEATURES": {
+      "title": "Discover Features Protocol 2.0",
+      "href": "https://didcomm.org/discover-features/2.0/",
+      "publisher": "DIDComm"
+  },
   "DID-CORE": {
       "title": "Decentralized Identifiers (DIDs) v1.0",
       "href": "https://www.w3.org/TR/did-core/",
@@ -168,6 +178,9 @@ Annex A: Glossary {#glossary}
   <dt>Branch</dt>
   <dd>A parallel development line within the [=version graph=] of a [=Record=]. From one finalised version, two or more simultaneously existing drafts arise. Branches are transparently visible; their consolidation is effected through an explicit merge act.</dd>
 
+  <dt>Capability</dt>
+  <dd>A function or operation, such as retrieve, compare, validate or publish, that a SchemaRecord declares as applicable to Records of its type. A capability declaration is descriptive and does not grant access.</dd>
+
   <dt>Case</dt>
   <dd>A specialised Record type that represents a persisted, governed view of linked [=Records=]. A [=Case=] makes [=Records=] belonging to a business transaction visible according to a defined schema, without becoming a container for those [=Records=]. It follows the same rules as any other [=Record=]: DID, states, [=version graph=], [=finalisation=].</dd>
 
@@ -205,6 +218,9 @@ Annex A: Glossary {#glossary}
   <dd>The smallest semantically autonomous unit of information in RecordWeb. A [=Record=] consists of [=identity=] (DID), [=payload=], and [=metadata=]. It has a type that determines its schema, and a state that controls its linkability. It exists
   within a [=version graph=] and is permanently identifiable regardless of system boundaries.</dd>
 
+  <dt>Service entry</dt>
+  <dd>An optional entry in the service property of a Record's DID Document, as defined in [[DID-CORE]], declaring an additional access channel beyond the mandatory Record endpoint. A service entry declares availability, not authorisation.</dd>
+
   <dt>State transition</dt>
   <dd>A change of the state of a [=Record=], for example from [=draft=] to [=finalized=]. In RecordWeb, "archiving" is a [=state transition=], not a system migration.</dd>
 
@@ -239,8 +255,15 @@ Annex B: Relationship to Existing Standards {#annex-standards}
     </tr>
     <tr>
       <td>[[DID-CORE]]</td>
-      <td>RecordWeb uses DIDs as the basis for [=Record=] [=identity=] and is fully compatible with the W3C DID standard.</td>
+      <td>RecordWeb uses DIDs as the basis for [=Record=] [=identity=] and is fully compatible with the W3C DID standard and uses its service property for optional access channels.</td>
     </tr>
+    <tr>
+      <td>[[DIDCOMM-MESSAGING]]</td>
+      <td>TBD by RecordWeb CG</td>
+    </tr>
+    <tr>
+      <td>[[DIDCOMM-DISCOVER-FEATURES]]</td>
+      <td>Complementary. A DIDComm channel can be declared as a service entry; Discover Features can negotiate protocol details at runtime once a connection exists. It does not replace declaration at resolution time.</td>
     <tr>
       <td>[[PROVO]]</td>
       <td>PROV-O would be used as serialisation format for RecordWeb lineage documentation to establish interoperability with PROV-O-compatible systems.</td>