Perspective
信頼の見取り図
重要な業務を「ログイン済みだから本人だろう」で終わらせないために。 Clavis を支える考え方を、専門用語ではなく、仕事の風景に置き換えて読み解きます。
ここで用いる比喩は、仕組みを理解するための入口です。 実際の技術設計と責任分界は、各記事から Technology / Security へご案内します。
Six viewpoints
仕組みではなく、判断の起点から読む。
- 01
Session → Intent → SignProof
入館証だけでは、金庫は開けない
ログインは建物に入るための確認です。送金や権限変更まで、その一度の確認だけで通してよいとは限りません。
- 02
Domain → DNS proof → Organization
会社の表札は、なぜドメインなのか
ドメインはウェブサイトの住所だけではありません。組織が外部へ示し、継続して管理できる「表札」として使えます。
- 03
Passkey → OIDC → Relying party
鍵は増やさず、建物を渡る
業務アプリが増えるたびに、本人確認の仕組みを作り直す必要はありません。共通の本人性を、安全な通行証として渡します。
- 04
Readable context ↔ Digest-bound proof
確認画面は、署名そのものではない
人が読む画面と、機械が検証する証跡。表示と照合値の元データを一致させて、はじめて確かな確認になります。
- 05
Identity boundary ↔ Business data
本人性と署名の基盤が、業務データを持たない理由
本人性を扱う場所と、契約・金額・顧客情報を扱う場所を分ける。集めすぎないことも、信頼基盤の設計です。
- 06
Shared SaaS ↔ Dedicated instance
共有の玄関と、自社専用の建物
同じ設計を共有サービスとして使うか、自社の表札と運用境界を持つか。違いは機能表だけでは決まりません。