2019年11月11日にOpenID Foundationから発表された、新たなOpenID Connectのプロファイル「OpenID Connect for Identity Assurance 1.0」。TRUSTDOCKのようなKYC事業者が保持する本人確認済み属性情報をAPI経由で提供できるOpenID Connect技術に対して、より厳格な本人確認性にも対応できる仕様として、マネーロンダリング防止法やeIDAS規則などを満たすことを目的に策定が進んでいるものです。
この、一般的にはまだ馴染みの薄いOpenID Connect for Identity Assuranceは、具体的にどのようなものでどんなメリットがあり、現時点において本人確認で活用する場合にどんな議題が存在するのか。
今回は、OpenIDファウンデーション・ジャパン代表理事である富士榮尚寛氏と、TRUSTDOCK COOの菊池梓の対談から、理解を深めて参りたいと思います。
★本文中の（※）については、最終チャプターの「本記事を読む際の用語集」で概要解説を記述しております（本記事初出時のみ※を記載、※を押すと開設箇所へと変遷します）
プロフィール
富士榮尚寛［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ライフサイクルのチームリーダーとしても活動。
OpenID Connect for Identity Assuranceとは？
菊池：まずは、OpenID Connect for Identity Assuranceとは何かについて、改めて教えてください。
富士榮：現在のOpenID Connectとの比較をベースにお話しできればと思うのですが、基本的に今のFederationって、Relying Party（以下、RP）（※）とIdentity Provider（以下、IdP）（※）、すなわちこの場合はOpenID Provider（以下、OP）（※）の間の信頼関係に依拠しています。基本的にRPとしては、OPがどういう身元確認をしたのかというプロセスを信じた上で成り立っていると言えます。
富士榮：例えばこちらは、OpenIDファウンデーション・ジャパンとしては懐かしのStudent Identity Trust Framework（以下、SITF）です。ここに描かれている通り、基本的にはOpen Identity Exchangeあたりが作るTrust Frameworkモデル（※）（下図の中央サイド）なるものを定義して、それに則った運用を想定しています。ここでいう「学認（GakuNin）」ですね。
OPとなるIdP（下図の左サイド：各大学側）は、学認技術運用基準という運用ルールに基づいて、例えば入って来た学生に対してアカウントを割り振ったり、逆に辞めた人のアカウントを消去するなどして、ちゃんと運営してるよねということを監査・認定されています。同じようにRP（下図の右サイド：民間サービス側）も、このTrust Frameworkに則って正しくアイデンティティ情報を扱っていることが保証されているからこそ、学生さんは安心して使えるというわけです。
学術分野と民間ビジネス分野を繋ぐトラストフレームワークを構築し、学生であるという属性をオンラインで取り扱うことにより、 学生証を提示するという行為をネットの世界でも可能にするというモデル。 ユースケースとしては、電子ジャーナル、電子書籍、ソフトウェア、旅行チケットに際しての学割の利用や、クレジットカード契約などを想定している
菊池：ここでいうRPとIdPの関係は、先ほどのお話にあった通り、信頼関係に依拠しているということですね。
富士榮：そうです。何とかよろしくやってくれているだろうという風に、RPからすると信じ切ってサービスを提供しているということをやってます。
そうなると、もう少し具体的に信じられる材料が欲しくなってくるんですよね。大学が、この人は生徒だということを「学認」というTrust Frameworkの元で保証しているので大丈夫ですよと言ったところで、シナリオによってはちょっと待てと、ホンマかいなと言いたくなる人たちもいるということです。
菊池：金融なんかはその最たるケースかもしれませんね。
富士榮：単純にこの人の名前は富士榮です、この人のメールアドレスは◯◯です、などの情報がポンとIDトークンの中に入って渡ってくるものを盲目的に信じるのではなく、どういうルールに基づいて確認したものなのか、そしてどういう証拠をもって確認したものなのかといった情報も、その属性情報にくっつけてもらいたいという話が出てきます。
このような背景の中で、OpenID Foundation KYC＆IDA WGでは、OpenID Connect for Identity Assurance（以下、OIDC4IDA）というプロトコルにおいて、「検証済み属性表現（Verified Claims）」というものを定義しています。
何をもって確認/検証したのかというメタデータを付与
富士榮：通常のOpenID ConnectのID連携ではIdPが言うことを一種包括的にRPが信じるようなことをやっているのですが、OIDC4IDAではその人のアイデンティティ情報に、何をもって確認/検証したのかといったメタデータをくっつけています。
※連携されるメタデータ例
- どんなルールに基づいて確認したものなのか？
- どんな証拠を持って確認したものなのか？
- いつ確認したものなのか？
- どうやって確認したものなのか？
富士榮：例えばこちらの例では、Trust Frameworkのところにはドイツのアンチマネーロンダリング法が定義され、方法としてはpippと表現される“Physical in-Person Proofing”、すなわち対面での身元確認が記述されています。さらに確認を実行したのは銀行そのものではなくてDeutsche Postという、ドイツの郵便局みたいな所での本人確認をするサービスにて、IDカードを使って確認しましたよ、という内容が表現されています。
マネロンからヘルスケアまで様々なケースがありますが、今お伝えしたようなメタデータをくっつけて渡すことをもって、渡されたアプリケーション側つまりはRP側が、よりそれを信じられるようにしましょう、ということを目的としたプロトコルがOIDC4IDAというわけです。
菊池：なるほど。ちなみに富士榮さんイチオシのメタデータってあるのでしょうか？今のお話だと、本人確認の手段やそれに関わる法律などがありましたし、私の知っている範囲だと、本人確認をいくつか組み合わせた情報や本人確認時の画像添付もあったと思います。
富士榮：このメタデータが良いとか悪いとか、一概には言えないのですが、菊池さんが言ったような、IDドキュメントの画像そのものを添付てきるようにする点については、特に日本だと求められるんだろうなと思いますね。やっぱり信じきれないといいますか。
菊池：わかります。もし自分だったら、画像取得APIを別で作っちゃうなって思っていたので、それが盛り込まれているのはすごい良いなと思いました。
富士榮：例えば銀行なんかを考えてみても、他の事業者に完全に依拠するのって、特に日本では文化的な背景も含めてまだまだ難しいんじゃないかなと思うんですよ。それこそTRUSTDOCKさんなんかでも業務委託じゃないですか。
いわゆる本当の意味でのサードパーティーではなくて、ファーストパーティーにKYCを代行する事業者がいて、そこに委託をしてるって考え方にならざるを得ないのは、やっぱりファーストパーティーでKYCまでやっちゃいたい、もしくはやらなけれならないというのがあるからだろうなと思っています。そうなると、本当の意味でのエビデンスそのものも必要になってくるんでしょうね。
菊池：たしか、後から照会できる機能もありましたよね。
富士榮：はい、ありますね。
菊池：何か事故が発生した時に、本人確認であの時どうだったのって求められることがあると思うのですが、全体的にその場で共有系が多い中で、後からこのIDで問い合わせましょうという手法が盛り込まれてる点も、すごく良いと感じます。
富士榮：プロトコル的に言うと非常にシンプルなんですけどね。IDだけ渡していくって方式だから。ただ、全部渡す必要はないだろうって話はありますから、用途によっては凄く良い使い方ができると思います。
OpenID Provider側の責任は重い
菊池：次に、セキュリティについての考えを教えてください。OIDC4IDAで送る時に、FAPI（※）レベルでないといけないとか、逆にそれは高すぎるんじゃないかといった議論があると思いますが、これについてはいかがでしょうか？
富士榮：セキュリティに関しては、スペックとしては非常に重要だよねという話がありつつ、トランスポートレイヤーのセキュリティとか、OpenID Connectとしてのセキュリティに関してOIDC4IDAの中で検討するということは、もうやめようと。あくまでデータの表現に関するところがスコープだよね、という感じにしています。
そういう意味で、FAPIのmTLS（※）の話だとか、Hybrid Flow（※）の話だとか、ああいう所に一種投げるということをしてます。
菊池：それはどういう風に受け止めたら良いのでしょうか？IDのところにmTLSとかHybrid Flowとかが入ってきたら、RPは「これをやらなきゃいけない」といった、一種の強制力になるわけじゃないですか。
でもそれを外したということは、OPがFAPIレベルのセキュリティを求めるかどうかを選べるということだと思っていて、それは「委ねる」という話なんですかね？そうなると、OPの責任も結構重いかなって気がしてきます。
富士榮：実際にOP側の責任は重いと思いますよ。少なくともVerifiedということは、OPがちゃんとVerifyしましたよ、という結果を渡すわけなので。これ、非常に難しいと思いますけれど、いわゆるNIST（※）でいうFAL（※）って誰の責任なんでしたっけみたいな話なんですよね。
菊池：その話もしたかったです。
富士榮：僕は、やはりOPの責任なんじゃないかなと思うわけです。ただ、セキュリティレベルを求めるのは誰かというと、それはRPなわけですよね。
菊池：はい、そうですね。
富士榮：ちょっとくらい改ざんされてもいいと、なんとなくメタデータが付いてれば良いというRPもいれば、せっかくVerifiedだってことを保証してくれるんだったらトランスポートのところでFederationする過程で置き換わってないこと、もしくは改ざんされてないことの保証もされてないと困るんだというRPもいらっしゃると思うんですよね。こうなってくると、やはり、OPがそこに対応してくるかどうかというのは重要なポイントかなとは思います。
菊池：なるほど。ちなみに先ほどmTLSとかHybrid Flowの話が出てきましたが、こういうリスクがあるからmTLSやHybrid Flowにした方が良いよ、といったあたりについて、もう少し詳しく教えて欲しいです。
富士榮：それについては、崎村さん（OpenID Foundation 理事長）が作った資料が分かりやすいです。
画像出典：FAPI and beyond - よりよいセキュリティのために スライド11より
富士榮：環境制御レベルという言い方をするのですが、要は通信レイヤーを含めて、ある程度自分たちのコントロール配下にあるようなネットワーク上のやりとりや企業間のやりとりって、改ざんリスクや置き換えリスクなどはそこまで大きくないですよね。そういうものに関しては、ベーシックなOpenID Connectを使っても良いんじゃないかなと思います。
一方で、もう少しパブリックなインターネットを通って重要な情報をやりとりするのであれば、それ相応のセキュリティは担保されるべきであろうと思うわけです。いわゆる、環境統制レベルが低い、という言い方になるんだと思います。
菊池：環境制御レベルが低いけど提供するデータが重要な場合は、お互いのためにmTLSやHybrid Flowを採用した方が良いんじゃないか、という理解で良いでしょうか？
富士榮：そういった理解で大丈夫です。
OpenID Connect for Identity Assuranceで本人確認はできる？できない？｜OIDFJ富士榮 × TRUSTDOCK菊池【対談】後編
本記事を読む際の用語集
| 用語 | 説明 |
| RP | Relying Partyの略。本人確認結果を利用してユーザに対してサービス提供を行う主体。 |
| IdP | Identity Providerの略。アイデンティティ情報をRPへ提供する主体。 |
| OP | OpenID Providerの略。OpenID ConnectにおけるIdPの呼称。 |
| Trust Framework | 法令・ガイドラインや第三者認定制度等、信頼を形成するための枠組みのこと。JASマークからクレジットカードまで、様々な実装ケースが存在する。 |
| FAPI | Financial-grade APIの略。OpenID FoundationのFinancial-grade API WGが策定する技術仕様で、高度なセキュリティが求められる分野のオンラインサービスへの適用を想定したもの。 |
| mTLS | mutual-TLS（TLS相互認証）の略。ネットワーク通信の際の暗号化プロトコルとして、サーバとクライアントが相互認証する仕様。FAPIの文脈においてはクライアント証明書によるOAuthクライアントの認証およびクライアント証明書に紐づくトークンに関する処理を指す。 |
| Hybrid Flow | 単一クライアントに対して、1回の認可フローで2つのIDトークンが発行できる技術仕様。フロントチャネルで発行されるIDトークンでは認可コードの検証を行うことでコード置き換え等の攻撃に対する対応を、バックチャネルで発行されるIDトークンでは同時に発行されるアクセストークンとの紐付けを検証できるようにすることでアクセストークンの信頼性の工場を図っている。 |
| NIST | National Institute of Standards and Technology（アメリカ国立標準技術研究所）の略。同団体が発行する電子的認証に関するガイドライン「NIST SP 800-63-3」では、各Assurance Level（IAL、AAL、FAL）の詳細に関するドキュメントが公表されている。 |
| IAL | Identity Assurance Level（身元確認保証レベル）の略。NISTが定義する、本人確認の厳密さや強度を示す。 |
| AAL | Authenticator Assurance Level（当人認証保証レベル）の略。NISTが定義する、当人認証プロセスの強度を示す。 |
| FAL | Federation Assurance Level（フェデレーション保証レベル）の略。NISTが定義する、認証連携（フェデレーション）の強度を示す。 |
＊＊＊
TRUSTDOCKでは、eKYCソリューションの導入を検討されている企業の方々や、実際に導入プロジェクトを担当されている方々に向けて、PDF冊子「eKYC導入検討担当者のためのチェックリスト」を提供しております。eKYC導入までの検討フローや、運用設計を行う上で重要な検討項目等を計12個のポイントにまとめていますので、こちらもぜひご活用ください。
なお、KYCやeKYCの詳細については、以下の記事も併せてご覧ください。
KYCとは？あらゆる業界に求められる「本人確認手続き」の最新情報を徹底解説
（文・長岡武司）
