Zusammenfassung

  • draft-templeman-scitt-measurement-capsule-00 speichert Erklärung, Fremdbeobachtung, strukturierte Differenz, Evidence-Digests und Grenzen, ohne Ausführungsgewalt zu verleihen.
  • UNCHECKABLE ist weder Fehler noch Erfolg, Null oder Abwesenheit. Ein unvollständiger Read darf keine vollständige Negativaussage erzeugen.
  • Content-ID, Merkle-Einbindung, Signatur, Transparency Receipt und Zeitanker belegen unterschiedliche Schritte. Eine Sperre braucht einen eigenen Principal, eine Policy und ein anfechtbares Decision Record.

Ein Prüfer sieht elf Werkzeuge, der Server hatte zwölf angekündigt. Die Kapsel ist kanonisch serialisiert, signiert und in einem Batch enthalten. Der Unterschied ist echt. Die Schlussfolgerung „Server sperren“ steht trotzdem in keinem dieser Belege.

Genau diese Lücke behandelt Declared-versus-Observed Measurement Capsules. Am 2. Oktober 2026 führte Datatracker Revision 00 als aktive Individual Submission, eingereicht am 27. September und gültig bis 31. März 2027. Der Text zielt auf Experimental, ohne IETF stream oder verantwortlichen Area Director. Er ist kein RFC, Konsens, Working-Group-Adoption oder Betriebsnachweis.

Die Kapsel stammt von einem Measurer, der weder Subject noch Teilnehmer der betreffenden Action sein soll. Sie hält declared bytes, observed data, differential, source digests, measurement state, Zeitpunkt und limitations fest. authority_state kennt nur „measurement only“.

Beide Seiten der Differenz brauchen Herkunft

Eine Declaration ist ein abgerufenes Artefakt mit Version, Ort, Zeitpunkt, Medientyp und Digest. Registry, Cache und Manifest können verschiedene Stände zeigen.

Eine Observation hängt von vantage, credential, request, timeout, parser und clock ab. Live protocol, ledger proof, signature verification und rerun sind unterschiedliche Methoden. Ein Ergebnis von einem Ort zu einer Zeit ist keine globale Sicht.

INCONSISTENT besagt daher nur, dass zwei Statements unter der definierten comparison abweichen. Es bestimmt weder Wahrheit noch Absicht oder Verantwortlichkeit. Auch die Evidence Ladder bleibt eng: ein Proof gegen einen Block-Header-Commitment validiert nicht automatisch den Header gegen Consensus; eine Operator API bleibt eine Operator-Aussage.

UNCHECKABLE bewahrt den Nenner

Bei abgebrochener Pagination, fehlender Permission, Identity-Fehler oder nicht prüfbarem Proof lautet der Zustand UNCHECKABLE. Er darf nicht zu Pass, Fail, Null oder Auslassung werden. NOT_LISTED setzt einen vollständigen Read voraus.

Wer unlesbare Zeilen entfernt, verbessert die Quote; wer sie zu Null macht, verschlechtert sie. Beides ist keine Messung. Eligible, attempted, complete und uncheckable müssen getrennt bleiben.

Auch die Batch-Auswahl kann verzerren. Der Issuer kann Subjects wählen, die wahrscheinlich abweichen. Deshalb soll der Batch Record inclusion rule und Ausschlüsse nach Grund offenlegen. Counts aus verschieden ausgewählten Batches sind nicht direkt vergleichbar.

Das Verbot von Entscheidungsfeldern macht den Entscheider sichtbar

Außer authority_state verbietet der Entwurf Feldnamen wie decision, allow, reject, approve, admit, authority, permit, enforcement, action oder gate sowie mehrere exakte Ergebniswerte. Eine Capsule soll nicht als Gate konsumiert werden.

Die Denylist ist unvollständig; der Text nennt per-kind Allowlists als offene Frage. Entscheidend bleibt der Consumer. Wenn er INCONSISTENT in Denial übersetzt, braucht er ein separates Record mit authorisiertem Principal, Policy-Version, Schutzgut, Threshold, Scope, Exceptions, Dauer, Notice und Appeal.

Die Signatur des Measurers übernimmt nicht die Haftung für den Ausschluss. Auch innerhalb eines Unternehmens müssen Measurement und Decision getrennte Rollen bleiben.

Kryptografische Belege sind nicht austauschbar

capsule_id ist SHA-256 über RFC-8785-JCS-Bytes ohne das ID-Feld. Exakte Bytes werden gespeichert; sortierte IDs bilden eine RFC-9162-Merkle-Tree-Hash. Ein Audit Path belegt Membership.

COSE_Sign1 bindet Issuer Key und Protected Headers. Ein SCITT Transparency Service kann das Signed Statement registrieren und ein Receipt liefern. Ein Zeitdienst kann die Existenz eines Commitments zeitlich einordnen.

Hash belegt Inhalt, Merkle die Einbindung, Signature den Schlüssel, Receipt die Registrierung und Timestamp den Zeitpunkt. Keiner belegt Kalibrierung, Vollständigkeit, Unabhängigkeit, Subject-Endorsement, faire Auswahl oder Berechtigung zur Sanktion.

Ein kompromittierter Signing Key kann falsche Records und eine umgeschriebene Daily Chain signieren. Erkennbar wird das nur gegen einen älteren Anchor außerhalb derselben Kontrolle.

Referenzieren heißt nicht, Outcomes zu übernehmen

effect_reference kann auf ein Signed Statement eines anderen Profils zeigen, ohne dessen Outcome zu kopieren. Authorization, Execution und Third-Party Measurement bleiben Aussagen verschiedener Issuer.

Approval beweist keinen Effekt, Action Receipt keine externe Postcondition, Measurement widerruft keine Approval, und ein gemeinsames Log entscheidet nicht zwischen ihnen. Der Consumer joint die Records und trägt seine Entscheidung.

Im gemeldeten Prototype ist effect_reference noch unbenutzt. Das Feld ist Entwurf, nicht Interoperabilitätsbeleg.

Korrektur ergänzt die Historie

Capsules werden nicht editiert. Eine Correction erzeugt neue Capsule und neuen Batch, verweist auf den Vorgänger und nennt before, after und reason. Der alte Record bleibt abrufbar. Änderungen an Canonicalization oder Merkle Construction erzeugen ebenfalls neue IDs.

So bleibt erkennbar, welche Evidence ein Consumer tatsächlich sah. Falsche Capsules lassen sich nach Registration aber nicht löschen. Subjects brauchen Correction/Exclusion, Consumers müssen Scores und Gates neu bewerten und Restoration dokumentieren.

Eine Korrektur im Log ohne Rollback der Sperre ist nur ein besseres Archiv, keine Wiedergutmachung.

Digest-only ist keine vollständige Privacy

sources enthält nur Digests. Ein privater Wert mit geringer Entropie kann dennoch durch Enumeration erkannt werden. Der Entwurf empfiehlt Blinding, das der Prototype nicht implementiert.

Messungen sollen sich auf maschinenöffentliche Surfaces beschränken, keine Credentials senden und bei MCP an Discovery enden. Wenn dadurch Claims unprüfbar bleiben, ist UNCHECKABLE die richtige Antwort.

Ein Prototype ist noch kein Ökosystem

Der Text meldet 13.184 Capsules, acht Batches und sieben Kinds aus der Organisation des Autors, dazu OpenTimestamps/Rekor, Browser Verifier und einen getrennten Checker. Das sind author-reported Implementation Claims.

Der Checker stammt aus derselben Organisation und gilt laut Draft nicht als unabhängige Implementierung. COSE_Sign1, echte SCITT-Registration, effect_reference und Blinded Digests fehlen.

Das Experiment verlangt eine fremde Implementierung, reproduzierte IDs/Roots, Registration bei einem anderen Service, Receipt-Verifikation durch Dritte, Cross-Issuer Reference und Corrections ohne Historienverlust. Bleibt all das zwei Revisionen lang aus, will der Autor den Draft zurückziehen. Diese überprüfbaren Ergebnisse sind stärker als eine interne Stückzahl.