Zusammenfassung

  • Der vorgeschlagene Pfad /.well-known/knowledge-linkset kann Wissensartefakte typisiert auffindbar machen und optional per Digest binden; ein fehlender Digest bedeutet jedoch nur, dass diese Prüfung nicht stattgefunden hat.
  • Systeme müssen Integrität, Herkunft, Herausgebervertrauen, Inhaltsbewertung und Handlungsbefugnis getrennt ausweisen, statt sie in einen einzigen Vertrauensstatus zu pressen.

Das Dashboard markierte den Eintrag rot. Nicht weil die Bytes abwichen, sondern weil der Herausgeber gar keinen Digest angegeben hatte. Ein zweites System markierte denselben Eintrag grün, weil kein Fehler berechnet werden konnte. Beide Anzeigen waren bequem. Beide erfanden eine Aussage, die aus dem fehlenden Wert nicht folgte.

Genau diese Lücke zwischen Protokolldaten und Betriebsurteil wird relevant, wenn The 'knowledge-linkset' Well-Known URI for Publishing Knowledge Artefacts umgesetzt wird. Paul Besleaga reichte Revision 00 am 30. September 2026 ein. Der Entwurf sieht unter /.well-known/knowledge-linkset ein JSON-Dokument vor, mit dem eine Origin typisierte Verweise auf Kontext, Graphen, Ontologien, Fähigkeiten, aktuelle Zustände, Ledger, Oberflächen, Mitarbeit und Peers veröffentlichen kann.

Es handelt sich derzeit um einen aktiven Individual Draft mit angestrebtem Informational-Status. Es gibt keine zuständige Arbeitsgruppe, keinen verantwortlichen Area Director und keine formale IETF-Position. Der gewünschte Well-known-Name ist vorläufig; die Profil-URI hat einen separaten Registrierungspfad. Diese Einordnung ist wichtig, weil das Auffinden über eine IETF-beschriebene Konvention weder den Entwurf noch die verlinkten Inhalte zu IETF-geprüften Aussagen macht.

Drei Integritätszustände statt eines Ampellichts

RFC 8615 schafft einen vorhersehbaren Ort unter einer Origin. RFC 8288 und RFC 9264 liefern Modelle für Links und Linksets. Der Entwurf spezialisiert diese Bausteine für Wissensartefakte. Für eine Maschine entsteht damit eine geordnete Startseite, keine universelle Vertrauenswurzel.

Digests können die Aussage präzisieren. RFC 9530 und RFC 9651 beschreiben moderne HTTP-Content-Digests. Ein Profil kann zusätzlich eine kanonische Darstellung festlegen, etwa für JSON nach RFC 8785. Stimmen erwarteter und berechneter Wert überein, hat der Client die bezeichnete Repräsentation erhalten. Weichen sie ab, darf er diese Repräsentation nicht akzeptieren.

Fehlt der Wert, ist keine dieser beiden Aussagen möglich. Das Artefakt ist durch diesen Mechanismus ungeprüft. Je nach Anwendungsfall kann die lokale Richtlinie es zulassen, isolieren, einer anderen Prüfung zuführen oder ablehnen. Die Entscheidung gehört der Anwendung; das Protokoll sollte den fehlenden Beleg nicht in einen positiven oder negativen Beweis umdeuten.

Auch der Umfang des Digests muss eindeutig sein. Übertragene Bytes, dekomprimierter Inhalt und kanonisiertes Objekt können verschiedene Werte liefern. Content Negotiation und legitime Transformationen erzeugen Varianten. Ein Profil muss festlegen, welche Repräsentation gebunden wird und wie Medienart, Kodierung und Canonicalization zusammenspielen.

Selbst eine Übereinstimmung bleibt schmal. Sie beweist weder Wahrheit noch Sicherheit, Lizenz, Aktualität oder Autorenschaft. Kontrolliert ein Angreifer sowohl Karte als auch Ziel, kann er beide austauschen und einen gültigen neuen Digest veröffentlichen. TLS und DNS helfen festzustellen, welche Origin antwortete. Origin-Kontrolle ist aber nicht zwingend redaktionelle Identität; Shared Hosting, Dienstleister, Übernahmen und kompromittierte Konten trennen beides.

Signatur, Herausgeber und Mandat

HTTP Message Signatures nach RFC 9421 können ausgewählte Nachrichtenkomponenten kryptografisch an einen Schlüssel binden. Das verbessert die Zuschreibung, wenn Schlüsselverwaltung und abgedeckte Felder sauber geregelt sind. Danach beginnen die Governance-Fragen: Wem gehört der Schlüssel? Für welche Artefaktklasse gilt er? Zu welchem Zeitpunkt? Darf der Unterzeichner nur veröffentlichen oder auch eine Produktionshandlung anfordern?

Ein gültiger Schlüssel ersetzt keine Capability-Policy. Ein Agent darf einen signierten Text zusammenfassen, ohne dessen Imperative auszuführen. Relationsnamen wie skills, contribute oder now klassifizieren Links; sie machen den Zieltext nicht zum privilegierten Anweisungskanal. Aufforderungen, Geheimnisse zu senden, Schutzregeln zu ignorieren oder Systeme zu ändern, bleiben fremde Daten.

Eine robuste Architektur trägt Provenienz strukturiert mit: Start- und End-URL, Redirect-Kette, tatsächlich verbundene Adresse, Medientyp, Relation, Manifestversion, Abrufzeit, Digestzustand und Vertrauensentscheidung. Die Ausführungsschicht erhält einen separaten Capability-Antrag mit Subjekt, Mandant, Ressource, Dauer und Policy-Version. Werden lokale Regeln und fremde Prosa in einem flachen Prompt vermischt, ist die Grenze schon vor der Prüfung verloren.

Der Crawler braucht Netzgrenzen

Jeder Link kann einen Request auslösen. Peers und Redirects schaffen deshalb eine SSRF-Fläche. Ein Hostname kann zunächst öffentlich auflösen und im Verbindungszeitpunkt per DNS Rebinding auf Loopback, private Netze, Link-local oder Metadatendienste zeigen. Ungewöhnliche URL-Schreibweisen können schwache Filter umgehen.

Clients sollten URLs vor der Policy-Auswertung parsen und normalisieren, nur vorgesehene Schemes zulassen, mehrdeutige Userinfo ablehnen und kontrollierte Resolver verwenden. Alle aufgelösten Adressen sowie die tatsächlich verbundene Adresse müssen klassifiziert werden. Nach jedem Redirect und jeder neuen Auflösung ist die Prüfung zu wiederholen. Redirectzahl, Schemes und Origin-Wechsel brauchen Grenzen und Protokollierung.

Peer-Graphen benötigen Budgets für Tiefe, Knoten, Bytes, Zeit, Parallelität und Requests pro Origin. Zyklen sind über normalisierte Kennungen zu erkennen. Ist das Budget verbraucht, lautet das Ergebnis „in diesem begrenzten Lauf nicht gefunden“. Es ist kein globaler Abwesenheitsbeweis. Ebenso kann eine öffentliche Ansicht absichtlich weniger enthalten als eine authentisierte.

Cache und Nachfolge ändern die Beweisart

RFC 9111, ETag und 304 Not Modified machen Wiederverwendung effizient. Ein 304 bestätigt den Validator des Servers, nicht erneut Autor, Lizenz oder Mandat. Sensible Entscheidungen sollten das verwendete Manifest, Cachealter, Validator und die Policy-Version bewahren. Sonst kann ein gecachtes Ziel weiterwirken, obwohl die Relation entfernt oder der Herausgeber widerrufen wurde.

Tombstones können das Ende eines Knotens markieren und einen Nachfolger nennen. Der Verweis überträgt keine Identität, Verwahrung, Lizenz oder Vertrauensstufe. Der Client hält alte Kennung und Endstatus fest, protokolliert die Nachfolgebehauptung und bewertet den neuen Knoten neu.

Ledger und Current-Pointer liefern zeitliche Evidenz. Ein gemerkter früherer Head kann Rollback oder Ersatz sichtbar machen. Bei konkurrierenden Historien entscheidet das Ledger nicht selbst, welche legitim ist. Dafür braucht es externe Regeln: benannte Autorität, Quorum, unabhängiges Archiv oder Recovery-Verfahren.

Auch die Karte selbst kann Informationen preisgeben. Geschützte Ziele bleiben zwar unlesbar, doch Namen, Existenz, Medientyp, Änderungsrhythmus und Digests können öffentlich werden. Stabile Digests ermöglichen mitunter die Bestätigung eines vermuteten Dokuments. Betreiber brauchen reduzierte öffentliche und umfassendere authentisierte Ansichten sowie die Möglichkeit, sensible Metadaten wegzulassen. Eine reduzierte Ansicht darf nicht als vollständiges Inventar gelten.

Im Ausgangsfall hätte ein gutes System weder rot noch grün gezeigt. Es hätte „Digest nicht vorhanden“ ausgewiesen und die anwendungsspezifische Folge separat erklärt. Diese Genauigkeit wirkt unspektakulär, verhindert aber, dass ein fehlendes Feld zur erfundenen Gewissheit wird.

knowledge-linkset kann Auffindbarkeit und überprüfbare Repräsentationen verbinden. Sein Nutzen wächst, wenn die Zustände nicht verschmolzen werden: entdeckt, abgerufen, bytegeprüft, signiert, vertraut, autorisiert. Nur dann bleibt sichtbar, welcher Beleg wirklich vorliegt und welche Entscheidung noch aussteht.

Sources