背景

README L20 に記載されているサブプロジェクト

Myna FIDO: マイナンバーカードを FIDO2 キーにする試み

について、構想と方向性を伺いたく Issue を立てさせていただきました。
GHSA-rxpx-26p9-4xvr / GHSA-g258-q5gf-7hvx / GHSA-58hw-cg5m-88rp の disclosure 関連で myna のコードを精読する中で関心を持ち、
GHSA-58hw のスレッドで HAMANO さんに公的個人認証法第 17 条の制約と myna の設計思想 (生成自由 / 自己検証自由 / 失効情報なしのカジュアル検証に意味あり) をご教示いただいた流れで、
Myna FIDO の方向性が現行 myna の思想と整合する形で実装可能と思い至り、議論をスタートしたいと考えました。

HAMANO さんの当初の構想についてご教示ください

README に 1 行のみ言及があり、コード・コミット・他ドキュメントに該当物が見当たらないため、当初お考えだった点をいくつか伺えると議論しやすいです。

• 想定アーキテクチャ (virtual FIDO2 device / browser extension / 独自プロトコル / 他)
• 想定ユースケース
• 法的位置づけのお考え (今日のお話との繋がり)
• 着手されていない理由 (時間 / 法的不確実性 / 他要因)

たたき台としての設計案

構成

[ Browser / OS ]
   ↕ WebAuthn API (alg=-257 RS256)
[ Virtual FIDO2 device (Linux uhid / macOS IOHIDFamily / Win WinUSB) ]
   ↕ CTAP2 over HID
[ Myna Authenticator core (新規) ]
   ↕ PIN verify, sign command
[ myna (既存) pcsc / APDU / jpki.rs ]
   ↕
[ マイナンバーカード 認証用 AID ]

鍵設計

• JPKI 認証用鍵 (RSA-2048) のみ使用 (4 属性が入る署名用鍵は使わない、プライバシー保護のため)
• 1 カード = 1 物理鍵 → credential ID を HMAC(jpki_pubkey, RP_ID) 等で派生 → RP 単位で differentiate
• WebAuthn の "1 origin = 1 credential" 原則を活用 → サイト間 unlinkable + 自動的に Sybil-resistance

法的位置づけ

• CTAP2 attestation を出さない (self / none モード): RP は JPKI cert chain を見ない → JPKI 由来である事が leak しない
• WebAuthn = 認証であって電子署名検証ではない: 第 17 条が想定する「電子署名検証」と用途が異なる
• 結果として「T1 (署名生成は自由) + T2 (RP 側での認証 = 本人登録鍵に対する challenge-response 確認)」の枠に収まり、PF 事業者制度を踏まない構造

想定ユースケース

1. 任意の WebAuthn サイトへの login (= マイナカードを共通認証手段に)
2. 転売不可能なチケット (WebAuthn 仕様上 1 origin 1 credential = 自動 nullifier、転売はカード+PIN 物理譲渡が必要 = 実質不可)
3. AI agent delegation の委任証 (本人が agent に対し WebAuthn 署名)
4. 投票系 Mini App での本人確認 (運営側の検証コストゼロで)

既存資産との関係

私が並行で開発している janus + hyde-webauthn (Linux 仮想 FIDO2 authenticator) で CTAP2 + uhid 部分のプロトタイプがあり、Myna FIDO に移植可能です。

進め方の選択肢

• A. myna 本体に subdirectory として実装 (mpa と同じパターン)。HAMANO さんがメインドライバ、私が PR で貢献
• B. 私の方で fork / 別 repo で実装、成熟したら myna への merge を相談
• C. 別 organization (例: myna-fido) で独立、myna を dependency として参照

私の希望は A または B ですが、HAMANO さんのご意向を最優先で進めたいです。

次のアクション (案)

1. まずは本 Issue で構想と方向性を議論
2. 必要に応じて設計 doc / RFC 形式で別途まとめ
3. 実装着手はご意向確認後

よろしくお願いします。

報告者: 安河内 竜二 (Ryuji Yasukochi) / @Ryujiyasu