アジェンダ (60分)

• Part 1: ビジョン — PDF/XMLの罠を超えて
• Part 2: コア・アーキテクチャ — 3レイヤーモデルとHMP
• Part 3: L2 セキュリティ深掘り — 暗号化、PRF、およびWASM
• Part 4: データ主権 — Web/A Folio と信頼レベル (LoA)
• Part 5: 信頼モデルとガバナンス — ライトウェイト・トラストとDID-lite
• Part 6: エンジニアリング詳細 — タイポグラフィとバイモーダルUI
• Part 7: 現在の状況とロードマップ — レッドチーミングと標準化

Soraneとは何か？

• 検証可能なWebドキュメントのためのオープンソース参照実装
• 長期的な判読性と暗号化による信頼にフォーカス
• PDFでは不十分な公共セクターのワークフロー向けに設計

Web/A vs PDF/A vs XML/XTX

4レイヤー信頼モデル

人間・マシン等価性 (HMP)

• 人間用のHTMLとマシン用のJSON-LDが確実に統合されている
• 署名によって、両方のビューが同一の事実を表していることを保証する
• 生成された全てのドキュメントに検証UIが組み込まれている

Web/A 適合性レベル

Web/A Form セキュリティのハイライト

• Layer 1 テンプレートは署名され、ハッシュで束縛されている
• Layer 2 ペイロードは Ed25519 署名を使用
• 暗号化は AAD を用いて layer1_ref に束縛される (切り貼り攻撃防止)

アーキテクチャ概要

flowchart TD
    User["ユーザー入力"] --> Plain["L2 平文"]
    
    subgraph browser ["ブラウザ（クライアント）"]
        Plain --> Sign["署名者 (Ed25519)"]
        Sign --> Signed["L2 署名済みペイロード"]
        Signed --> Encrypt["暗号化 (HPKE / WASM)"]
    end
    
    Encrypt --> Envelope["L2 暗号化エンベロープ"]
    
    Envelope --> Storage["配送 (Local / WebA Post)"]
    
    subgraph aggregator ["アグリゲータ（発行者）"]
        Storage --> Decrypt["復号器 (Strict Replay Check)"]
        Decrypt --> Verify["署名検証器"]
        Verify --> Data["検証済みデータ"]
    end

Web/A 5つの構成要素

graph TD
    Maker[Web/A Maker] -->|1. 鋳造| Form[Web/A Form]
    Maker -->|1. 鋳造| Doc[Web/A Doc]
    
    Form -->|2. 入力・署名| Doc
    Doc -->|3. 保管| Folio[Web/A Folio]
    
    Folio <-->|4. 配送| Post[Web/A Post]
    Post -->|5. 収集| Aggregator[Aggregator]

• Foundry (Maker/Aggregator)：信頼の生成と集計
• Interface (Form/Doc)：人間と機械が等価に扱える容器
• Infrastructure (Folio/Post)：主権的な「所有」と「配送」

階層的鍵導出

flowchart TD
    Instance["SRN マスター鍵"] -->|HKDF| Root["組織ルート鍵"]
    Root -->|HKDF| Campaign["キャンペーン・フォーム鍵"]
    
    subgraph per_form ["フォーム毎"]
    Campaign --> Pub["公開鍵（フォームに埋め込み）"]
    Campaign --> Priv["秘密鍵（アグリゲータで使用）"]
    end

• 運用の手間がかからない鍵ローテーション
• キャンペーンおよびフォーム間の隔離
• マスター鍵を露出させない鍵預託

WebAuthn PRF による復号

sequenceDiagram
    participant User as ユーザー
    participant Browser as ブラウザ
    participant Auth as WebAuthn/認証器
    
    User->>Browser: 「パスキーでロック解除」をクリック
    Browser->>Auth: PRF拡張付きで get() を実行
    Auth-->>Browser: PRF 出力 (シード)
    Browser->>Browser: HKDF(シード) -> ラップ鍵
    Browser->>Browser: AES復号 (ラップされた秘密鍵)
    Browser->>Browser: L2 エンベロープを復号
    Browser->>User: 平文データを表示

L2 エンベロープのライフサイクル

sequenceDiagram
  participant User as ユーザー
  participant Browser as ブラウザ
  participant Issuer as 発行者
  User->>Browser: フォームに入力
  Browser->>Browser: ペイロードに署名 (Ed25519)
  Browser->>Browser: 暗号化 (HPKE準拠)
  Browser->>Issuer: エンベロープを送信
  Issuer->>Issuer: 復号 ＋ 検証

リプレイ保護

• エンベロープ毎に nonce を保存し、厳格に重複をチェック
• Security Audit v3 要件：復号時のリプレイガードを必須化
• CLI: JsonFileReplayStore / ブラウザ: LocalStorageReplayStore

flowchart TB
  S[エンベロープ] --> N{既知の nonce?}
  N -- No --> A[受理 ＋ 保存]
  N -- Yes --> R[拒絶]

パイロット運用における安全ガイド

• 利用者向けガイドの公開：リスクと責任境界の明文化
• 人的サポート体制：技術的限界を運用（バックアップ等）で補完
• 実験的機能の明示：HMPの実証を通じた段階的な信頼獲得

Pre-Key インフラストラクチャ草案

• prekey_url を介した使い捨て受信者鍵
• オフライン提出の利便性を維持
• 静的な鍵へのフォールバック時には警告を表示

Layer 3：Web/A Folio

信頼レベルとLoA

• LoA 1 (本人申告)：正本 ＝ 人間可読テキスト。JSONは派生。
• LoA 2+ (検証済み)：正本 ＝ マシン可読。人間用は派生。
• バリデーション：LoA 2+データを編集すると「検証済み」が無効化される。

提出用バンドル

graph TD
    B[提出用バンドル] --> M[Manifest.json]
    B --> D[Docs/ HTML]
    B --> A[Attachments/ PDF]
    B --> V[VP/ スコープ限定の主張]
    B --> R[検証レポート]
    
    M -->|署名済み| S[Manifest.sig]
    R -->|全ファイルをカバー| B

ツールキット・アーキテクチャ

graph TD
    MD[Form.markdown] -->|parse| Schema[Schema.json]
    Data[Data.json] -->|fill| Filled[Filled.html]
    MD -->|validate| Result[検証結果]
    Key[Passkey] -->|sign| Signed[署名済みHTML]

ポリシー用DSL（草案）

profile: onboarding
requires:
  - manifest.bundle_id
  - subject.id
rules:
  - id: vp_required_for_l3
    when: claims.level == 3
    assert: vp.exists == true

Bring Your Own AI Agent (BYOA)

• MCP (Model Context Protocol) 対応：エージェントが Folio に直接アクセス
• 検証済みのコンテキスト：AI が「正しい証拠」に基づいて推論・対話を遂行
• 個別のエージェント選択：特定のプラットフォームに縛られない自由なAI活用

「ライトウェイト・トラスト」モデル

• 強力な検証機能を維持しつつ、導入コストを低減
• レガシーPKIからの段階的な移行を想定した設計
• インフラ刷新なしに耐量子暗号 (PQC) への移行をサポート

クライアントの安全性：下書き状態の保存

• 下書きHTML内に作業状態を埋め込み
• デバイス間移動やキャッシュクリア後の復元を可能に
• 下書きファイル自体を機密性の高い成果物として扱う

高度なタイポグラフィ要件

• 行政標準文字のカバー (IVS/SVS)
• 公的なレイアウトの忠実な再現（グリッド再現）
• セキュリティ制約としての「レイアウト崩れゼロ」

Web/Aの進化（サマリー）

エンジニアリングの進捗

flowchart LR
  A[L2 実現可能性] --> B[暗号化フォーム]
  B --> C[ReplayGuard 強化]
  C --> D[WASM 移行完遂]
  D --> E[Red Team 評価 v8]
  E --> F[安全ガイド公開]
  F --> G[広域運用に向けた設計]

反復的なフィードバックループ

sequenceDiagram
  participant Dev as Web/A チーム
  participant RT as レッドチーム
  participant Spec as 仕様 ＋ 文書
  RT->>Dev: 発見事項 (v2)
  Dev->>Spec: 修正計画
  Dev->>RT: 実装報告
  RT->>Dev: 再評価 (v3)
  Dev->>Spec: ハードニング・メモ

段階的な導入アプローチ

文書の類型化

標準化に向けた課題

• デバイス間、および対面での転送プロトコル
• ブラウザサンドボックス内での実用的なホルダーバインディング
• ブラウザによるネイティブな検証サポート
• 長期検証 (LTV) の確立

主要なホワイトペーパー

• Web/A 解説書
• Web/A L2 暗号化仕様
• Web/A Folio コンセプト
• 再評価報告書 v3

なぜこれが重要なのか

• Web/Aは文書を、単なるファイルではなく検証可能な「成果物」に変える
• 信頼は時間、デバイス、機関を超えてポータブルになる
• 目標は、ロックインではなく、透明なセキュリティによる相互運用性である