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

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

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

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

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（民間を含むサービス）の３パーティモデルを使ってIssuerとVerifierを分離することが有効なのかもしれません。

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