身分証の検証を用いた身元確認/当人認証を意識してみよう

(4/14 表記揺れなどのコメントいただいたので、少し修正、追記しました。)

ritouです。

私のタイムラインによく出てくる、この辺りの話っていつになってもしっくりこない人が多いと思います。

• OAuth認証👮 : アプリケーションがユーザー情報取得を提供するAPIを叩いて受け取ったユーザー識別子を使って新規登録やログインさせてはいけない。OIDCのIDTokenを使え
  • ユーザーIDが取得できればログインさせていいのではないか
  • IDTokenはユーザーIDを含むJWTだが、どうしてこれは良いのか
• デジタル庁が進めるマイナンバーカードを用いた個人向け認証アプリケーション(以下、認証スーパーアプリ)の用途
  • マイナンバーカードを用いた本人確認は既にいくつかの民間サービスで使われているが、ログインに使えるとはどういう事なのか
  • デジタル庁からは スマホ用電子証明書搭載サービス　という物も出ているが、関連は？

この辺りをスッキリさせるために、今回はタイトルにした 身分証(Identity Document)の検証を用いた身元確認(Identity Proofing)/当人認証(Authentication) について理解し、実際のユースケースでもこれを意識して見ていきましょう。

身分証/⚪︎⚪︎証明書(Identity Document)

IDといえば、Identifier(識別子)、Identity(属性情報の集合) などコンテキストを複数持っていることが知られていますが、これ以外ではいわゆる「(身分証の意味での)IDを見せてください」という文脈で使われる「Identity Document」も ID の一つです。

Digital Identityな文脈では以下のものがIdentity Documentに当たるでしょう。
記載されている情報に注目してみます。

• OIDCのIDToken
  • Issuer: Identity Provider
  • Audience: Relying Party
  • Subject: エンドユーザーの識別子
  • Attributes: エンドユーザーの属性情報
• (JPKIではないタイプの)eKYCで提出される各種証明書
  • Issuer: 証明書の発行元
  • Subject: 証明書自体の番号
  • Attributes: 証明書の対象となる属性情報
• マイナンバーカードの利用者証明用電子証明書には2種類存在、スマホ版もある
  • 電子証明書
  • スマホ用電子証明書

なるほど、IDTokenのIDって...ってなりましたか？
マイナンバーカードの2種類の証明書というのも気になりますね。
これらをどのように利用するかを考えてみましょう。

身元確認(Identity Proofing)

身元確認で何をしているかというと、ユーザーの属性情報の確認です。
よく行われている身元確認の例を見てみましょう。

• メールアドレス確認、SMS認証(): ユーザーが申告したメールアドレス、SMS番号の所有者であることを確認
• OIDCのIDTokenに含まれる確認済みメールアドレスを用いたメールアドレス確認のスキップ: IdPから受け取ったメールアドレスとそのメールアドレスが確認済みであるという情報を利用
• 免許証などの証明書画像+αを用いたeKYC(主に犯罪収益移転防止法が意識されているもの): ユーザーが申告した氏名、生年月日、住所などが正しいことを確認する。証明書自体の画像以外にセルフィーやカードを持った画像、動画を提出する
• 公的個人認証サービス(JPKI)を用いたeKYC: 暗証番号を入力し、マイナンバーカードのICカードのチップを読み取りもしくはスマートフォン内のマイナンバーカード情報を読み取り

一番最初の例は、サービスとユーザーしか登場人物がいませんし、Identity Documentは出てこないのでとりあえずおいておきましょう。ただこれもとてもライトな身元確認の一つと言えます。
OIDCの例では、認証フローを安全に実装することで、IdPのユーザーと今サービスを利用しているユーザーの紐付けができる状態 となります。そのため、Identity Documentの検証が済んだら確認済み情報を今サービスを利用しようとしているユーザーの属性情報として取り扱える状態になります。
一方、eKYCではIdentity Document自体の検証だけでは証明書の所有者と今サービスを利用しているユーザーの一致が確認できません。 そのため、証明書を持った画像や動画などで一致を確認する必要があるわけです。
JPKIを用いたeKYCでは署名用電子証明書がIdentity Documentに相当します。 氏名、住所、生年月日、性別の4情報が記載されていることでその属性情報が確認済みであるとして扱えます。 カード読み取りのみでOK！スマホの中の情報を使うのでカード読み取りさえも不要！というのはここから来ているわけですね。

https://www.jpki.go.jp/faq/word.html#:~:text=署名用電子証明書,用いて暗号化します。

認証スーパーアプリでもこのあたりの仕組みを利用し、民間サービスが身元確認に利用できることを実現しようとしているのでしょう(具体的なところは調達仕様書を探せない状態のようなので確認できません)

当人認証(Authentication)

いわゆる「ログイン」に利用することを考えてみましょう。

OIDCではIdentity DocumentのSubjectがIdPのユーザー識別子です。
IdP上でログイン状態であるユーザーとIdentity Ducumentが紐付いているので、それを検証した上でさらにそのユーザー識別子と紐付けられたサービスのユーザーでログインできるわけです。サービス側のユーザーと紐付けられていない場合、新規登録に誘導するなども一般的ですね。

同様のしくみでいうと、パスキーで利用されるAssertionでは事前に保存しておいた公開鍵の識別子が含まれており、かつ検証可能です。その点では、これも認証器が発行したIdentity Documentと言えそうです。

え？SAML？

https://twitter.com/ritou/status/1777509830867210381

マイナンバーカードに関する部分では、身元確認のための署名用電子証明書とは別で、利用者証明用電子証明書というのがサービスの当人認証のために用意されています。 マイナポータルにてマイナンバーカードでログインを実現するために使われています。

https://faq.myna.go.jp/faq/show/3494

認証スーパーアプリではサービスがこの証明書情報を検証可能になることと同等の機能を実現できるように、OIDCのプロトコルに乗せて実装されることになるのでしょう(こちらも具体的なところは調達仕様書を探せない状態のようなので確認できません)。

まとめ

今回は身分証、なんとか証明書を用いて身元確認、当人認証を実現する際に何が検証されているか、そして一般的なユースケースではどうなっているかに触れてみました。

画像を使った身元確認では、証明書自体の検証精度、証明書の対象となる人物とサービスの利用者の一致の確認精度に課題があります。そのせいで、某氏に「なんちゃってeKYC」と呼ばれてしまうのです。犯収法・携帯電話不正利用防止法に基づく本人確認手法は、マイナンバーカードを使った公的個人認証サービス（JPKI）に原則一本化していく という流れとなっていることも認識しておきましょう。

当人認証でいうと、わりと多くの開発者がOAuth認証()に最終的にユーザー識別子がとれりゃあ良いんだよ的な考えになってしまうことも多く、その意識を変えるのはなかなか困難です。最近はパスキーをはじめとする秘密鍵/公開鍵を用いた署名生成、検証の仕組みを利用する認証方式が出てきていますし、OIDCのIDTokenもIdentity Document相当のものであることを意識しておくと今後新しい方法が出てきた時の理解や真っ当なものかどうかの判断ができるようになるでしょう。

今回紹介した方法を意識することで身元確認と当人認証の違い、なぜOAuthではなくOIDCを利用すべきなのか、認証スーパーアプリでなぜ身元確認と当人認証両方ができると言われているのかを理解できるようになるかもしれません。こういった観点をたくさん持って解像度を上げていきましょう。

ではまた。