ラベル マイナンバーカード の投稿を表示しています。 すべての投稿を表示
ラベル マイナンバーカード の投稿を表示しています。 すべての投稿を表示

2024年9月15日日曜日

デジタル認証アプリを利用するサービス一覧が更新

こんにちは、富士榮です。


デジタル認証アプリと連携するサービス(事業者)一覧が大幅に更新されています。

https://services.digital.go.jp/auth-and-sign/case-studies/



2024年6月にアプリがリリースされた際は横浜市と三菱UFJ銀行のアプリの2つだけでしたが、この3ヶ月で15個まで増えています。

6月時点のポスト

https://idmlab.eidentity.jp/2024/06/blog-post.html


ざっとみていくと、

  • 事業者や自治体のアプリそのものが連携するパターン
  • 都市OSやIDaaSなどのプラットフォームが連携するパターン
  • 本人確認アプリなど他の事業者アプリから呼び出されるアプリが連携するパターン
に分類されそうです。


短期間で多くのサービスと連携できるようになってきているのは非常に良いことだと思いますが、この辺りに書いたようにアプリの乱立や認証アプリと連携したアプリがあたかもマイナンバーカードそのものを使った本人確認とみなされるようなミスリードが起きないように注意が必要ですね。
マイナンバーカードを読み取るアプリがいっぱい
デジタルクレデンシャルによる「本人確認」と「身元確認」


2024年8月28日水曜日

選択的情報開示とウォレットと本人確認書類

こんにちは、富士榮です。


突然ですが、本人確認書類の電子化をする理由ってなんでしょう。

  • ペーパーレス
  • プラスチックカードの発行費用の削減
  • 機械可読によるビジネスプロセスの最適化

など、頑張れば色々と理由はつけられます。

OpenArtが書いてくれたモバイル本人確認書類。なんか変。


Perplexityにデジタル化の意義について聞いてみたらこんな回答が返ってきました。

質問)

免許証やマイナンバーカードなどの本人確認書類をデジタル化することによるメリットはなんですか?

回答)

デジタル化された本人確認書類には、以下のようなメリットがあります: 

利便性の向上

  • 携帯の容易さ

    • デジタル化された本人確認書類はスマートフォンなどのデバイスに保存できるため、常に携帯することが容易になります。財布や身分証ケースを持ち歩く必要がなくなり、日常生活の利便性が向上します。
  • 迅速な提示
    • 必要な時にすぐに提示できるため、本人確認のプロセスが迅速化されます。デジタル形式であれば、必要な情報を素早く表示したり、関連する証明書を即座に呼び出したりすることが可能になります。

 セキュリティの強化

  • 偽造防止
    • デジタル技術を活用することで、偽造や改ざんを防ぐ高度なセキュリティ機能を実装できます。電子署名や暗号化技術により、従来の紙の書類よりも安全性が向上します。

紛失リスクの低減

  • 物理的な紛失のリスクが軽減されます。デジタル形式であれば、クラウドにバックアップを取ることができ、デバイスを紛失しても復元が容易になります。

行政手続きの効率化

  • オンライン申請の促進
    • デジタル化された本人確認書類があれば、さまざまな行政手続きをオンラインで完結させることが可能になります。例えば、マイナンバーカードを利用すれば、確定申告や各種証明書の取得がオンラインで行えるようになります。

データ連携の容易さ

  • デジタル化により、異なる行政サービス間でのデータ連携が容易になります。これにより、複数の手続きを一度に行ったり、必要な情報を自動的に入力したりすることが可能になり、手続きの効率が大幅に向上します。

環境負荷の低減

  • 物理的な書類の発行や更新が不要になるため、紙の使用量が削減され、環境負荷の低減につながります。また、郵送や窓口での対面手続きが減ることで、移動に伴うCO2排出量も抑えられます。

デジタル化された本人確認書類は、利便性、セキュリティ、行政効率、環境保護など、多岐にわたるメリットをもたらします。ただし、デジタル格差への配慮や、プライバシー保護の徹底など、課題にも適切に対応していく必要があります。


なんだか、想像通りすぎますね。特に後半はデジタル化の意味が違いますね。


追加で質問してみます。

質問)

デジタル化について、デジタイゼーションとデジタライゼーションの違いの観点から説明してください。

回答)

デジタイゼーションとデジタライゼーションは、デジタル化の異なる段階を表す概念です。以下にその違いを説明します:

デジタイゼーション

  • デジタイゼーションは、デジタル化の最初の段階を指します。
  • 定義
    • アナログ形式の情報をデジタル形式に変換する過程です。
  • 特徴
    • 物理的な情報や資料をデジタルデータに変換します。
    • 業務フローの一部をデジタル化することに焦点を当てます。
  • 具体例
    • 紙の書類や本をスキャンして電子ファイル化する
    • 電子契約や電子署名の導入
    • クラウドストレージやオンラインドキュメントによるファイル管理
    • QRコードやバーコードの活用

デジタライゼーション

  • デジタライゼーションは、デジタイゼーションの次の段階を表します。
  • 定義
    • ビジネスプロセス全体をデジタル化し、新たな価値を創出することです。
  • 特徴
    • 組織のビジネスモデル全体を一新します。
    • クライアントやパートナーへのサービス提供方法を改善します。
    • 特定の業務プロセス全体をデジタル化します。
  • 具体例
    • クラウドやAIなどのテクノロジーを導入して業務の自動化や最適化を図る
    • オンラインでの販売やマーケティングを強化する
    • 電子書籍の販売システムの構築
    • 動画共有プラットフォームの運営

 主な違い

  • 対象範囲:

    • デジタイゼーション: 個別の情報や業務フローの一部
    • デジタライゼーション: ビジネスプロセス全体
  • 目的:
    • デジタイゼーション: 情報のデジタル化、業務効率化
    • デジタライゼーション: ビジネスモデルの変革、新たな価値創出
  • 影響度:
    • デジタイゼーション: 局所的な改善
    • デジタライゼーション: 組織全体の変革

デジタイゼーションとデジタライゼーションは、デジタル化の異なる段階を表す概念であり、企業のデジタルトランスフォーメーション(DX)を実現するための重要なステップとなります


こうやってみると本人確認書類のデジタル化はデジタイゼーションとデジタライゼーションが混ぜこぜで語られていそうですね。

まさに崎村さんが言うところの「西用と変法」ですな。 


というか、そもそも運転免許証のデジタル化についてのメリットは「バーに入るとき免許証を全部見せる必要ないですよね。物理免許証だと選択的開示はできないけど、デジタル化すると21歳以上であることだけを示せるようになるんですよ!」ってみなさん言ってましたよね。


カリフォルニア州のモバイル運転免許証(mDL)やっているSpruceIDのWayneもBlogで語ってますよ。


https://blog.spruceid.com/top-5-takeaways-from-getting-started-with-digital-id-a-look-inside-californias-mobile-drivers-license-program/


TBDもそんな説明をしていましたね。。。

そして彼女がパスポートを係員に渡すと、「ああ、私たちは誕生日が同じなんですね!」とか「出身地は美しい島ですよね〜」とか言われてしまいます。

調べた結果VCは「過剰な個人データを明らかにせずに、法定飲酒年齢に達していることを証明する必要があるとします。完全な ID を提示する代わりに、ベンダーに VC を提示することもできます。販売者は資格情報を年齢証明として認識し、引き換えにアルコールを提供します。」 

https://idmlab.eidentity.jp/2024/03/tbdverifiable-credentials.html


たぶん、こう言うアナログではできなかったことが、デジタル化することによってできるようになる、というのがデジタライゼーションでありイノベーションなんだろうなぁ、、と強く思います。


しかし、ちょうど先日カリフォルニア州のモバイル運転免許証がGoogle Walletに搭載できるようになった、という話も出てきていますしが、Apple WalletやGoogle Walletはスマホ搭載はするものの選択的開示はできなさそうです。

https://www.gov.ca.gov/2024/08/23/californians-can-now-add-their-mobile-drivers-license-to-google-wallet/

例のApple Walletにマイナンバーカードを搭載する件はどうなんでしょうか。。。うーん。


mDoc自体は当然選択的開示をサポートしていて、ISO 18013-5:2021の6.2 Functional requirementsをみると「The interface between the mDL and the mDL reader shall support the selective release of mDL data to an mDL reader.」とあるようにサポートすべし的な記載なんですよねぇ。Presentation要求にOpenID for Verifiable Presentationsを使う場合は属性要求にPresentation Exchangeを使うと思いますが、その場合はinput_descriptorで要求属性なんかもかけるわけで、リーダーというかVerifier側はそう言う実装になっていくんでしょうけど、大前提としてウォレット側が選択するUIを持っていないと片手落ちになってしまいます。自己主権アイデンティティとか言っていた人たちはどう思っているんでしょうか。

まぁ、全員が選択的開示をしたいわけではないので、これまで通りデジタイズされた免許証を使ったりマイナンバーカードを使う人がいてもいいとは思います。ただ、重要なのは「選択肢」だと思います。

今回Google WalletやApple Wallet「にも」搭載できるようになったカリフォルニア州の運転免許証はそもそもSpruceIDのウォレットに搭載されてきていました。つまり、選択的開示できるウォレットも選択肢として残されているわけです。

一方でマイナンバーカードは先にApple Walletへの搭載に関する情報が出てきてしまったので、今から別アプリが出てきても使う側のモチベーションを選択的開示一本で向かわせるのはなかなか難しいだろうなぁ、、と思います。

政治的に色々とあったんでしょうけど、戦略的にこの辺りの情報の出し方を考えていけたらよかったですね・・・

2024年8月25日日曜日

犯罪収益移転防止法施行規則の改正に関するパブコメが募集されています

こんにちは、富士榮です。

警察庁から犯収法(施行規則)の改正に関するパブコメ募集が始まっています。
期間は8月23日〜9月24日ですので、KYCとか本人確認に関与している人たちはコメントしましょう。



中を軽く見てみると「マイナンバー法等の改正等に伴う犯収規則等の改正」となっているので、ざっくりいうと、令和6年12月2日施行のマイナンバー法の改正で
  • 1歳に満たない人のマイナンバーカードへの顔写真が表示されなくなること
  • 健康保険証や公務員共済組合の組合員証などが廃止されること
  • 医療機関で電子資格確認を受けられない(ありていに行ってマイナンバーカードを持っていない人)に対して資格証明が発行されること
を受けて、また他にも、
  • 在留カード、特別永住者証明書(16歳未満への交付時)
  • 精神障害者保護福祉手帳
  • 外国人登録証明書(の一部)
など顔写真が表示されない本人確認書類が存在すること、また
  • 令和6年能登半島地震にかかる本人特定事項の確認方法等に関する特例の廃止
を受けて犯収法施行規則の改正を行う、という話です。

主に第七条(本人確認書類の区分)を整理するための改正ですね。

ただ、せっかくなので対面での本人確認(当人認証)を行うために必要な顔写真がない場合への対応まで踏み込んでいけるといいですね。




2024年8月24日土曜日

マイナンバーカードを読み取るアプリがいっぱい

こんにちは、富士榮です。

デジタル庁からマイナンバーカード対面本人確認アプリがリリースされましたね。


そういえばこの手のアプリって大量に出回っている感覚があったのでAppleのAppStoreを探索してみました。

いっぱい出てきた・・・(順番などに他意はありません。適当に探索したのでカバーできているわけもありません。XX Payなどアプリの中の一機能になっているものは拾っていません)
アプリ名Copyright概要
マイナンバーカード対面確認アプリデジタル庁デジタル庁謹製のマイナンバーカード確認アプリ
マイナチェッカーLEGAL PROMPT INC.券面情報の読み取りアプリ
マイナンバーカード読み取り練習アプリHideki Kariyaマイナンバーカードの読み取りを練習するアプリ
OKBマイナンバーカード本人確認アプリTOPPAN Edge Inc.大垣共立銀行の手続きに利用する本人確認アプリ
北陸銀行本人確認アプリTOPPAN Edge Inc.北陸銀行の手続きに利用する本人確認アプリ
Speed Letter Plus本人確認アプリTOPPAN Edge Inc.通知物電子送付サービス「Speed Letter Plus」に利用する本人確認アプリ
南牧村本人確認アプリTOPPAN Edge Inc.みなみまきパスポートの手続きに利用する本人確認アプリ
LIQUID eKYC株式会社LiquidLiquid社が提供する汎用本人確認アプリ
ProTechマイナンバーIC認証Showcase IncProTechマイナンバーIC認証を利用しているWebサイトで利用する認証アプリ
本人確認アプリD-ConfiaDouble Standard InceKYCアプリ。足立区で使われている?
JPKI利用者ソフトJ-LISJ-LIS純正のマイナンバーカードの電子証明書利用機能提供アプリ
JPKI暗証番号リセットJ-LISマイナンバーカードのパスワードを初期化・リセットするアプリ
IDリーダーOSSTech CorporationOSSTech社が提供するIDカード読み取りアプリ
IAM<アイアム>ShiftPlus IncShiftPlus社が提供する汎用本人確認アプリ
電子認証マイナサインCYBERLINKS CO.,LTD.電子署名、券面情報取得を行うアプリ
本人確認アプリeKYCCYBERLINKS CO.,LTD.eKYCアプリ
マイナトラスト電子署名CYBERLINKS CO.,LTD.電子署名アプリ
マイナポータルデジタル庁言わずと知れたマイナポータルアプリ
デジタル認証アプリデジタル庁言わずと知れたデジタル庁認証アプリ
マイナポイント総務省言わずと知れたマイナポイントアプリ
PDFにマイナンバーカードでJPKI電子署名二進合同会社PDFに署名するアプリ
eKYC本人確認アプリsho@99zz.neteKYCアプリ
都市OS共通サービス(マイナンバーカード共通機能)Hitachi, Ltd日立の都市OS用の本人確認アプリ
クロスアイディxID Inc.xID社が提供する汎用本人確認アプリ
TRUSTDOCKTRUSTDOCK INCTrustdock社が提供する汎用本人確認アプリ
e-Probatio本人確認アプリNTTビジネスソリューションズNTTビジネスソリューションズが提供する汎用本人確認アプリ
e-NINSHO本人確認サービスNRINRIが提供するe-NINSHOサービスの本人確認アプリ
e-NINSHO公的個人認証アプリNRINRIが提供するe-NINSHOサービスの公的個人認証アプリ
日司連公的個人認証有効性確認システム日本司法書士連合会マイナンバーカードの券面情報の取得と有効性確認を行うアプリ
当事者型電子署名システム日本司法書士連合会電子署名を行うアプリ
Great eKYCTREASURY INCeKYCアプリ
マイナPocketNTTデータマイナンバーの申告・本人確認に使うアプリ
ジャスミーPDL本人確認サービスJASMY本人確認アプリ
本人確認情報提出アプリBIPROGYスマートシティ(Dot to Dot)の本人確認アプリ
スマートライフパス本人確認アプリTOPPANSmart Life Passのユーザ登録時の本人確認アプリ
NAWABARI eKYCアプリNAWABARIネットショップの住所に使えるサービスの本人確認アプリ
めぶくIDmy FinTech inc汎用デジタルID
YSD公的個人認証アプリヤマトシステム開発ヤマトシステム開発が提供する証明書類Web取得サービス用の公的個人認証アプリ
RSSモバイルLEGAL Corporation電子署名アプリ

どうするんでしょうね。


2024年8月14日水曜日

デジタルクレデンシャルによる「本人確認」と「身元確認」

こんにちは、富士榮です。

「クレデンシャル」という言葉も色々と定義がブレブレだという大きな課題はあるものの、さまざまな証明書をデジタル化(クレデンシャル化)するムーブメントの中では更にわけがわからないことになってきていますので、そろそろ定義をちゃんとしていかないといけない時期にきているわけです。

OpenArtに「Digital Credential, National ID」と入れたら生成された画像


例えば、マイナンバーカードをスマホ搭載した場合のmDocは本人確認書類として利用できるデジタルクレデンシャル、という位置付けとされていますが、マイナンバーカードを使って本人確認された情報をVerifiable Credentialとして発行したものも同じように本人確認書類として利用できるかのように表現されてしまっているのは本当に大丈夫なのか?という話はその典型だと思います。また、学修歴や資格試験の合格証のデジタル化のように本来は「資格を有していることを証明するもの」を使って「認証」をしてしまうようなケースまで出てきてしまっているのも気になるところです。まるでアクセストークンを使って認証を行う「OAuth認証」の悪夢が再び繰り返されているかのようです。

ということで、今日は
  • いわゆる”本人確認VC”などを本人確認に利用することはできるのか?
  • デジタルクレデンシャルを本人確認に用いるための要件は何か?
を見ていきましょう。


そもそも「本人確認」とは?

経済産業省「オンラインサービスにおける身元確認に関する研究会」並びに、その後OpenIDファウンデーションジャパンが公開した「民間事業者向けの業界横断的なデジタル本人確認のガイドライン」において、本人確認は「身元確認」と「当人認証」の2つの要素で構成されるという整理をしています。つまり当該のエンティティについて「実在していること」と「当人性」が確認できることを指しているわけです。

身元確認

先のガイドラインでは身元確認の目的を「実在性を確認すること」である、と定義しています。
  • 本⼈確認書類を確認する等により、「実在性」を確認することであり、⼀般的にはユーザー登録等が該当します。
  • ここでの実在性は、1) 集められた属性によって当該⺟集団の中でそれぞれの要素を区別することができ、2) 申請者が実在し、3) 申請された属性の値が正しく、4) その属性が申請者に関するものであること、によって確認される。

当人認証

同じくガイドラインでは当人認証の目的を「当人性を確認すること」である、と定義しています。要するにログイン時の認証ですね。
  • あらかじめ登録されているパスワードや⽣体情報等と⼿続を⾏う際に⼊⼒されたパスワードや⽣体情報等を照合する等により、「当⼈性」を確認することであり、⼀般的にはログインが該当します。

デジタル化されたクレデンシャルによる「身元確認」

さてさて、ここまで見てきたところによると、「本人確認書類」を使って本人確認を構成する要素の一つである「身元確認」を行って「実在性」を確認するということでした。
ということはデジタル化されたクレデンシャル(mDocやVC)を本人確認書類として使って「実在性」の確認ができれば良い、というのがミニマムな要件になりそうです。
ここで言う「実在性」とは住民基本台帳など権威あるデータベースに当人に関する情報が確かに記録されていることを指しています。こうなるとクレデンシャルに記載されている情報と住民基本台帳に記載されている情報を一意にマッチングできることが必要となります。
最低限、このくらいの要件がありそうです。
  • 偽造されていないこと
  • 同姓同名を含め一意に識別できること
  • 住民基本台帳側の情報更新に追従できていること
こうなると、マイナンバーカードを使って身元確認した結果を使った”本人確認VC”では身元確認はできなくなってきそうです。少なくとも民間事業者が管理するIDでしかない場合においては住民基本台帳上の情報とのマッチングを確実に実施することは不可能ですし、有効性確認APIを使ったとしても住民基本台帳側の更新と完全に同期を取るのは難しいはずです。
(結局、マイナンバーカードのコピーを使って身元確認はできないですよね、という話だと思います)
つまり、結局はマイナンバーカードと同列で政府がデジタルクレデンシャルを発行し、管理している状態でないと日本国民という「身元」を確認するための「身元確認」に使う「本人確認書類」としての要件を満たすことはできない、ということになりそうです。

同様に、実在性確認のスコープが企業内や学校内に「実在」することを確認する、という話であったとしても、当該の企業や学校などの組織が発行した(委託先が発行するケースはもちろんあり得る)デジタルクレデンシャルでないと「本人確認書類」としては使えない、という話になります。

デジタル化されたクレデンシャルによる「本人確認」

一方で、デジタル化されたクレデンシャル(mDocやVC)を使って「本人確認」つまり「実在性」+「当人性」の確認を行う、ということを考えるとどうでしょうか?実は世の中で言われている”本人確認VC”などのワードを見る限りで言うと、先に述べたような身元確認以上のことをデジタルクレデンシャルを使ってやってしまえる、というイメージを植え付けてしまっている(言っている側が正しく理解できていない、もしくは敢えて混ぜで話している)ケースが多いのではないか?と感じています。

さきに見てきたように、本人確認書類として利用できる状態のクレデンシャルであれば「実在性確認」ができる、つまり「身元確認」はできることはわかりました。追加で考えなければいけないのは「当人性の確認」が当該のクレデンシャルで実施できるかどうか?という点です。

つまり、当該のクレデンシャルを行使しているのが、当該クレデンシャルのサブジェクトと一致している「当人」であることを確認する必要となります。
そのためには、
  • クレデンシャルを当人以外行使できない仕掛けが存在している
  • 検証者が客観的に見てクレデンシャルのサブジェクトと行使者が一致していることを検証できるだけの情報がクレデンシャルに含まれている
などの要件が出てきます。

一般にクレデンシャルを当人以外が行使できないようにするためにはウォレットに認証の仕組みを入れたりすることが多いと思いますが、検証者はクレデンシャルの発行先がサブジェクトと一致していることを暗黙的に「信頼」する必要がある点が大きな課題です。何を言っているかと言うと、クレデンシャル発行者がクレデンシャルのサブジェクトが指し示す主体とHolderが一致していることを検証した上でクレデンシャルを発行していることを「期待」するわけです。(簡単に言うと、Aさんの運転免許証をBさんのウォレットに発行していないですよね?ってことです)

これはなかなかハードな話だと思います。そうなると検証者が自身でクレデンシャルのサブジェクトと提示者となるHolderが一致していることを確認する(もしくはできる)ことが大切になります。
具体的には現実世界で行われている、
  • クレデンシャルに埋め込まれた顔写真と提示者の顔が一致していることを確認する(免許証の目視確認)
  • クレデンシャルを使うためのPINを使って認証しないと提示ができないという状態を作る(マイナンバーカードの公的個人認証など)
といった必要が出てきます。

こうなると券面入力補助APを使っている限りは4情報のみしか取得できない(顔情報は取得できない)ので券面APを使うか、公的個人認証APを使わないとダメって話になります。
ますます民間の”本人確認VC”では無理ゲーな話になってきました。

とはいえ

なんだかイノベーションのかけらもない話になってきましたが、結局のところ検証者がどのレベルで本人確認や身元確認をしたいのか次第という話ではあります。
つまり、現実世界のユースケースでも住民票のコピーを使って身元確認をしたり、顔写真のない身分証明書を2つ用意すればコンサート会場に入れたりするわけで、検証者たる事業者はリスクとベネフィットの天秤の世界の中で生きているわけです。
ですので、これを言うと元も子もないのですが「全ては検証する側のビジネス事情次第」ということになってしまうのかと思います。(もちろん法規制がある場合は事業者が勝手に決めるわけにはいきませんが)

結論はなんだ?

ここまでの話で、民間の”本人確認VC”などマイナンバーカードを使って生成・発行したクレデンシャルを本人確認書類として実在性確認をしたり、当人認証をするのは難しい、というテイストになってしまいましたが、結局最後に書いた通り「事業者の事情による」ところが大きいので、デジタルクレデンシャルを使おうとする事業者の皆さんは「どこまでのレベルで」、「何(身元確認、本人確認)」を求めるのか、をしっかりと定義することが重要ってことです。

2024年2月24日土曜日

デジタル認証アプリがやってくる(その後)

こんにちは、富士榮です。

先月、デジタル認証アプリに関連する法令に関するパブコメ募集が出ている件について個人的に考える課題点について書きました。

デジタル認証アプリがやってくる

https://idmlab.eidentity.jp/2024/01/blog-post_28.html 


それなりのPVがあったこともあり、某雑誌社の方からインタビューがあったりもしました。

パブコメの募集が2月末までだったこともあり、コメントをしてみました。

(なお、重要なことですがこの分野は素人なので頓珍漢なコメントをしている可能性も高いです。後述しますが今回のパブコメの対象は認証アプリそのものというよりも法律だったこともあり、私の条文の解釈の仕方はおそらく間違っている可能性が高いです)

ということで個人的解釈に基づく今回のパブコメ募集の中身を深掘りしていきたいと思います。

パブコメの対象は何か? 

はい、ここがおそらく一番重要だと思います。
募集要項にバッチリ書かれています。よく読んでコメントしましょう。
対象は「法令施行規則」ですね。

読んでみます。縦書きPDF・・・


その中のコメントの対象は何か?

対象が法令施行規則だということが分かった上でコメントしてほしいポイントはどこなのか?という点を見ていきましょう。
「命令案」の中に「改正後」として記載されているところに改正したいポイントがわかる様に記載されています。

ここは優しく「概要」という資料に改正のポイントがまとめられていますのでこちらも併せて見ると理解が早まると思います。


要するに、「電子署名等確認業務受託者」に「内閣総理大臣」を加えたいということですね。
なんでこんなことをやっているのか?を紐解くためには「電子署名等確認業務受託者」とはなんなのか、どういう義務を負うのか、について改正対象となる「電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律」を見てみましょう。
こちらで参照できます。

これをみていると結局のところ「電子署名等確認業務受託者」、つまり現状でいう「プラットフォーム事業者」といわれるJ-LISのサーバに対してアクセスをしてマイナンバーカードの有効性確認等を実施することができる事業者に「個人番号カード用利用者証明用電子証明書」に関して「利用者に関する情報を適切に扱うこと」などを義務付ける法律であることがわかります。


では、なぜ内閣総理大臣を受託事業者に追加するのか?

今回やりたいことは認証アプリの「システム連携イメージ」に記載がある様に、デジタル庁の管理する「デジタル認証アプリサーバ」がJ-LISの管理するJPKIサーバに対してアクセスする、ということです。これは正に現在のプラットフォーム事業者が行なっているマイナンバーカードの有効性確認などと同じ構図となります。

これまでは前述の法律に則って総務省認定を受けた受託事業者のみがJPKIサーバへのアクセスを許可されていたわけですが、上記の図の構成、つまりデジタル庁がJPKIサーバへアクセスしようと思うと根拠法が存在しないわけです。

となると、行政機関の長である内閣総理大臣を受託事業者に加えておかないといけなくなる、とうロジックなんだと思います。


本当にそれでいいのか?どうコメントすべきか?

構図がわかったところでツッコミどころコメントすべき事項を探すわけですが、結局は従来の民間のプラットフォーム事業者と行政機関の差を紐解いていくのがアプローチが良いのではないかと思います。

利用者に関する情報を適正にあつかうこと、という点については民間だろうが行政機関だろうがそうでしょうね、という感じで違和感はないのですが、この利用者に関する情報は一体何を含むんだろうか?という点を見ていくとどうやら法律では「利用者証明利用者符号」を中心に考えているんじゃないかな?と思えてきます。

結局、マイナンバー(カードじゃなく)や証明書シリアルなど、背番号制度に関するアレルギーが意味不明に強い日本では符号や識別子に関しては非常に慎重に扱われる傾向にありますが、行政機関においては識別子についてはそもそも扱う前提があるんじゃなかったっけ?民間事業者が扱うことになるから認定制度があるんじゃなかったっけ?というところに行き着きます。

むしろ前回のポストでも記載した通り行政機関がやるから気持ち悪いポイントは公共・準公共・民間という異なるコンテキストを横断的に政府のIdentity Providerがまとめてフェデレーションをする、つまりデジタル庁の認証アプリサーバから見て利用者がどのRelying PartyとID連携しているのかがわかってしまう、という点にあるはずです。これはIdentity Providerを実装したことがある人ならわかると思いますが、利用者がどのRelying Partyに対して属性提供について同意しているかの状態を保持したり、PPIDを生成するための連携状態を保持したり、とログを含むとそれなりにID連携状態の情報を持つ必要が出てきてしまいます。

こうなってくるとこの法令施行規則に関する改正のポイントが受託事業者の対象に内閣総理大臣を加えることでプラットフォーム事業者と同じことをデジタル庁ができる様になりますよ、だけでは少々不足していると思われるので、法令改正対象には少なくとも「符号などに関する情報の適正な管理」だけでなく「ログを含むID連携状態の適正な管理」を求めていかないといけないのではないか?というのが現時点での私の結論です。

とりあえずそんな主旨でコメントはしてみたので、今後どうなっていくかは注視していきたいと思います。








2024年1月28日日曜日

デジタル認証アプリがやってくる

こんにちは、富士榮です。


噂のデジタル認証アプリですが、パブコメが出てますね。

電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律施行規則の一部を改正する命令案に対する意見募集について

https://public-comment.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=290310311&Mode=0

2月末までの募集のようなのでぜひ皆さんみておくと良いと思います。

ざっくり見てみたいと思います。色々と課題もありそうです・・・

概要

OpenID Connect/OAuth2.0もちゃんと採用されていますね。


サービス提供領域

個人的に一番気になっていた民間PF事業者との棲み分けにについても記載されていますね。

準公共サービスの範疇をどこにおくのか、で既存事業者とのせめぎ合いがありそうな感じです。

システム構成

しかしながら、このシステムイメージ図を見ると色々と問題点が浮かび上がってきます。

パッと見た感じ普通のID連携モデルです。サービス事業者(先に述べた公共・準公共・民間)がデジタル庁の認証サーバ(OAuthの認可サーバ)に対してクライアント登録をするということになるはずです。このクライアント登録をする段階で公共・準公共・民間の区分で審査をした上で登録していく、という感じで運用していくことになるはずですね。
しかし、そうなると2点問題があるように感じます。

課題はなにか?

  1. 多段フェデレーションへの対応が困難
    • これはID連携モデルだけにとどまらずオンプレミスのActive Directoryフォレストの設計を行う上でも昔から考慮点となっていたところですが、デジタル庁の認可サーバに登録されるクライアントが更にID基盤として実際のサービスとID連携を行なっているケースがありえます。例えば、IDaaSなどのサービスを使っている事業者の場合、デジタル庁にクライアント登録されるのはIDaaSとなり、実際のサービスが登録されるわけではありません。このことにより準公共という触れ込みでデジタル庁に登録されたとしても、その先で民間のサービスとID連携をしてしまっていた、、というケースに対応できなくなります。この辺りはルールで縛りを入れる形になるんだと思いますが
  2. デジタル庁のIdPによる行動把握問題
    • フェデレーションモデルということは利用者(今回の場合はマイナンバーカードを持っている国民)がクライアントとなるサービスを使う都度、デジタル庁のIdPへリダイレクトされることになります。今回のケースではクライアントとなりえる公共・準公共・民間のサービスを認証対象となるユーザが使っていることをデジタル庁のIdPは知ることができる、という状態が発生します。まさにGoogle Knows You Better Than You Know Yourselfならぬ「デジタル庁はあなたよりあなた自身のことを知っている」なんてことになるのでは?という疑念を抱かせないように丁寧な説明が必須になると思います。


この辺りはパブコメだしますかね・・・
こういうユースケースこそVCを使ったIssuer(デジ庁IdP)→Wallet(個人のスマホ)→Verifier(民間を含むサービス)の3パーティモデルを使ってIssuerとVerifierを分離することが有効なのかもしれません。

いずれにしても4月に出てくるということなので楽しみにしておきましょう。