このシリーズでは、マイナンバーカードを USB リーダー無し(スマホ NFC)で WebAuthn 認証器にするところまで作り、実在のネット証券(自分の口座)で登録とログインまで通しました。次に自然に浮かぶのが「デジタル認証アプリの認証API(OIDC)と組み合わせて、もっと強い本人性まで足せないか」です。実際に 登録時に OIDC で本人確認 → 以後はパスキー、というハイブリッドの PoC も作りました。
でも、設計として詰めた結果、このプロダクトでは公的な認証APIを「あえて使わない」と決めました。今回はその判断、つまり「認証の強さ」と「制度の重さ」のトレードオフの話です。技術 how-to ではなく、設計メモに近い回です。
「マイナを使う」=「公的APIを使う」ではない
まず誤解されやすい点。マイナンバーカードを認証に使う、と聞くと「公的個人認証(JPKI)の検証サーバや、デジタル認証アプリの認証APIを叩く」をイメージしがちです。でも、やり方は大きく2つに割れます。
- B(ローカル完結型):カードを端末で読み、その署名を種にサイトごとの鍵を導出して WebAuthn する。J-LIS にもデジタル庁にも問い合わせない。「このカードが物理的にここにある」しか見ない。
- A(公的API連携型):登録時などに認証API(OIDC)を呼び、本人確認情報や「証明書が今も有効か」を公的に検証した結果を受け取る。
これまでの記事で作ってきたリーダーレス認証器は、全部 B です。証券口座に通したときも、カードの署名から導出した鍵で WebAuthn しただけで、公的な検証サーバは一切経由していません。一方、OIDC ハイブリッドの PoC が A でした。
B の身軽さ
B は、制度の外にいられます。公的個人認証の検証結果を受け取らない＝「検証者」でも「委託者」でもない。だから:
- 公的機関との契約は不要
- 検証の利用料も発生しない
- サイトごとに別鍵で名寄せ不可、マイナンバーも証明書も外に出ない(プライバシー設計の記事参照)
個人開発・小規模で「とりあえず作って動かす」には、この身軽さが効きます。証券口座の実証も、この身軽さの中でできました。
A を選ぶと「制度」が乗ってくる
では A、公的APIで有効性検証や本人確認情報を受け取る側に回るとどうなるか。私の理解では、ここは分散型の FIDO2 とは別の、規制された平面です。電子証明書の有効性を確認する事業者は、署名検証者/利用者証明検証者として認定(あるいはプラットフォーム事業者経由の「みなし認定」)を受ける必要があり、おおむね次のような義務を継続的に背負います(詳細・最新は公的個人認証サービスの公式情報やデジタル認証アプリの開発者ドキュメントを確認してください)。
- 利用申込・業務委託契約(事前準備契約 → 本契約)。代表者名義で結ぶ正式な契約
- 目的外利用の禁止(申告した用途の外で使えない)
- 検証結果の第三者提供の制限
- 本人確認情報の安全管理・アクセス記録・廃止時の消去、個人情報保護法の上乗せ
- 監査・報告の対象
これらは「悪い」わけではなく、公的な本人確認情報を扱う以上当然の責任分界です。ただプロダクト目線で見ると、登録フローのたびにこの重さが乗り、開発の自由度とスピード、そして何より UX が落ちます。「強くするために、結局そのままでは使いにくいアプリになる」——これが A の本質的な詰みでした。
いちばん効く制約 — 「依存(reliance)」の原理
契約義務がかかるフックは、データが毎回流れるかどうかではありません。「マイナ由来の保証を、誰が当てにするか」です。ここを掴むと一気に整理できます。
- 自分のサービス内で完結(下流に検証結果を渡さない)なら、委託者は自分一者。契約も一本で済む。
- でも「マイナで確認済み」という保証を下流の各事業者に提供し、向こうがそれを当てにして自前の本人確認を省くなら——その各社が検証者として個別に契約することになる。
つまり「マイナ保証を売りに横展開する」と、使う事業者ごとに契約が要る構造になる。個人や小規模には、現実的に回せません。ここに鉄則が一つあります。
下流に出す「価値」と、下流が背負う「契約義務」は、同じ量。
「価値は出すが、依存も契約もさせない」という第三の状態は、この枠組みには存在しない。
逆に言えば、保証を誰にも当てにさせていない(完全に内部の衛生として使っている)なら、それは契約フックを引かない代わりに商業的な「売り」にもならない。価値と義務は連動していて、片方だけ取ることはできない、という話です。
「失効検知だけ欲しい」という中間案
B には正直な穴があります。「カードがそこにある」しか見ないので、そのカードが失効・再発行・紛失届け済みでも気づけない。盗まれたカードと PIN が同時に漏れた場合の経路が残ります。
これを埋める中間案が A-lite です。失効リストを定期取得して自社内だけで照合し、下流には何も渡さない。第三者提供や上の「依存」問題は避けられます。ただし検証者としての届出・契約や安全管理の義務は残り、さらに仕様の一部は協定下で開示制限がかかる(=こういう設計記事で内部まで書けなくなる)。だから「失効検知がどうしても要るときだけ、自社内に閉じて半歩出る」のが現実的な落としどころだと考えています。
結論 — あえて公的APIを使わない
そこで本線は B に決めました。強さは「制度」ではなく所持 factorで出す、という方針です。
- 物理カード + PIN:知識だけ・端末だけでは突破できない
- PC + スマホ + カードの三点同時:単一端末が陥落しても突破されない。生体・端末内パスキー(Windows Hello 等)に対して上乗せできるのはここ
- これらは下流に何も申し送らなくても、本人にそのまま効く価値。だから制度を背負わずに出せる
逆に、公的性(失効・本人保証)を売り文句にはしない。売りにした瞬間、さっきの「依存」側に滑って制度の重さが戻ってくるからです。そして製品の伸ばし方は、これまでのブラウザ拡張(原理実証の足場)を卒業して、OS 標準の認証器プロバイダ(iOS の ASCredentialProvider、Android の Credential Manager、デスクトップは caBLE ハイブリッド)に寄せる。サイト側に一切介入せず、契約も要らず、スケールします。
「マイナを使う」と聞くと公的APIを連想しがちですが、FIDO2 の所持 factor として使うだけなら、制度の外で軽く・強くできる。何を取って何を捨てるかを意識的に選ぶのが設計だと思います。今回はその「捨てる」を言語化した回でした。
※ 本記事は一開発者の設計メモであり、法的助言ではありません。公的個人認証やデジタル認証アプリの制度・手数料・契約条件は時点や運用で変わるため、実際に検討する際は必ず公式の最新情報をご確認ください。
コメントを残す