【ITニュース解説】nomos.can() – authority as a first-class primitive

システム開発において、ユーザーやプログラムが特定のアクションを実行する権限があるかどうかを判断する機能は非常に重要だが、その管理は複雑になりがちだ。これまでのソフトウェア開発では、「この操作は許可されているのか、そして誰の権限で行われるのか」という問いに対する統一された「プリミティブ」、つまり基本的な操作単位が存在しなかった。

通常、このような権限判断のロジックは、個々のアプリケーションのコード内部に直接記述されたり、特定の設定ファイルに分散して定義されたりする。時には開発者の間で共有されるドキュメント（Wikiなど）にルールが記載されているだけの場合もある。しかし、このアプローチだと、権限の定義が各システムに紐づけられてしまい、異なるシステム間で権限の定義を共有したり、あるシステムが別のシステムに対して「この操作は確かに許可されています」と信頼できる形で証明したりすることが非常に難しいという問題があった。権限そのものを独立した要素として扱ったり、システム間で移動させたりすることができないため、多くの手間やミスの原因となることが少なくなかった。

このような課題を解決するために「nomos.can()」という新しい概念とツールが提案されている。これは、権限をまるでインターネット上のウェブサイトのホスト名のように、固有の名前を持ち、アドレス指定可能な独立した存在、すなわち「第一級プリミティブ」として扱うことを目指す。このアプローチにより、権限に関するロジックが個々のアプリケーションコードから切り離され、集中管理され、独立して参照できるようになる。

nomos.can()の利用は非常にシンプルで、主にcan()という単一の関数を呼び出すことで行われる。この関数は、どの「権限（authority）」に対して、どのような「アクション（action）」を、どのような「事実（facts）」に基づいて評価するかを引数として受け取る。例えば、「eu-ai-act」という名前の権限に対して「システムのデプロイ」というアクションを、「リスクレベルが『高』で、適合性評価が未実施である」という特定の事実を考慮して評価するといった形で利用する。

can()関数は実行後、三つの主要な情報を返す。一つ目は「verdict（裁定）」で、これは操作が「AUTHORIZED（許可）」、「DENIED（拒否）」、「ESCALATED（要エスカレーション）」のいずれであるかを示す。二つ目は「obligations（義務）」で、もし操作が許可された場合に守るべき追加の条件や指示が含まれることがある。そして三つ目で最も重要なのが「signed transcript（署名付きトランスクリプト）」である。このトランスクリプトは、行われた権限チェックの正確な質問内容、それに対する正確な回答、そしてその権限の定義元によって生成されたデジタル署名が含まれる記録である。

この「署名付きトランスクリプト」があることで、権限チェックの結果に高い「検証可能性」がもたらされる。例えば、システムのログだけでは信頼性に不安が残る場合でも、このトランスクリプトと権限の公開鍵、そして小さな検証スクリプトがあれば、第三者がオフライン環境で、どのような質問がされ、どのような回答が返されたのかを独立して検証できる。これにより、権限管理のプロセスにおける透明性と信頼性が大幅に向上する。

nomos.can()で利用できる権限の定義方法にはいくつか種類がある。一つは、名前で指定され、誰でも照会できる「公開された権限」だ。二つ目は、利用者が自身で権限の定義を作成し公開する「artifact_id」で指定される権限。そして三つ目は、権限の定義ファイルとそれに関連する証明書チェーンを自分で管理し、can()関数がそれらをオフラインで検証する方式である。このオフライン検証では、利用者が事前に信頼する「ルート公開鍵」を明示的に指定する必要があり、デフォルトのルートは存在しない。nomos.can()は外部のサーバーに情報を送信することはなく、常に同じ入力に対して同じ結果を返すように設計されているため、安定性と予測可能性が高い。

nomos.can()では、エラーの種類も明確に区別される。「DENIED」という結果は、権限の定義されたルールに基づいて特定のアクションが拒否されたことを意味し、ルール自体に問題があるか、指定された事実がルールを満たしていないことを示す。これに対し、「NomosIssuerNotTrustedError」というエラーは、can()関数がその権限を定義した発行元を信頼できなかった場合に発生する。これは証明書チェーンが無効であったり、指定されたルート公開鍵と一致しなかったりした場合に起こる。これら二つの問題は全く異なり、それぞれ異なる方法で対処する必要がある。例えば、証明書チェーンを修正すれば信頼性の問題は解決するが、ルールによって拒否されたアクションが許可されるわけではない。

権限の定義自体は、デジタル署名されたファイルとして行われる。具体的には「Ed25519」という署名アルゴリズムと「JCS/SHA-256」というデータ正規化方式が用いられ、これにより定義の改ざんが非常に困難になる。また、一度定義された権限は後から「失効」させることも可能だ。失効リストは署名され、日付が付与された状態で公開され、can()関数が結果を返す前に必ずこのリストをチェックする。もし権限が失効していれば、その旨と理由がcan()関数の結果に含まれる。

しかし、nomos.can()にもまだ発展途上の部分や未解決の課題が存在する。例えば、can()関数は与えられた事実だけから、どの権限を適用すべきかを自動的に推論することはできない。適用したい権限は、利用者が明示的に指定するか、権限の定義自体をcan()関数に渡す必要がある。また、権限の信頼チェーンに関するフォーマットは現在「ドラフト」段階であり、これが広く業界標準として受け入れられるためには、さらなるフィードバックと、仕様に基づいた複数の実装が求められる。そして、これらの権限システムにおける「信頼の根源」となるルート証明書を、誰がどのような責任と体制で運用していくべきかという点も、まだ議論と解決が必要な重要な課題である。

nomos.can()は、現代の複雑なソフトウェアシステムにおける権限管理の課題に対し、新しい視点と具体的な解決策を提供する試みだ。権限を独立した検証可能なプリミティブとして扱うことで、これまでアプリケーションコードに分散しがちだった権限のロジックを一元化し、システム全体の堅牢性、透明性、そして信頼性を向上させる可能性を秘めている。システムエンジニアにとって、より安全で信頼性の高いシステムを構築するための新しい強力なツールとなり得るだろう。