1. 目的

PassKey (WebAuthn) は端末内の鍵として安全だが、第三者に対して「誰の鍵か」を証明できない。 そこで、マイナンバーカードの署名用電子証明書で PassKey 公開鍵を署名し、本人性を担保する仕組みを設計する。

2. 前提とスコープ

  • 対象は PassKey公開鍵の本人性証明。ID確認そのもののUI/UXは別途検討。
  • 署名は カード内秘密鍵で実施し、外部へは公開鍵証明書と署名結果を提供する。
  • 署名はローカル環境で行う (ブラウザ単体では不可のため)。

3. 実現可能性の整理

3.1 技術的には可能

  • 署名用電子証明書は 公開鍵証明書 (X.509) と 署名機能を提供する。
  • PassKey公開鍵は登録時に取得可能 (WebAuthnのcredentialPublicKey)。
  • これらを ローカルアプリ/CLI で結びつけ、署名データを生成できる。

3.2 主要な制約

  • ブラウザ標準APIだけではカード署名が扱えない。
  • 署名用証明書の利用には カードリーダーやNFC と OS側ミドルウェア が必要。
  • 失効確認 (CRL/OCSP) は実装負担がある。

4. 署名対象データの設計

4.1 署名する内容

PassKey公開鍵そのものだけでなく、以下を束ねて署名する。

  • PassKey公開鍵 (COSE Key or JWK)
  • 鍵識別子 (credentialId)
  • 発行時刻 (createdAt)
  • 依拠先 (rpId)

4.2 署名対象JSONのスキーマ (Draft v0)

ブラウザでPassKeyを取得し、CLIでmyna署名できる最小構成を定義する。

{
  "schema": "passkey-binding-v0",
  "createdAt": "2026-01-04T12:34:56Z",
  "rpId": "example.com",
  "credentialId": "BASE64URL",
  "publicKey": {
    "format": "cose",
    "value": "BASE64URL"
  },
  "client": {
    "origin": "https://example.com",
    "userAgent": "UA String"
  }
}

補足:

  • publicKey.format は cose を基本とし、必要に応じて jwk を許容する。
  • credentialId と publicKey.value は Base64URL 表記。
  • client は監査・再現性のための付帯情報。署名対象から外す場合は別ファイル化でも可。

4.3 カノニカル化

  • 署名対象は 安定したJSON文字列に変換してからハッシュ化する。
  • 例: JCS (JSON Canonicalization Scheme) を採用。

5. 署名形式

5.1 推奨形式

  • CMS/PKCS#7 署名を採用し、X.509証明書チェーンを内包する。
  • 署名アルゴリズムは証明書の鍵種に従う (RSA or ECDSA)。

5.2 成果物

  • passkey-binding.json (署名対象データ)
  • passkey-binding.p7s (CMS署名)
  • これらを VC形式でラップして Folio に保存する。

6. 検証フロー

  1. passkey-binding.json と署名ファイルを取得
  2. CMS署名の検証 (証明書チェーン)
  3. 署名対象の正当性チェック (canonical JSON一致)
  4. 証明書の失効確認 (CRL/OCSP)

7. Folioとの統合イメージ

  • Folio内に keys/passkey-binding/ を作成し、署名成果物を格納。
  • 提出時は VC/VP として同梱し、PassKey署名と 二段階の証明を構成。

8. リスクと留意点

  • 証明書失効時の扱い (更新・再署名のフロー)
  • 署名時の利用者確認プロセス (PIN入力等)
  • 署名対象の範囲が曖昧だと 再バインド攻撃が成立しうる

9. 実装ステップ案

  1. PassKey公開鍵の抽出 (WebAuthn登録時に取得)
  2. 署名対象JSONの生成とカノニカル化
  3. ローカルCLIでカード署名を実施
  4. 署名成果物の検証ツールを実装
  5. Folio連携 (保存・VP生成)

10. 優先度と論点整理

SRN側のトラストチェーンは既に動作しているため、Passkey統合は「設計論点の整理」を先に進め、実装はFolio側のholder bindingが落ち着いてからでも良い。

10.1 SRN側の位置づけ

  • 役割: 発行者署名 (Template/Instance VC) はSRNで完結する。
  • Passkeyの位置: 利用者署名 (VP) を担うが、SRN自体の発行チェーンには必須ではない。

10.2 Folio側で優先すべき理由

  • holder bindingが必須: 申請・提示の現場で本人性が必要になる。
  • I/Fが多い: Passkey取得、JSON生成、myna署名、VP生成を束ねる必要がある。

10.3 先に整理すべき論点

  • Passkeyの役割範囲: VP署名のみか、Draft保存の署名にも使うか。
  • Binding VCの扱い: 発行主体、失効、更新フロー。
  • 検証ルール: SRN側でBinding VCの必須化をするか、Folio側のみで扱うか。

11. 住民票ユースケースでの必須条件

総務省向けの説明では、住民票の提示が「誰が提示したか」を伴うことを明確にする必要がある。住民票は本人性の確認が前提であり、Credentialの配布ではなくPresentationの提示が必須となる。

11.1 前提

  • 住民票は本人性の証明を目的とするため、Holder Binding が欠かせない。
  • 提示時は VCそのものではなくVP を受け渡し、提示者の署名を含める必要がある。

11.2 必須となる要素

  • マイナンバーカードとの紐付け: 公的な本人性を担保するため、National IDの署名でPasskeyをバインドする。
  • Passkey署名: 提示時に本人の操作でVPへ署名し、提示者の真正性を担保する。
  • Binding VC: Passkey公開鍵と本人性を結びつける証拠として保存・提示する。

11.3 説明の要点

  • 提示者が本人であることが住民票の要件であり、Passkeyのみ・IDカードのみでは不十分。
  • IDカード署名 + Passkey署名の二段階が、オンライン提示における本人性と操作の両方を担保する。

12. 住民票が複数Data Subjectを含む場合の論点

住民票は世帯単位の情報を含むため、data subjectが複数になる。提示者（holder）が代表者であるケースを想定すると、署名構造に以下の論点が出る。

12.1 署名主体の整理

  • 提示者署名 (Passkey/VP): 提示行為の真正性を担保する。
  • 発行者署名 (VC): 住民票の内容自体の真正性を担保する。
  • data subject全員の署名は原則不要: 住民票の性質上、発行者の公的署名が一次的な根拠となる。

12.2 同意・代理の扱い

  • 世帯主や代理人の権限: 誰が提示できるかの法的整理が必要。
  • 未成年・被後見人: 代理提示のルールを明確化する必要がある。

12.3 プライバシーと最小開示

  • Selective Disclosure: 必要最小限の項目だけ提示する構成が望ましい。
  • 世帯員情報の分離: 世帯全体が不要な場面では、個別のVC/VPを切り出す運用も検討する。

12.4 監査・説明責任

  • 提示ログ: 誰が誰の情報を提示したかを追跡可能にする必要がある。
  • 説明文言: 「提示者=本人」ではなく「提示者=権限を持つ代表者」であることを明示する。