RecordWeb · Auffindbarkeit über Veränderungen hinweg

Wo ist dieser Record?

Der Name bleibt. Der Ort kann wechseln.

Nicht den alten Ort suchen.
Den stabilen Namen auflösen.

Teil 1 · Die Geschichte einer Suche

Frau Berger sucht eine Antwort, die sie früher einmal gefunden hat.

Einige Jahre nach der Fragestunde möchte die Journalistin Frau Berger nochmals auf die damalige Antwort zur Entwicklung des CO₂-Ausstosses verweisen.

Sie hat einen alten Link gespeichert. Sie klickt darauf.

FB

Frau BergerJournalistin · spätere Nutzerin

„Ich weiss, dass es diese Antwort gibt. Aber wo finde ich sie heute?“

Szene 1 · Der alte Ort

Der gespeicherte Link führt ins Leere.

https://altes-fachsystem.example.gov/antworten/co2-2026

404Seite nicht gefundenDie Anwendung wurde abgelöst. Die frühere Web-Adresse existiert nicht mehr.

Die Information kann noch existieren. Doch ihre frühere Adresse beschreibt einen Ort, der sich verändert hat – Server, Domain, Anwendung oder Verantwortungsbereich.

Szene 2 · Name und Ort trennen

Eine URL ist eine Adresse. Eine DID ist ein stabiler Bezugspunkt.

Web-Adresse

Enthält Domain, Server und Pfad
Beschreibt, wo etwas heute abrufbar ist
Muss bei System-, Domain- oder Strukturwechsel aktiv nachgeführt werden
Kann bei fehlender Pflege zur 404-Seite führen

RecordWeb-DID

Benennnt genau diesen Record
Enthält keinen aktuellen Server und keine Domain
Wird über eine Registry und Resolver aufgelöst
Kann beim Ortswechsel zum aktuellen Endpoint führen

Der Name sagt: „Das ist dieser Record.“
Die Auflösung findet heraus: „Wo wird er heute bereitgestellt?“

Szene 3 · Der stabile Name

Die DID benennt den Record – ohne über ihn zu spekulieren.

did:rwp:b7d4c810:2fe14680-575a-4da4-aa65-6e72e0866e9b

did:rwp

Die Kennzeichnung: Dieser Identifier folgt dem RecordWeb-Verfahren.

b7d4c810

Opaquer Namespace. Er führt zur zuständigen Auflösungsinformation.

2fe14680-575a-4da4-aa65-6e72e0866e9b

Opaque und technisch eindeutige Zeichenfolge (uuid). Sie verrät weder Thema, RecordType, Organisation noch aktuellen Ort.

Szene 4 · Warum die Kennung nicht spricht

Ein stabiler Name soll keine veränderliche Annahme enthalten.

Ein sprechender Name würde festschreiben

welche Organisation zuständig ist
welches Thema oder welche Klassifikation gilt
welcher RecordType erwartet wird
welche Sprache, Struktur oder Domäne verwendet wird

Eine opaque Kennung sagt nur

dies ist genau dieser Record
der Ort kann später wechseln
die Zuständigkeit kann übergehen
Typ und Kontext werden aus dem Record selbst ermittelt

Opaque bedeutet nicht geheim. Es bedeutet: Der dauerhafte Name bleibt neutral gegenüber Veränderungen.

Szene 5 · Der Namespace als Auflösungsraum

Der Namespace beantwortet nicht „Was ist das?“, sondern „Wer weiss, wie es aufzulösen ist?“

Ein Namespace bündelt eine Zuordnung zu einem Resolver. Wie fein oder grob er geschnitten wird, ist eine Organisations- und Governance-Entscheidung, keine Vorgabe des Protokolls.

Gestaltung des Namespace	Mögliche Stärke	Mögliche Folge
Pro Organisation	Einfacher Einstieg, wenige Zuständigkeiten	Veränderungen können einen grossen Bereich betreffen
Pro Anwendung	Klare technische Betriebsgrenze	Mehr Namespaces und mehr Übergänge bei EoL
Pro Fach- oder Verantwortungsbereich	Kann stabilen Aufgaben und Custody-Strukturen folgen	Erfordert klare fachliche Governance
Feingranulare Custody-Bereiche	Gezielte und kleinere custodyTransfers möglich	Mehr Verwaltungs- und Entscheidungsaufwand

Szene 6 · Ein etabliertes Prinzip

Ein Resolver ist ein Wegweiser.

Viele Menschen kennen das Prinzip vom DNS: Ein Name wird aufgelöst, damit ein technisches Ziel gefunden werden kann.

RecordWeb folgt derselben Grundidee mit einem zusätzlichen Schritt: Der Resolver liefert nicht nur eine technische Adresse, sondern ein DID-Dokument mit dem aktuellen RecordEndpoint und weiteren Angaben zum Record.

?

Resolverfindet den zuständigen Weg zum Record

Einfaches Bild: DNS hilft, einen Domainnamen zu finden. Ein RecordWeb-Resolver hilft, einen Record über seine DID und seinen Namespace zu finden.

Teil 2 · Der technische Auflösungsweg

Der RecordFinder zeigt die Auflösung in vier Schritten.

Eine Anwendung führt eine DID über die Namespace-Registry zum zuständigen Resolver. Dieser liefert das DID-Dokument; dessen Endpoint liefert den Record.

1. Input DIDFrau Berger oder ein Client gibt die DID ein.

→

2. Root ResolverDie Namespace-Registry findet den Resolver für b7d4c810.

→

3. DID-DokumentDer Namespace-Resolver liefert Endpoint, Version und Controller.

→

4. RecordDer RecordEndpoint liefert den verantworteten Record.

Technischer Nachweis · Schritte 1–2

Aus der DID wird der Namespace. Die Root-Registry findet seinen Resolver.

RecordFinder · AuflösungswegRoot-Resolver-Chaincode

1 · inputDid
inputDid
did:rwp:b7d4c810:2fe14680-575a-4da4-aa65-6e72e0866e9b

extractedNamespace
b7d4c810

2 · Root-Resolver-Chaincode
namespace-registry · ResolveNamespace

namespace
b7d4c810

resolverEndpoint
https://vps.recordweb.dev/antwortmanagement/did

registeredBy
CH

registeredAt
2026-08-25T12:51:01Z

endorsedBy
["CH", "RecordWeb.org"]

Im PoC-Fragestunde: Die Root-Registry liefert für den Namespace b7d4c810 den zuständigen Resolver. Der RecordFinder erhält damit nicht den Record selbst, sondern zunächst den verlässlichen Weg zu dessen DID-Dokument.

Technischer Nachweis · Schritt 3

Der Namespace-Resolver liefert das DID-Dokument.

Das DID-Dokument enthält die aktuelle Information, wo der Record bereitgestellt wird, sowie Angaben, die seine Einordnung und Prüfung unterstützen.

DID-Dokument · bereinigter Auszugantwortmanagement/did

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:rwp:b7d4c810:2fe14680-575a-4da4-aa65-6e72e0866e9b",
  "recordEndpoint": "https://vps.recordweb.dev/antwortmanagement/api/records/did%3Arwp%3Ab7d4c810%3A…",
  "created": "2026-08-25T14:08:03.956Z",
  "updated": "2026-08-25T14:14:32.702Z",
  "currentVersion": "sha256:0661762b2d678e3e0699accfb00d7f227…",
  "controller": "did:rwp:b7d4c810:users/daniel-wyss"
}

Wichtig: Die DID bleibt der Bezugspunkt. Der recordEndpoint ist die aktuelle, veränderbare Adresse, die der Resolver ausliefert.

Technischer Nachweis · Schritt 4

Der RecordEndpoint liefert den Record und der Record erklärt seinen Typ.

Record · bereinigter AuszugAntwortmanagement

{
  "did": "did:rwp:b7d4c810:2fe14680-575a-4da4-aa65-6e72e0866e9b",
  "record_type": "did:rwp:b7d4c810:schema:fragestunde-antwort",
  "owner": "did:rwp:b7d4c810:users/daniel-wyss",
  "state": "finalized",
  "schema_version": "sha256:b03e4ff45a36431a70a7b08085b8f916…",
  "snapshot_hash": "sha256:0661762b2d678e3e0699accfb00d7f227…",
  "payload": {
    "antworttext": "Ich weiss noch nicht",
    "bundesrat_did": "did:rwp:b7d4c810:users/daniel-wyss",
    "beantwortet_am": "2026-08-25T14:08:03.938Z"
  },
  "finalized": "2026-08-25T14:14:32.701Z"
    }

Die DID muss keinen Typ verraten. Der record_type im abgerufenen Record macht sichtbar, um welche Art von Record es sich handelt. Status, Eigentümerschaft, Schema- und Fassungsbezug können ebenfalls geprüft werden.

Technischer Nachweis · Wenn der Ort wechselt

Beim custodyTransfer ändert sich der Endpoint, nicht die Identität.

Alte AnwendungStellt den Record heute über ihren Endpoint bereit.

→

custodyTransferDie Verantwortung und Bereitstellung gehen kontrolliert weiter.

→

Nachfolgeanwendung oder AISStellt denselben Record über einen neuen zuständigen Endpoint bereit.

Frau Berger muss keinen neuen Link lernen. Sie löst dieselbe DID erneut auf und erhält den aktuellen Weg zum Record.

Technischer Nachweis · Die gemeinsame Basis

Wer entscheidet, welcher Resolver für einen Namespace zuständig ist?

Namespaceb7d4c810Ein Client kennt den Namespace aus der DID, aber noch nicht den Resolver.

gemeinsam
geführte
Registry

Root ResolverDie Namespace-Registry ordnet Namespace und ResolverEndpoint nachvollziehbar zu.Im Testnet: Chaincode namespace-registry mit ResolveNamespace.

PoC/Testnet: Die Namespace-Registry wird in einem Hyperledger-Fabric-2.5-Testnetz erprobt. Sie ist Lern- und Entwicklungsplattform, kein Produktivbetrieb.

Technischer Anhang · Langfristige Governance

Eine weltweit auflösbare Registry braucht langfristig getragene Verantwortung.

Heute: PoC-Testnetz

Hyperledger Fabric 2.5 als permissioned Blockchain. Das Testnetz enthält 3 Muster-Organisationen sowie einen Channel root-resolver.

Es demonstriert die technische und organisatorische Idee der mehrseitig bestätigten Namespace-Registrierung.

Diskussionsbild für später

Eine internationale RecordWeb-Trägerorganisation könnte Spezifikation, Governance und den anfänglichen Betrieb der Root-Registry verantworten.

Mitgliedsbehörden könnten schrittweise Infrastruktur und Mitverantwortung übernehmen, sodass Betrieb und Governance zunehmend föderiert werden.

Einordnung: Das rechte Bild ist eine Entwicklungshypothese, keine bereits bestehende Organisation oder produktive Betriebszusage.

Technischer Anhang · Ein möglicher Entwicklungspfad

Von einem Startbetrieb zu einer föderierten Vertrauensbasis.

1Start

Eine Trägerorganisation etabliert Spezifikation, Policies und einen ersten Registry-Betrieb.

2Teilnahme

Landes- oder Sektorbehörden treten bei und bringen Anforderungen, Legitimation und Governance ein.

3Verteilung

Mitglieder können Infrastruktur mittragen; die Registry wird technisch und organisatorisch robuster.

4Reife

Die Trägerorganisation konzentriert sich zunehmend auf Spezifikation, Interoperabilität und Governance.

Die Blockchain ist nicht die Geschichte. Sie ist ein möglicher Mechanismus, damit die Zuordnung Namespace → Resolver nicht von einer einzelnen, wechselnden Website abhängt.

RecordWeb · DID und Auflösung

Ein Record bleibt auffindbar,
auch wenn sein Ort sich verändert.

Die DID benennt den Record. Der Namespace führt zum zuständigen Resolver. Das DID-Dokument liefert den aktuellen Endpoint. Und eine gemeinsam getragene Registry macht den ersten Schritt langfristig nachvollziehbar.