こんばんは、ritouです。
Digital Identity技術勉強会 #iddance Advent Calendar 2020 15日めの記事です。
何の話か?
このプレスリリース、ニュースを覚えていますでしょうか。
事業者が同APIを導入すると、利用者にマイナンバー提出をリクエストすることが可能となります。それを受けた利用者は、PINコードを入力、もしくは生体認証（指紋または顔認証）した後、マイナンバーカードのQRコードをスマホで読み取り、そしてカード本体をNFCで読み取るだけで瞬時にマイナンバーを提出することができます。
とあります。これはこれで "瞬時にマイナンバーを提出"とはどの部分にかかってるのかが気になる文章ではありますが、xIDのサイトにも説明があります。
今日はこのマイナンバー要求APIの仕組みを標準化仕様、既存の技術を組み合わせて作るとしたらどんな感じかと言うところを考えてみます。
マイナンバー要求APIのフローを理解する
上述のサービスに概要が書かれております。
(引用元 : https://my-number.x-id.me/)
xIDアプリでやることっていうのがこの図ですね。
(引用元 : https://www.jiji.com/jc/article?k=000000023.000037505&g=prt)
これを5つの処理に分解しましょう。
- サービスからのマイナンバーリクエスト : 属性情報要求
- ユーザーへの通知、確認コード選択 : ユーザーへの通知
- PIN or 生体認証 : ユーザー認証
- マイナンバー入力 or QR読み通り + マイナンバーカード読み取り : マイナンバー取り扱いのためのお約束
- 暗号化して送信 : 属性情報応答
で、それぞれの処理に標準化仕様をあてはめてみましょう。
- 社内のマイナンバー登録フローみたいなのに入り、サービスはこのユーザーのマイナンバーが欲しいとxIDに要求、ユーザーには確認コードを表示 : →CIBA
- xIDはアプリへの通知を用いて「サービスがマイナンバーを欲しがってるよ」と通知、ユーザーは表示された確認コードと一致するものを選択 : →CIBA
- 通知を受けたxIDアプリでPINもしくは生体認証を行うことで2FA完了 : →FIDO
- マイナンバーを入力もしくはQR読み取りを行い、さらにマイナンバーカードをNFCで読み取る : →マイナンバー取り扱いのお約束
- xIDアプリで暗号化されたマイナンバーがサービスに返される : →CIBA(w/ JWE?)
1,2,3について、「手元のスマホでログイン」的な流れ、利便性を上げるためにFIDOとの組み合わせ、なんてところは本ブログで何度も扱ってきた通りです。 4の処理については「民間事業者におけるマイナンバーカードの活用」というPDFなどに記載されている券面事項入力補助APを使う際のアクセスコントロールに従っているようです。
https://www.cao.go.jp/bangouseido/pdf/topic_card_minkan.pdf
これの券面事項入力補助APの②で、アクセスコントロールで求められるマイナンバーがその前に入力/QR読み取りってとこか(と教えてもらった) pic.twitter.com/YezVamp34L
— 👹秋田の猫🐱 (@ritou) 2020年12月9日
あとは5のところでモバイルアプリの段階で暗号化して送ってサーバーも見れませんよ！って言えるなら出来上がりでしょう。
CIBA/FIDO で作るマイナンバー要求API
ここまで分解できれば、あとはシーケンス書いてそれぞれの処理を整理しましょう。
登場人物
実際はxIDのアプリの他にxIDのバックエンドサーバーがいるだろうと言うところで、登場人物は4人と言うところでしょうか。
- RP : マイナンバーを要求するサービス
- IdP(Backend) : マイナンバー要求API(xIDのサーバー)
- IdP(MobileApp) : xIDアプリ
- EndUser : マイナンバーカードを保持するユーザー
シーケンス
シーケンスはこんな感じでいけそうです。
それぞれを見ていきましょう。
RPからIdPにマイナンバー要求、受付応答
CIBAにおける、バックチャネル認証リクエストに相当します。
- RPは社員番号、メールアドレスなどを
login_hintなどとして指定 - 確認コードは
binding_messageとして指定
CIBAにはPOLL/PING/PUSHと言ったモードがありますが、ここではPOLLモードを想定し、auth_req_id が返されます。
確認番号の選択
これは以前、手元のスマホでログインみたいなのをCIBAで実現しよう！みたいな記事でも触れた気がしますが、EndUserがこのフローの正しい利用者であることを確認する仕組みとして binding_message をうまく使うことで実現できそうです。
この、3つ表示して1つ選ばせるみたいな部分は結構普通に使いそうなので、CIBAの仕様として組み込んでも良さそうな気はしています。
PIN or 生体認証
xIDアプリは所持 + αの2要素認証をうたっています。 それに相当する仕組みとして、ここでは FIDO を用いることで実現できそうです。
マイナンバーカードのお約束
ここは標準化仕様というよりもガイドライン的なものに従って作る感じですね。
暗号化したマイナンバーのやりとり
この辺りはモバイルアプリでJWE形式にしたIDTokenを生成、もしくはマイナンバーだけを暗号化するなどよしなにしてバックエンドサーバーが復号できない状態とし、RPまで返してやる、そして破棄することで実現できそうです。
まとめ
いかがでしたでしょうか。 ある程度、認証認可周りのプロトコルの理解が進んだ状態であれば、何か新しい仕組みが出てきたときにこんな感じかなーと考えて見ることもできるでしょう。 まぁ実際に実装するとなると細かくいろんなこと決めないといけないんでしょうけど、頭の体操をしてみても面白いのではないでしょうか。
何か気になることがありましたら、匿名でも質問受け付けておりますので気軽にどうぞ！
私のアドカレ次回作は12/25の予定です。
で、その間に会社のやつを20日にQiitaの方に書く予定です。
ではまた！
