Summary

  • draft-wei-capability-language-core-00 の allow_unresolved は独立した判定値であり、制約を認識したものの、利用可能な証拠や評価器では結論を出せなかったことを示す。
  • 利用側は正規化された未解決集合を保持し、AND 条件として全件を解決しなければならない。違反または解決不能が一つでもあれば実行を拒否する。
  • 時間窓を満たして得た allow は、その区間の終了より長く有効ではない。正しい瞬間判定をキャッシュで恒久的な権限に変えてはならない。

三つ目の値を二つに丸める危険

許可と拒否しか扱えない連携基盤に、三値の判定を渡すとする。allow_unresolved が非ゼロだから真、HTTP 200 だから成功、文字列が allow で始まるから許可——どれも実装上は簡単で、意味上は同じ事故である。

CLC revision 00 は、分からない条件を捨てないために三つ目の値を置く。コアが制約の型を理解しても、信頼できる時刻、現在のネットワーク状態、あるいは配置固有の評価器がなければ、判断は終わらない。未解決条件は unresolved に残され、利用側が証拠をそろえて Resolve に戻すか、拒否しなければならない。

CLC 自体はキャリアに中立である。JWT などのネイティブな入れ物を誰が検証し、どの発行者を信頼するかは周辺システムの責任だ。外部操作を実行したか、その結果が現実に生じたかも、言語評価とは別の記録になる。共通化されるのは、評価結果と残作業の意味である。

「知っている制約」と「満たした制約」

草案は core-clock と network の制約を認識する。これは構文を解析し、正規化し、未解決のまま運べるという意味であって、条件が成立したという意味ではない。

認識した条件を評価できないからと削除すれば、入力より出力の方が権限の広い capability になる。同じ scheme/type に複数の条件があれば、すべてが AND である。一件だけを採用する first-wins や last-wins、どれか一件でよいという扱いは、最適化ではなく方針変更だ。

正規化では同値な重複をまとめられる一方、異なる義務を落としてはいけない。順序も規定された UTF-8 バイト列で決まり、処理系の既定比較に委ねられない。ECMAScript の通常の UTF-16 順は同じとは限らない。ここで必要なのは、二つの実装が同じ未完了リストを指せることだ。整列したリストそのものは証拠にならない。

Resolve で初めて閉じる

Resolve は、最初の判定と各義務の resolution を受け取る。優先順位は明確だ。一件でも violated なら deny。全件 satisfied のときだけ allow。unknown が残るなら allow_unresolved のままである。壊れた入力や不正なタイムスタンプも拒否に倒す。

したがって運用記録には、最初の enum、未解決集合、評価器の識別子と版、証拠、観測時刻、各項目の状態、最終 enum、実際の実行許可を一つの鎖として残す必要がある。「resolver を呼んだ」というログだけでは、何を根拠にどの操作を通したか分からない。

証拠を照合する側には allow_unresolved に相当する逃げ道がない。分からない証拠条件は UNSATISFIED である。この違いは、未完了の認可を表すことと、証拠が一致したふりをすることを混同しないために重要だ。

期限は判定結果にも付く

実行可能時間を 23:50 から 24:00 までとする。23:58 に信頼できる時計で条件を満たし、Resolve が allow を返すのは正しい。しかし 00:01 に同じ結果を再利用するのは正しくない。

主体・資源・操作だけをキーにしたキャッシュは、この差を隠す。制約、評価コンテキスト、解決時刻、区間終端を保存し、キャッシュの寿命を最も早い終端以内に制限しなければならない。RFC 3339 は日時表現を定めるが、信頼する時計や許容するずれは決めない。

containment も代用にならない。ある capability が上位 capability の範囲内にあると証明できても、現在時刻の義務は満たされない。キャリアが信用できるとも、操作が実行されたとも言えない。構造、信頼、認可、実行、結果は別々の境界である。

恒路の Reality Layers に照らせば、正規化された条件は現実そのものではなく、未完了状態の表現だ。Minimum Initial Specification が共有すべきなのは、その表現を消さずに受け渡す最小限の意味である。ローカルな証拠源と決定責任まで、共通言語が自動的に引き受けるわけではない。

草案は 123 の conformance vectors、1,184 の property cases、三つの実装を報告する。再計算可能な running code として価値はあるが、三実装は著者を共有しており、独立実装の基準はまだ満たされていない。別組織の実装で enum 変換、UTF-8 順、重複条件、unknown、壊れた時刻、区間終了直後のキャッシュを検証して初めて、相互運用の主張が強くなる。

Sources and limits

これらが示すのは、個人提出の active Internet-Draft、公開コーパス、関連仕様である。IETF 合意、RFC、WG 採用、独立セキュリティ評価、広範な導入、キャリアの信頼性、操作結果は示さない。本稿の範囲は revision 00 の認識済み・未評価制約、Resolve の閉ループ、時間窓の失効境界に限る。