要約

  • draft-templeman-scitt-measurement-capsule-00 は、宣言、第三者観測、差分、source digest、limitationを一つに保存するが、decisionやexecution authorityを持たせない。
  • UNCHECKABLEは欠如や失敗ではない。partial readは完全な否定を支えず、INCONSISTENTも真偽や責任を決めない。
  • correctionは旧capsuleを消さない。consumerが誤ったgateを解除するには、測定とは別のprincipal、policy、appeal、rollback receiptが要る。

誤ったcapsuleが公開され、marketplaceはserviceを停止した。翌日、issuerは新しいcapsuleで訂正した。古いrecordはsupersededになったが、marketplaceのcache、risk score、credentialは変わらなかった。

transparencyは履歴を守った。しかし権利は戻らなかった。訂正を発行する力と、停止を解除する力が別だからである。

この問題を正面から扱える素材が Declared-versus-Observed Measurement Capsules である。2026年10月2日のDatatrackerではrevision 00、active Individual Submission、提出日は9月27日、失効日は2027年3月31日。本文はExperimentalを意図し、IETF streamも担当Area Directorもない。RFC、WG adoption、IETF consensus、endorsement、deployment proofとして扱ってはならない。

提案は、対象やaction当事者ではないmeasurerが、subjectのdeclarationと別sourceからのobservationを比較し、structured differentialを作る。recordはdeterministic JSONで、authority_stateはmeasurement onlyに固定される。別profileのreceiptを参照できるが、そのoutcomeをcopyしない。

観測値より先に観測条件を読む

declarationは取得されたbytesである。registryやmanifestの名前だけでは足りない。version、location、retrieval time、media type、digestが必要だ。段階的rolloutやcacheがあれば、同じsubjectでも異なるdeclarationが見える。

observationにはvantage、credential、request、timeout、parser、clockがある。live endpoint、ledger proof、signature check、別runtimeでのrerunは異なるevidence classだ。二つのsurfaceを数時間離れて読めば、その時間差もlimitationになる。

INCONSISTENTは二つのencoded statementの不一致を示すだけで、どちらが真かを決めない。宣言がstaleかもしれず、観測がstaleかもしれない。scopeが違う可能性もある。差分をtruth oracleに変える瞬間、consumerは自らの推論を隠す。

draftのevidence ladderも同じ慎重さを持つ。state proofをblock header commitmentに対して検証しても、headerがconsensusに照らして正しいとは限らない。operator APIはoperator assertionであり、proofではない。labelを強化せず、sourceの主張がevidenceを超える場合はcapsule作成を拒む。

読めなかったものをゼロにしない

UNCHECKABLEは最も運用価値の高いstateである。permission不足、pagination中断、identity failure、proof評価不能はfailでもzeroでもabsenceでもない。NOT_LISTEDを使えるのはcomplete readの後だけで、partial readからtotalを作れない。

これによりdenominator manipulationが見える。unreadable rowを捨てれば率は上がり、zeroにすれば下がる。どちらも測定ではない。eligible、attempted、complete、uncheckableを分けるべきだ。

batch selectionも記録対象になる。disagreementが多そうなsubjectだけを選べば、個々のcapsuleがaccurateでもaggregateはmisleadingになる。batch recordはinclusion ruleと除外理由別countを示し、異なるruleのbatch countを安易に比較しない。

暗号化された履歴は判断権を生成しない

capsule_idは自身のfieldを除いたRFC 8785 JCS bytesのSHA-256である。exact bytesを保存し、IDをsortしてRFC 9162 Merkle Tree Hashへ入れる。audit pathはmembershipを示す。

COSE_Sign1はissuer keyとprotected headerをpayloadへbindingする。SCITT ReceiptはTransparency Serviceへのregistrationを示す。timestampは完成したproofの範囲で存在時刻を示す。これらはcontent、membership、signer、registration、timeという別々のreceiptだ。

どのreceiptもinstrument calibration、complete sampling、observer independence、subject endorsement、fair population、policy sufficiencyを証明しない。valid signatureはkey holderがbytesをsignしたことだけを示す。compromised keyならfalse historyもsignでき、検知には改ざん前のindependent anchorが必要だ。

schemaはdecision、allow、reject、approve、admit、permit、gateなどを禁止する。しかしsynonymは無限にある。real controlはconsumer側で、INCONSISTENTをdenyへ変えるpolicyを別recordにし、authorised principal、scope、threshold、exception、notice、appealを示すことである。

effectをjoinしてもissuerは一人にならない

effect_referenceは別profileのSigned Statementをdigestで指す。authorization receipt、execution receipt、third-party measurementを関連付けられるが、outcomeをcopyしない。

approvalはeffect occurrenceを示さず、action recordは外部postconditionを示さず、measurementはapprovalを取消さない。shared logはそれらを裁定しない。consumerがidentityとtime windowを明示してjoinし、自らのdecision receiptを出す。

current prototypeはeffect_referenceをpopulateしていない。fieldがあることとcross-issuer interoperabilityは別である。

append-only correctionの後に誰が動くのか

capsuleはeditされない。correctionはnew capsule/new batchで、旧record、before/after、reasonを指す。canonicalizationやMerkle constructionが変わってもnew IDsが必要で、old batchは残る。

このhistoryは「当時のconsumerが何を見たか」を守る。だがerroneous capsuleをwithdrawできない。subjectにはcorrection/exclusion routeが必要で、consumerにはsupersessionを検知し、score、credential、gateをre-evaluateする責任がある。

rollback receiptには、旧decision ID、使用したcapsule、new correction、re-evaluation policy、復旧範囲、残る損失を含めるべきだ。そうしなければtransparent correctionはarchive上の美しさに留まる。

digest-onlyはprivacyを完成させない

sourcesがdigestだけを持つのは直接開示を減らす。しかしlow-entropy private valueはcandidate enumerationでre-identifyできる。draftはblindingを勧め、prototypeでは未実装だとする。

machine-readable public surfaceだけを測り、credentialを送らず、MCPではdiscoveryで止めるという制約も重要だ。権限のないdeep probeでcomplete stateを作るより、UNCHECKABLEを残す方が正しい。

append-only registrationでは誤公開も消えない。privacy reviewはregistration前に行い、entropy、linkability、retention、disclosure、subject remedyを検討する必要がある。

author-reported prototypeを成熟度の終点にしない

draftはauthor organizationのPython implementationについて、13,184 capsules、8 batches、7 kinds、OpenTimestamps/Rekor commitments、browser verifier、別codebaseのcheckerを報告する。これはauthor-supplied statusである。

checkerも同一organization製で、draft自身がindependent implementationではないと認める。COSE_Sign1、third-party SCITT registration、effect_reference、blinded digestは未実装。OpenTimestampsやRekorはSCITT Receiptではない。

experimentは、別partyのimplementation、root再現、別operatorへのregistration、第三者Receipt verification、cross-issuer reference、historyを失わないcorrectionを求める。二revision以内に成果がなければwithdrawするという条件は、件数より強いmaturity signalである。