OpenID Connect for Identity Assuranceで本人確認はできる？できない？｜OIDFJ富士榮 × TRUSTDOCK菊池【対談】後編

　2019年11月11日にOpenID Foundationから発表されたOpenID Connect for Identity Assurance（以下、OIDC4IDA）は、具体的にどのようなものでどんなメリットがあり、現時点において本人確認で活用する場合にどんな議題が存在するのか。

　後半も引き続き、OpenIDファウンデーション・ジャパン代表理事である富士榮尚寛氏と、TRUSTDOCK COOの菊池梓の対談から、理解を深めて参りたいと思います。

★本文中の（※）については、最終チャプターの「本記事を読む際の用語集」で概要解説を記述しております（本記事初出時のみ※を記載、※を押すと開設箇所へと変遷します）

》前編記事はこちら

OpenID Connect for Identity Assuranceで本人確認はできる？できない？｜OIDFJ富士榮 × TRUSTDOCK菊池【対談】後編

プロフィール

富士榮尚寛［Naohiro Fujie］
OpenIDファウンデーション・ジャパン 代表理事
OpenID Foundation eKYC and Identity Assurance Working Group Co-chair

デジタルアイデンティティ分野で18年以上の経験を持ち、大手自動車製造業のグローバルID基盤に関するコンサルティング～PMを担当。2018年よりOpenIDファウンデーション・ジャパンの理事、KYC WG・リーダーに就任。2020年1月より米国OpenID FoundationにてeKYC and Identity Assurance Working Groupの設立および共同議長に就任。2021年6月よりOpenIDファウンデーション・ジャパンの代表理事に就任。

菊池梓（Azusa Kikuchi）
株式会社TRUSTDOCK
OpenIDファウンデーション・ジャパン KYCワーキンググループ

TRUSTDOCKの業務執行責任者として、営業支援・プロダクト開発内容の策定・オペレーション関連の顧客折衝・海外事業・海外技術調査等に従事。OpenIDファウンデーション・ジャパンにて、KYCワーキンググループ バインディングとIDライフサイクルのチームリーダーとしても活動。

OIDC4IDAのメリット・デメリットとユースケース

菊池：今度はOIDC4IDAのメリット・デメリットについて考えていきたいのですが、そもそもmTLS（※）もHybrid Flow（※）も、RP（※）としては作りづらいですよね。

富士榮：とは言え、さっきの話の通り、求めるのは本来はRPだから、欲しいならRPに実装してほしいんですよね。

菊池：そこは分かります。スペックを作った人はそうですけど、市場に普及させるっていう観点で考えると、少しギャップがあるような気がしています。例えば、NTTドコモさんやMUFGさんが提供するような本人確認APIがあったとして、お金を払うのはRPになるので、RPが作りやすいSDKの提供や仕様の策定なども大事なのかなと思うこともあるのですが、そこはどうなんでしょう？

富士榮：正に似たような話を先日崎村さんと話していたのですが、「FAPIって結構ややこしいじゃないですか」って所からスタートするのがまずおかしいと。なぜならば、JAR（※）にしろHybrid Flowにしろ、基本的にはOpenID Connect Core（※）に元々入っていたものだと。なので、それが喋れないLibraryがあるんだとすると、それはOpenID Connectってものにコンプライアントではないという話も考えられるよねと。

菊池：かなり厳格ですね。すごい。

富士榮：オプショナルなパラメータについて、OP（※）を作る人もRPを作る人も、どう捉えるかって結構あると思いません？

菊池：ありますね。

富士榮：確かにオプションだから実装しなくても動くけど、それってすべてのユースケースではなくて、たまたま目の前にあるユースケースのために、OpenID Connectの一部を使ってみましたっていう実装にしかなっていないと。本当の意味でLibraryを作ったりOPを作ったりすると、今そんなに困ってないはずだっていうのを仰っていました。

菊池：いいですね。スペックとセキュリティ、リスクと実装コスト、市場の普及と実際に使われるものという、それぞれの観点での話が、おそらくここで明白になったのかなと思います。

実装がめんどくさいから辞めた、みたいな形になると本末転倒で、一方で実装が楽なようなRP向けの一連のもののためにスペックを下げるという話でもなく、それを作るってことがすごく課題だなと思います。

せっかく標準化された仕様なので、そこを競って作る必要はもしかしたらないですよね。例えば先ほどの「学認」でいう大学のOPに対するOIDC4IDA準拠で、セキュリティも万全のものを我々が作っても良いわけですよね。

市場の普及においては、そういうのって欠かせないのかなと思いました。

富士榮：まさにその通りだと思います。OIDC4IDAのConformance Test（※）の時期が楽しみですね。

菊池：もう一つ、OIDC4IDAじゃないといけないパターンについても知りたいです。現在でも、普通にOIDCとかOAuth（※）で提供していてワークしているという話があると思うのですが、その上で、わざわざOIDC4IDAにする価値とは何かを考えたいなと。

富士榮：何個かあるだろうなとは想像するのですが、一例として、例えば本人確認APIを実装するとして、APIとしてはいわゆるプロプライエタリな実装をしてるわけですよね。

菊池：プロプライエタリ？

富士榮：要は、固有の実装ということです。RPからすると、本人確認APIを提供するA社用とB社用の実装をそれぞれしなければならないワケです。

これが、やはり本人確認APIを提供するすべてのOpenID Providerが、OIDC4IDAにみんな統一するんだとなれば、RPからすると一回実装すれば良いという話になるのが、一番大きいポイントなのかなと思います。

今みたいなベンダーロックインがどうしても発生しやすい状況に対して、一回繋げば全部繋がるんですよ、という世界が来るんじゃないかなと思っています。

菊池：いいですね！確かに。そうですね。

私が思っていた点としては、本人確認手段や本人確認者が1つの場合は現状のOIDCでも実装できそうですが、ひとたび複数の本人確認レベルの表現をするとなると、今の自己申告用のOIDCの仕様だとできないので、そのようなユースケースではやる意味があるのかなと。本人確認済みということだけデータ提供して、何か問題があった時に取りにきてねってことを実現しようとすると、OIDCの仕様だけだと足りなくて、そういう観点でもOIDC4IDAが必要になるのかなとは感じます。

Implementer's Drafts 3発表に向けて

菊池：ここまでだいたいOIDC4IDAの概略としては聞きたいことを聞けた感じがするのですが、逆に富士榮さんからお伝えされたいことは、何かありますか？

富士榮：今、OIDC4IDAがどういうステータスにあるかという話と、次に何をしていこうかという話を伝えておきたいなと。

菊池：ぜひぜひ！

富士榮：まず直近として、今年の9月13日週にドイツでEuropean Identity and Cloud Conference 2021（EIC）というカンファレンスがありまして、その初日にOpenID ワークショップというものが開催され、そこで、Implementer's Drafts 3が発表しました。

菊池：おめでとうございます！

富士榮：最近の議論でいうと、Implementer's Drafts 3に向けてPull Request（※）とかissues（※）を全部潰しているみたいなことをやっていて、ほぼ潰れているんですよね。これが候補版ですみたいなところまで今出てるので、これで一応、Implementer's Drafts 3が出来上がるとというフェーズにきています。

菊池：この次の、3の後のステップはどうなるのですか？

富士榮：パブリックレビューと言われる期間に入り、その間にオープンに意見をもらうなどするわけですが、次がImplementer's Drafts 4になるのか、本当にfinalizeになるのかまだ分からないのですが、そこに向けてさらに潰していくってやり方になりますね。

菊池：なるほど。

富士榮：それがOIDC4IDAのいわゆるコアの仕様になるのですが、それ以外にも何個かやらねばならないことがありまして、そのうちの一つが、OpenIDファウンデーション・ジャパンでもやっている「法人KYC」なんですよね。

それこそ政府がGビズIDなんかをやっているとは思いますが、その人がどの組織に所属しているのかみたいなところをどう表現していくのかみたいなのところをやっています。

富士榮：Authority Claimsと呼んでいるのですが、具体的には、ここでいう「法人の詳細情報」を提供するっていうデータベースを作りましょうという話ではなくて、どちらかというと下の方、「法人の代理として活動する自然人の情報の取得」というところで、この人が会社を代表しているといっているけどどういう風にそれがデリゲーションされてるのか等を、どう表現するかっていうことをやろうとしています。

富士榮：さっきの話は、OIDC4IDA単体ではClaimに対して誰がいつ検証したのかって話だったと思います（上図）。これに対して、更にこのオーソリティーに関するメタデータっていうのを与えていて、“Authority to act”というところで、どの会社のためにどういうロールで、誰によって権限付与された人なんだよという情報を、更にメタデータとしてくっつけて渡していくことができるようにする考えです。

富士榮：ちょうどデジタル庁が今月からスタートしていますが、この辺が法人認証基盤の次の姿にも近いかと思います。

菊池：GビズIDを拝見して、親子関係だけで表現できないということがいっぱいあったなと思っていたので、これはめちゃくちゃ欲しいです。

OIDC4IDAの観点から、本人確認の依拠を考える

菊池：最後に、一番議論が分かれるであろうテーマとして、OIDC4IDAで本人確認をしたことになるのかならないのか。これについてはいかがでしょうか？

富士榮：OIDC4IDAは、あくまで本人確認した結果を渡すためのデータ定義がされている、という位置付けであると思います。OIDC4IDAは依拠に近くて、依拠そのものを本人確認と呼ぶのであれば、もしかしたら本人確認の1つかもしれないですが、NIST 800-63-3で定義されたIdentity Proofingとは違うと思います。

NISTのIdentity Assurance Levelを図るためのIdentity Proofing processって、Resolution から入って、Validation、Verificationって走るという流れがあるので、それとは大きな違いがあります。

じゃあResolutionというところで、飛んできたIDトークンを自己申告なりで考えた時に、それのValidationはできるかもしれないですが、Verificationとなると、その持ってきた人とIDトークンの紐づきってまさにBAL（※）の話になってくると思うんですよね。

要はOIDC4IDAのスペックってBALには手を出してなくて、あくまでデータ表記なんですよ。

菊池：そうなんですよね。なんでBALに関わることをやってくれないんだ、っていうのは思っていました（笑）

富士榮：まあ認証はアウトオブスコープだよね、とかなってきちゃうからというので、他のものと組み合わせて担保していくべきなんだろうという話になると思うんですけどね。

なのでさっきの話で言うと、いかにOIDC4IDAが喋れるOpenID Providerで認証されて、IDトークンがメタデータ付きでRPに渡ってきたとしても、結局本人が持ってきたものなのか、違う人が代わりに持ってきたものなかって話がわからないじゃないですか。この課題を解決する必要がありますね。

菊池：なるほど。依拠が本人確認かという話であれば、依拠も犯収法の規則13条において、銀行と銀行クレジットカードを一緒に作るようなケースでは、依拠が本人確認手段として定義されています。そういう意味では、依拠が本人確認になっているという事例はあります。あとそもそもですが、免許証を作る時だって住民票を持っていってるわけですし、何かしらのIDを作る時だって、その前のIDを持っていってIDを作っていますよね。

そう考えると、この動きって公的か公的じゃないかっていう区切りはあるにしても、Aで本人確認したというデータを提供して、それを持って本人確認したとみなすっていことって、普通に行われていることだなっていう風に考えることもできると思っています。

富士榮：なるほど。

菊池：ここからはめちゃくちゃ個人的な持論なんですけど、依拠ってそういう意味では2回本人確認をしているっていう、前半・後半の概念がある世界なのかなというイメージを持っています。

初回は身分証を提出して、本人確認をしてIDを作りますと。ここまでがいわゆる普通の本人確認ですね。それを前提に、依拠するのに必要な情報をデータ提供のリクエストをして提出される。その内容に問題ないかを確認する行為自体は、後半となる依拠でも行われていると思っていて、今回でいうOIDC4IDAを仮にそうだと考えるのであれば、OIDC4IDAでOPからRPへと本人確認情報を提供するということ自体が、前半・後半はあるものの、同じようなことをしているんじゃないかと思っています。

そういう意味では、仮に国がデジタル身分証を配布します、マイナンバーカードのデータが全部スマホに入りますみたいなことを進めた時には、少なくとも一段回目における提出する・確認するという方法自体は新しくなりますよね。そうなると、本人データが端末ローカルになければならないって理由ももはやないじゃないですか。もしかすると国のDBがより最新で、端末ローカルのデータのほうが古いかもしれない。となった場合、国がOIDC4IDAのOPで、ユーザーのリクエストに応じて良い感じにデータ流してくれるみたいなことが仮にあったとすると、これ自体は本人確認かもしれないみたいなこともあるかもしれません。

このような仮定の仕方によっては、OIDC4IDA自体が本人確認になるかどうか、ではなくて、条件によってはもしかしたら本人確認したことになるかもしれないし、でも全然ならないかもしれない。そういうことを日々悩みながら過ごしています。

欠かせないであろうBinding Assuranceの存在

富士榮：そういう意味でいうと、さっきの話にあった、一段回目・二段階目って話との一貫性があるかという話が、たぶん一番大事だと思っていて、それを実現する1つの姿がBinding Assurance Levelかもしれないですよね。

ちゃんと最初に身分証を提示した人が本人なのかと、2回目にIDを使う人が最初にIDを作った人と同一で、ログインできているのかが保証できないといけないですよね。

菊池：確かに。それはおっしゃる通りですね。そこに対してBAが効くというのもわかります。特に、1回目はEntity Binding（※）が、2回目はAuthenticateor Bindingがポイントですね。

私の主張としては、BAは効くんですけど、BAだけで何とかするものでもない。実際には、本人確認においての偽造で一番多いのって身分証に手を加えるものなので、実務面においてはIALが一番まず重要で、その時のBAがきちんと考慮されているということが重要なのかなみたいな感じですかね。

最初の本人確認の提出者とRPが同じ人であるということを、どう保証するかですね。

富士榮：そうです。それをBALでやってもいいし、それをどうRPが求めていくかって視点も大事で、これってacrとかOpenID Connectとアプリケーションコンテキストと合わせましょうって話に繋がると思っていて。これがやっぱり暗黙的にコンテキストと合っているはずだと信じ込んでしまってたのが、さきに発生したフィンテックアプリと銀行口座の不正紐付け事件の問題ですから。

菊池：そうでうすね、なるほど。だとしたら、やはり一段目と二段目をつなぐのがOIDC4IDAだった時にBAの要素入ってないの困りますね。

本記事を読む際の用語集

＊＊＊

　TRUSTDOCKでは、eKYCソリューションの導入を検討されている企業の方々や、実際に導入プロジェクトを担当されている方々に向けて、PDF冊子「eKYC導入検討担当者のためのチェックリスト」を提供しております。eKYC導入までの検討フローや、運用設計を行う上で重要な検討項目等を計12個のポイントにまとめていますので、こちらもぜひご活用ください。

　なお、KYCやeKYCの詳細については、以下の記事も併せてご覧ください。

KYCとは？あらゆる業界に求められる「本人確認手続き」の最新情報を徹底解説

eKYCとは？日本唯一の専門機関のプロがわかりやすく解説

（文・長岡武司）