デジタル庁認証アプリ FIRST IMPRESSION まとめ

昨夜(6月21日)午後11時より、YouTube Live で「デジタル庁認証アプリ FIRST IMPRESSION」と題して配信を行いました。デジタル庁が同日発表したデジタル認証アプリについて、一緒にドキュメントを読んで、その内容や課題などを洗い出していきましょうという企画です。夕方にゆるい感じでアナウンスして、トークデッキの準備も間に合わず見切りで始めたにも関わらず、デジタル庁の幹部の方なども含めて、最大94名の方が同時アクセスしていただきました。ご参加いただいた方々に深く御礼申し上げます。アーカイブは以下から見ることができます。YouTubeに遷移してみること推奨です。チャットに多くの情報がありますので。以下、AI1によるまとめと、それに書き加えた覚えている限りのメモです。そのうち見返して追記するかも知れません。

しかし、こうして見返してみると、署名の話を飛ばしてしまいましたね。これはまた別途…

【資料】

要約

このLive配信の動画では、デジタル庁が新しく発表したマイナンバーカードを使ったデジタル認証アプリについて議論しています。このアプリを使うと、ECサイトやネットバンキング、公共施設の予約などで簡単にオンライン本人確認ができるようになります。アプリの利用登録方法、認証の流れ、APIリファレンスなどの技術的な側面について詳しく説明されています。また、プライバシーポリシーやセキュリティ、個人情報の取り扱いについても触れられています。

キーポイント

00:00:08 はじめに

動画の冒頭で、デジタル庁が新しくリリースしたマイナンバーカードを使ったデジタル認証アプリについて話し合うことが説明されています。このアプリを使えば、ECサイトやネットバンキングでの本人確認が簡単にできるようになります。

00:01:00 アプリの概要

デジタル認証アプリの主な利用シーンとして、ECサイトやネットバンキングのログイン時の本人確認、公共施設やシェアリングサービスのオンライン予約、年齢確認、オンライン本人確認などが挙げられています。民間企業や官公庁を問わず、幅広い分野で利用できるアプリとなっています。

00:06:23 利用登録の方法

アプリを利用するには、まずデジタル認証アプリをダウンロードし、利用規約とプライバシーポリシーを確認する必要があります。その後、端末認証の設定、マイナンバーカードと暗証番号の入力、マイナンバーカードの読み取りを行い、利用登録が完了します。利用登録の必要性についてはチャット欄で疑問の声もあがっています。

  • なぜこの登録が必要なのかという疑問が配信の中では呈された。例えば後程CIBAとかで使うというならわかるが、そうなっていない。
    • これに対して、別のコメントで、新旧のシリアル番号がわかるようにしてPPIDを維持するようだとの指摘があった。5

00:10:09 認証の流れ

認証の流れとしては、まずサービスからデジタル認証アプリが立ち上がり、ユーザーが認証用証明書で認証を行います。その後、利用中のサービスに戻ります。この流れは標準的なOpenID Connectの流れに従っています。クロスデバイス認証の場合は、QRコードを読み取ってデバイス間をリンクする必要があります。

  • 認証の流れは、OpenID Connect Core6 + OpenID Connect Session Management7+ PKCE[RFC7646]8認証アプリを立ち上げるのは、デジタル庁のOpenID Provider。RPとアプリは直接やりとりはしない。
  • クロスデバイス認証の場合は、QRコードを読み取ってデバイス間をリンクする。
  • アプリ立ち上げ時に生体認証が入るが、これは必要なのかとの疑義あり。
  • 属性の提供の可否は、全部了承するか全部否定するかの二択。

00:25:57 APIリファレンスと技術的な側面

APIリファレンスやOpenID Connect設定、JWTの使用、セキュリティベストプラクティスの適用状況などの技術的な側面についても説明されています。一部の設定の位置や、セッション管理の扱いなどが標準的な実装と異なる点が指摘されています。

  • 使っている仕様としては、OpenID Connect Core + Discovery9 + Session Management + PKCE, OpenID Connect Backchannel Logout10, OAuth 2.0 Framework[RFC6749]11[RFC6750]12, JWT[RFC7519]13, JWK[RFC7517]14
  • 署名のインターフェースは独自のリソースサーバ。この辺りは標準に付して欲しい。
    • (事後の感想:ETSIのリモート署名の仕様とかに実はあっているとかあるんだろうか?)
  • ユーザの識別子としてはPPIDを使っているため、RP同士で結託しても、他の属性を取得していなければ名寄せできない。このPPIDは証明書が変わっても維持される模様。
  • PPIDはRP毎に一人一つになるので、お一人様一個限りのクーポンやチケットの発行にも使える。巷の記事では券面アプリの情報を使えばと言うようなはなしもあるがそれは要らないし取得情報最小化の原則からしたら取らないほうが良い。
  • ドキュメントに書いてあるopenid-configurationの場所が間違っている。正しくは、https://auth-and-sign.go.jp/api/realms/main/.well-known/openid-configuration で、/api/ が抜けている。
  • .well-known をドメイン直下ではなく、/api/realms/main/ の下に置くのは、標準と異なる。(RFC578515ではドメイン直下に置くことになっている。)なので、これはwell-knownでは無い。KeyCloakがこうなっているという指摘あり16
  • openid-configuration の中に入っている独自スコープ「user_certificate_history」が気になるという指摘あり。
  • 認証強度はaal3
  • クライアント認証はprivate key JWT.
  • APIリファレンス(民間事業者向け、行政機関向け)を見ると、Access Token、Refresh Token ともにJWTになっている。特にRefresh Tokenに関しては今からでもやめた方が良いという指摘あり。

00:40:56 プライバシーとセキュリティ

プライバシーポリシーでは、個人情報の取り扱いや保持期間、安全対策などが説明されています。認証APIで取得する基本4情報は1時間で削除されますが、セッション情報などは一定期間保持される可能性があります。個人を特定できるPPIDの扱いについても議論されています。

プライバシーについて

  • プライバシーポリシーはテキストベタ打ちで読みにくい。JIS X 925217 などで推奨しているように表形式などで表してほしい。せっかく経産省のガイドラインを元に作った国際基準 ISO/IEC 29184 の日本語版なのだから。
  • 独立したプライバシーポリシーとしてみると、開示・訂正・削除手続きなどが記載されておらず、デジタル庁全体のプライバシーポリシーと合わせないと全貌がわからないのは不親切。JIS X 9252 でもスマートフォン・プライバシー・イニシアチブでも、アプリのプライバシーポリシーにまとめて書くことを推奨している。
  • 基本4情報が1時間で削除されるということはFAQに乗っており、プライバシーポリシーには「一定時間」という記載のみがある。基本4情報以外の情報がどれくらい保持されるのかはよくわからない。
  • ここで払い出されるPPIDは個人データ。PPIDは個人情報では無いという「偉い人」もいるようだが間違い。

セキュリティについて

  • RFC911618で規定されている security.txt も現在存在していない。
  • QRコードと6桁の数字で認証デバイス(Authentication Device)と利用デバイス(Consumption Device)とをリンクさせるのが安全なのかはもう少しちゃんと検討しないとわからない。OpenID for Verifiable Credential の発行においてQRコードの利用のところがセキュリティ的に問題があることは、Formal Analysisの結果わかっているので、それとちゃんと比較してみるのが良い。
  • このリンクのところは、せっかくアプリを登録させているのだから、CIBAを使うなどのやりようはあったような。
  • OpenID Connect Core + PKCE で、FAPIにはなっていない。OAuth Security Best Current Practice19 との比較はやってみると良い。
  • (配信で言い忘れた点)スマホアプリをデジタル庁のバックエンドがどう認証するのかがよく解からない。この辺も情報公開してほしい。

配信実施上の反省点

技術上の気付き

今回はWebカメラ配信というYouTubeの機能を使ってやってみた。カメラはmmhmmを利用して画面も共有しながらやった。マシンは、いつもは MacBook Pro (M1Pro)を使っているが、今回はM2 MacBook Air を使ってやってみた。その結果、いくつか反省点や気付きが出てきた。

  • マシンが非力なのか動画がカクカクする。途中からはサーマルスロットリングもかかったようで、手元の操作もカクカクした。M1ProのMacBook Proでやった方がスムースそうだ。
  • OBSを使わないでやれるのは手軽だが、チャット画面を画面に映せないのはちょっと寂しい。
  • 意外と2画面しか出せないのは気にならなかった。(OBS分必要な画面が減っているせいかな)
  • 音声はこの構成でも普通に通る。
  • Webカメラを使ってやると、画面に映した書類を読んだりするときにドアップになってしまって見苦しい。アバターでやった方が良さそう。

内容上の気付き

  • いくら時間がなくても、トークデッキくらいは用意しよう。話すはずだったことを色々忘れてしまった。
    • アプリ部分のクライアント認証
    • eKYC&IDAの話
    • ある意味マイナンバーカードをClaims Source とした Aggregated Claims モデルだよねという話 など
  • やって見ると、コメント欄の有識者の方々から多くの情報が寄せられて、事前の予想以上に個人的に収穫が多かった。
  • 参加者はリンクをコメントに貼ることができないけれども、自分は貼れるのだから、このページを見てみましょう、みたいにコメントにリンクを貼れば良かった。

参考になりそうな資料

以下、配信とは関係ありませんが、参考になりそうな資料を随時追加していきます。

技術的な分析記事

報道など

Xなどより

(更新履歴)

  • 2024-06-22 初版
  • 2024-06-23
    • JIS X 9252 であるべきところを JIS X 9250 と書いていたの訂正
    • 参考になりそうな資料を追加
    • 引用している規格についてリファレンスを挿入
  • 2024-06-24
    • X上のkokumin_aさんの調達仕様書に関する指摘を収録

脚注

  1. https://www.notta.ai/
  2. デジタル庁 (2024) デジタル認証アプリサービスサイト. https://services.digital.go.jp/auth-and-sign/ (2024-06-21取得)
  3. デジタル庁(2024) デジタル庁開発者サイト. https://developers.digital.go.jp/ (2024-06-21取得)
  4. 小山安博 (2024)『デジタル庁「認証アプリ」が目指す「オンライン本人確認の基盤」』Impress Watch
  5. デジタル認証アプリの利用者登録の中で、新旧シリアル番号を紐付けてID管理DBに登録するフローが調達仕様書に書いてあったようです。from https://x.com/kokumin_a/status/1804778856689160447
  6. Sakimura, et al. (2023) OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-core-1_0.html (2024-06-21取得)
  7. de Madeiros, et al. (2022) OpenID Connect Session Management 1.0. OpenID Foundation. https://openid.net/specs/openid-connect-session-1_0.html (2024-06-21取得)
  8. Sakimura, et al. (2015). RFC7636 Proof Key for Code Exchange by OAuth Public Clients. IETF. https://datatracker.ietf.org/doc/html/rfc7636 (2024-06-21取得)。
  9. Sakimura, et al. (2023). OpenID Connect Discovery 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-discovery-1_0.html. (2024-06-21取得)
  10. Jones, et al. (2023). OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1. OpenID Foundation. https://openid.net/specs/openid-connect-backchannel-1_0.html (2024-06-21取得)
  11. Hardt, et al.(2012) RFC6749 The OAuth 2.0 Authorization Framework. IETF. https://datatracker.ietf.org/doc/html/rfc6749 (2024-06-21取得)
  12. Jones, et al. (2012) The OAuth 2.0 Authorization Framework: Bearer Token Usage. IETF. https://datatracker.ietf.org/doc/html/rfc6750. (2024-06-21取得)
  13. Jones, et al. (2015). JSON Web Token (JWT). IETF. https://datatracker.ietf.org/doc/html/rfc7519
  14. Jones. (2015). JSON Web Key (JWK). IETF. https://datatracker.ietf.org/doc/html/rfc7517
  15. Nottingham. (2010). Defining Well-Known Uniform Resource Identifiers (URIs). IETF. https://datatracker.ietf.org/doc/html/rfc5785 (2024-06-21取得)
  16. KeycloakのAdmin REST APIでレルムを作成してみる。 https://blog.linkode.co.jp/entry/2023/08/22/161335 (2024-06-21取得)
  17. JIS X 9252:2023 情報技術―オンラインにおけるプライバシーに関する通知及び同意https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+X+9252%3A2023. なお、オンラインでの閲覧は無料です。https://jisc.go.jp/app/jis/general/GnrJISSearch.html… から「X9252」で検索して閲覧できます。
  18. Foudil. (2022). RFC9116 A File Format to Aid in Security Vulnerability Disclosure. IETF. https://datatracker.ietf.org/doc/html/rfc9116
  19. Lodderstedt. (2024). OAuth 2.0 Security Best Current Practice. IETF. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics (2024-06-21取得)

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください