IoTと金融サービスの連携が生み出す未来｜最新の国際標準「CIBA」の全貌

はじめに　

あらゆるモノがインターネットにつながるIoT（インターネット・オブ・シングズ）が急速に広がりつつある。様々なセンサーで得た情報を活用してエネルギー消費量などを最適化する「スマートハウス」や、遠隔制御による「現場の無人化」など多岐にわたる分野で応用が進んでいる。

金融関係者にとって、IoTはやや縁遠い存在に感じられるかもしれない。だが近い将来、その認識を変える必要が出てくるだろう。決済などの金融サービスをIoTと融合させて、発注から決済、サービス提供までのプロセス全てをオンラインで完結できる新たなサービスが続々と生まれると考えられるからだ。

例えば、事前予約なしのホテル宿泊予約と支払いをスマートフォンだけで可能にするサービスを実現できる。宿泊代の支払いについては部屋の鍵をIoT機器にしておき、支払いが済むと鍵が自動で解除される形が考えられる。利用者の利便性を高めるのはもちろん、ホテル運営を効率化できると期待される。

金融サービス側では、欧州に端を発した金融機関におけるオープンAPI（アプリケーション・プログラミング・インターフェース）の動きが大きなきっかけになりそうだ。特に更新系APIの公開が進めば、オンラインでの決済指示が容易になる。金融機関とFinTech企業が連携して経費振込処理をオンラインで完結できるようにするなど、APIを活用した金融サービスは増えつつある。

IoT機器に認証機能を持たせるべきか

IoTと、APIを使った金融サービスが融合すると、利便性の高い魅力的な新たなサービスが生まれる可能性が高い。だが、実現しようとすると大きな問題が持ち上がる。本人認証をどうするか、である。

サービスの全てがインターネット上で処理されるとなると当然、サイバー空間におけるセキュリティーへの脅威が強まる。適切な対策を施す必要があるのは言うまでもない。

多くの場合、新サービスは個々の利用者に応じた形になるだろう。そうなると、サービスを提供する前に利用者を識別・認証する必要が生じる。決済指示についても、セキュリティーを担保した上で本人の同意に基づき進めなければならない。攻撃者のなりすましを防ぐ強固な認証手段を用意する必要があるわけだ。

だからといって、センサーやデバイスといったIoT機器全てに認証機能を持たせるのは現実的ではない。多大なコストがかかり、維持や保守の負荷も大きい。

IoT機器の多くはユーザーインターフェース（UI）を備えていない点も問題だ。それぞれの機器で利用者認証を実現しようとすると、パスワード入力や生体情報の読み取りに必要なUIを新たに追加する必要がある。ディスプレーやキーボード、マウス、QRコードリーダーなどの利用が考えられるが、どの方法であれ、利用者に不慣れなインターフェースを強いるのは同じである。ユーザー体験（UX）の面で好ましいとは言えず、サービスからの離脱につながる懸念も生じる。

具体例を挙げよう。利用料の支払いが完了するとすぐに車を借りられる、カーシェアリングのサービスを始めるとする。このサービスを実現するに当たり、車を借りようとしている人が本当に借主かどうかを認証する必要がある。ところが、車は利用者確認に必要なID認証機能やUIを持っていない。

さらに、このサービスを実現するためには、支払処理を実行する機能も必要になる。だが、車はインターネットを介した決済指示機能を備えていない。サービス提供者が多額の投資をして、車にID認証や決済指示の機能を追加するのは考えにくい。

サービス提供機器と認証機器を分離

こうした課題を解決する方策として、注目を集めつつあるのが、「CIBA（シーバ）」だ。CIBAは「OpenID Connect Client Initiated Backchannel Authentication Flow」の略で、ID認証のフローを示した標準仕様を指す。複数のWebサービスにおけるユーザーIDを連携し、1つのIDで認証できるOpen IDに関する標準化団体である米OpenID Foundationが策定し、2019年2月4日にImplementer’s Draftとして承認、公表した。

従来のID認証の仕組みと異なるCIBAの特徴は、「サービスを提供するデバイス」と「ID認証を担うデバイス」を分離できる点である。しかもサービスを提供するデバイスは利用者の管理下（操作下）になくてもよい。先ほどのカーシェアリングの例で説明する。

カーシェアリングのサービスでは、サービスを提供するデバイスは当然「車」であり、ID認証を担うデバイスは例えば「利用者自身のスマートフォン」となる。

CIBAを利用した処理の流れは以下のようになる。利用者はまずカーシェアリングのサービスセンターに支払処理を依頼する。センターは連携しているペイメントサービスに対し、依頼を受け渡す。

利用者のスマートフォンにはID認証や同意の取得に関する通知が来る。利用者はスマホで処理を実行する。センターがペイメントサービスから支払完了の通知を受け取ると、車のキーロックを解除し、貸し出しを許可する。

CIBAを活用すれば、利用者向けのUIを持たないIoT機器にID認証や支払処理の機能を付加しやすくなる。先ほど例として挙げた事前予約なしのホテル宿泊といった、「IoT+金融」サービスの実現が容易になると期待される。

支払・認証を10の処理で進める

いま挙げたカーシェアリング利用時の支払・認証処理の流れをもう少し詳しく見ていくと、大きく以下の10の処理で構成される。処理の詳細についてはOpenID Foundationが公表している関連仕様を参照してほしい。

• ［1］利用者が出した「支払処理開始」のリクエストを、デバイスのサービスセンターのシステムに送付する。リクエストの送付手段について、CIBAの標準仕様は特に規定していない。サービス提供用デバイス経由でもいいし、架電のようにデバイスを通らない経路を使う選択肢もあり得る。
• ［2］サービスセンターからペイメントサービスに対し、支払処理を依頼する。
• ［3］サービスセンターからのリクエスト内容を確認し、ペイメントサービスに登録されている利用者IDを識別する。
• ［4］識別した利用者IDの値を基に、ペイメントサービス側にあらかじめ登録された利用者の認証デバイス（例えばスマートフォン）に対し、支払処理の確認とID認証の要求を通知する。
• ［5］利用者の認証デバイスに確認・ID認証要求の通知が届く。［1］で自身が実施したリクエストであると利用者が確認した上で、認証デバイス上で確認・ID認証を実施する。
• ［6］認証デバイスでの確認・ID認証結果を許可サーバーに戻す。
• ［7］認可サーバーは「トークン」を発行し、サービスセンターのシステムに送る。トークンは支払処理時に必要なチケットと考えればよい。
• ［8］サービスセンターのシステムからペイメントサービスの支払い処理システムに対し、トークンとともに支払い処理を依頼する。
• ［9］支払処理の結果が戻ってくる。
• ［10］支払い処理の結果に応じ、センター側でサービス提供を開始する。

処理［2］から［7］に関して、サービスセンターでは状況を把握できない。そこでCIBA
の仕様では、処理［7］における連帯方式として以下の3パターンを定義することで、トークンの発行状況を把握できるようにしている。

• ［a］Pushモード：ペイメントサービス側からトークンを送付
• ［b］Pingモード：ペイメントサービス側からセンターに処理が終わった旨を通知し、あらためてセンターからペイメントサービス側にトークンを取得しにいく
• ［c］Pollモード：センター側から継続的に結果を確認し続ける

CIBA躍進に3つの要因

CIBAはもともと、「モバイルネットワークやデバイスによるID認証技術を活用できないか」との着想から検討が始まった。だがここまででお分かりのようにモバイルの分野に閉じず、幅広く応用が期待されている。

金融の分野では「Financial-grade API（FAPI）」の構成プロファイルの1つとして活用が検討されている。FAPIはセキュアなFinTechサービスを実現するためのAPI仕様で、OpenID Foundationが議論を進めている。以前は「Financial API」という名称だったが、幅広い分野での応用を期待され現在の名称に変更された。

このようにCIBAの応用範囲が広がりを持つと考えられる背景として、以下の3点が挙げられる。

テクノロジーの進化に伴い、デバイスの処理性能は格段に向上している。このため、IoTデバイスやセンサーの細分化と低コスト化が進んだ。

一方で前述したように、細分化した個々のデバイスにID認証機能を実装する方法はコスト面で折り合いが付かない。このため、効率よく各デバイスのID認証を進める手法としてCIBAに注目が集まった。

最近では、利用者の多くは自身が管理するIDをできるだけ集約し、認証処理を楽にしたいと考えている。

IoT機器を使う機会が増えるとともに認証処理が複雑になると、こうしたニーズに逆行してしまう。これまで以上に、使い慣れたIDと認証手段を用いた認証に対するニーズが高まると予想される。

多くの人がスマホを常に携帯している。生体認証などセキュリティーが強固な認証機能を備えている機器も多い。

このため、スマホの活用を前提としたID認証の実現が現実的になった。

CIBAがもたらす未来の可能性

多様な分野でCIBAの利用が広がると、利用者、サービス提供側の双方に大きな恩恵をもたらすと期待できる。

利用者は、各サービスの認証手段を身近で使い慣れた単一の認証デバイスに集約できるようになる。従来のようにサービスごとに認証に必要な機器や道具を持ち歩く必要はなくなり、UXの向上が期待できる。

さらに集約先の認証デバイスに高いセキュリティーのID認証手段を持たせておけば、各サービス利用時のID認証に関するセキュリティーを画一的に高いレベルに保てるようになる。

サービス提供側にとっては、先に触れたようにまずコストメリットが見込める。サービス品質の向上も期待できる。IoT機器ごとにID認証が可能になれば、利用者に応じてIoTが提供するサービスのレベルを変える、といった形態が可能になるからだ。

CIBAによりコンポーネント単位でのID認証が可能になれば「車単位」でなく、より細かい単位でのサービス提供が可能になる。例えば、駆動系システムに対しID認証をすれば、利用者それぞれの運動の癖を反映した最適な補助設定を反映できる。されにカーナビやオーディオ機器などにID認証をすれば、自身の利用履歴やお気に入りの曲を再生できる。この考え方はカーシェアリングに限らず、FinTech関連のサービスにも応用できるとみられる。