JP2024044013A - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】認証の効率をさらに向上させる。【解決手段】本願に係る情報処理装置は、認証時に、認証器から認証用公開鍵を搭載したＶＣ（Verifiable Credentials：検証可能な資格証明書）を受け取る受付部と、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出す抽出部と、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理部と、ＦＩＤＯ認証に成功した場合、サービスを提供する提供部と、を備えることを特徴とする。【選択図】図４

Description

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。

ＦＩＤＯ（Fast Identity Online）に関する技術であって、認証器を用いる技術が開示されている（特許文献１参照）。

特開２０２０－１４１３３１号公報

しかしながら、上記の従来技術では、認証時の本人確認を含め、ＦＩＤＯ認証に関してまだまだ改善の余地がある。

本願は、上記に鑑みてなされたものであって、認証の効率をさらに向上させることを目的とする。

本願に係る情報処理装置は、認証時に、認証器から認証用公開鍵を搭載したＶＣを受け取る受付部と、前記認証用公開鍵を搭載したＶＣから、前記認証用公開鍵を取り出す抽出部と、前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理部と、前記ＦＩＤＯ認証に成功した場合、サービスを提供する提供部と、を備えることを特徴とする。

実施形態の一態様によれば、認証の効率をさらに向上させることができる。

図１は、実施形態に係る情報処理方法の概要を示す説明図である。 図２は、ＦＩＤＯマイクロサービスによるＦＩＤＯ認証機能の分離の概要を示す説明図である。 図３は、ＶＣに公開鍵情報を搭載する方式における登録時の処理の概要を示す説明図である。 図４は、ＶＣに公開鍵情報を搭載する方式における認証時の処理の概要を示す説明図である。 図５は、実施形態に係る情報処理システムの構成例を示す図である。 図６は、実施形態に係る端末装置の構成例を示す図である。 図７は、実施形態に係るサーバ装置の構成例を示す図である。 図８は、利用者情報データベースの一例を示す図である。 図９は、履歴情報データベースの一例を示す図である。 図１０は、実施形態に係る処理手順を示すフローチャートである。 図１１は、ハードウェア構成の一例を示す図である。

以下に、本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態（以下、「実施形態」と記載する）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．情報処理方法の概要〕
まず、図１を参照し、実施形態に係る情報処理装置が行う情報処理方法の概要について説明する。図１は、実施形態に係る情報処理方法の概要を示す説明図である。なお、図１では、ＦＩＤＯ認証の基本的な仕組みについて説明する。

図１に示すように、情報処理システム１は、端末装置１０とサーバ装置１００とを含む。端末装置１０とサーバ装置１００とは、ネットワークＮ（図５参照）を介して有線又は無線で互いに通信可能に接続される。本実施形態では、端末装置１０は、サーバ装置１００と連携する。

端末装置１０は、利用者Ｕ（ユーザ）により使用されるスマートフォンやタブレット端末等のスマートデバイスであり、４Ｇ（Generation）やＬＴＥ（Long Term Evolution）等の無線通信網を介して任意のサーバ装置と通信を行うことができる携帯端末装置である。また、端末装置１０は、液晶ディスプレイ等の画面であって、タッチパネルの機能を有する画面を有し、利用者Ｕから指やスタイラス等によりタップ操作、スライド操作、スクロール操作等、コンテンツ等の表示データに対する各種の操作を受付ける。なお、画面のうち、コンテンツが表示されている領域上で行われた操作を、コンテンツに対する操作としてもよい。また、端末装置１０は、スマートデバイスのみならず、デスクトップＰＣ（Personal Computer）やノートＰＣ等の情報処理装置であってもよい。

本実施形態では、端末装置１０は、ＦＩＤＯ認証（Fast Identity Online）におけるＦＩＤＯクライアントとして機能する。ＦＩＤＯクライアントは、認証器（Authenticator）と連携してユーザの認証を行う。なお、認証器は、ＦＩＤＯクライアントと同一のデバイスに実装されることがあってもよく（内蔵認証器）、ＦＩＤＯクライアントとは物理的に異なるデバイスに実装されていてもよい（外部認証器）。

例えば、ＦＩＤＯ認証では、ＰＩＮ（Personal Identification Number）、ＵＳＢ（Universal Serial Bus）セキュリティキー、スマートカードなどの記憶や所有物を用いた認証方式や、指紋、顔、虹彩、静脈、声紋などの生体情報や行動情報を用いた認証方式を実装できる。認証方式は、これらに限定されず、あらゆる方式を導入することができる。また、複数の認証方式を組み合わせて、マルチモーダル生体認証や多要素認証を実現することもできる。

以下、説明の簡略化のため、ＦＩＤＯクライアントと認証器とを区別せず、端末装置１０をＦＩＤＯクライアントかつ認証器として説明する。すなわち、認証器が内部認証器である場合を例に説明する。なお、実際には、認証器は、端末装置１０から物理的に独立し、端末装置１０と連携可能な外部認証器であってもよい。

また、ＦＩＤＯクライアントのＷｅｂブラウザに表示されるウェブコンテンツから認証器を呼び出し、認証サーバとのやり取りでＦＩＤＯ認証を可能にするためのＷｅｂ認証ＡＰＩ（Application Programming Interface）も実装可能であるが、本実施形態では説明を割愛する。

サーバ装置１００は、ＦＩＤＯ認証における認証サーバ（ＦＩＤＯサーバ）として機能する情報処理装置であり、コンピュータやクラウドシステム等により実現される。認証サーバは、ＲＰ（Relying Party）／ＩｄＰ（Identity Provider）に相当する。ＲＰ（Relying Party）は、ＦＩＤＯサーバを実装するエンティティ・組織のことを指す。ＦＩＤＯ認証では、認証器（Authenticator）と認証サーバとの間で、パスワードや生体情報のような「秘密」を共有しないので、フィッシングに対する耐性がある。

図１に示すように、ＦＩＤＯ認証では、認証サーバは、ユーザからの認証要求を受けると、ユーザ側の認証器にチャレンジ（Challenge）を送る。チャレンジは、一度だけ有効なランダムな文字列であり、乱数を元に決めた毎回異なるデータ列である。ユーザは、認証器を用いてユーザ検証（User verification）を行い、本人性の検証をローカルで実施する。そして、認証器は、検証結果を秘密鍵（Private Key）で署名し、署名付き検証結果(Signed response)として認証サーバに送る。認証サーバは、署名付き検証結果を受け取ると、公開鍵（Public Key）で署名検証する。秘密鍵と公開鍵との組を、鍵ペアと称する。

このように、ＦＩＤＯ認証では、認証サーバが、公開鍵を用いて、ユーザ側の認証器が適切な秘密鍵を保有することを確認することによって認証を実現する。認証器と認証サーバは「秘密鍵」を共有しない。

また、サーバ装置１００は、ＦＩＤＯ認証に対応したＲＰ／ＩｄＰとのＩＤ連携（フェデレーション）によりアイデンティティサービスを提供する連携ＲＰ／ＳＰ（Service Provider）としても機能する。ＦＩＤＯ認証とＩＤ連携とを組み合わせると、認証コンテキストは認証器からＲＰ／ＩｄＰを介して連携ＲＰ／ＳＰへと伝搬する。

以下、説明の簡略化のため、ＲＰ／ＩｄＰと連携ＲＰ／ＳＰとを区別せず、サーバ装置１００をＲＰ／ＩｄＰかつ連携ＲＰ／ＳＰとして説明する。なお、実際には、ＲＰ／ＩｄＰとしてのサーバ装置と、連携ＲＰ／ＳＰとしてのサーバ装置とは、物理的に独立した異なるサーバ装置であってもよい。

例えば、サーバ装置１００は、各利用者Ｕの端末装置１０と連携し、各利用者Ｕの端末装置１０に対して、各種アプリケーション（以下、アプリ）等に対するＡＰＩ（Application Programming Interface）サービス等と、各種データを提供してもよい。

また、サーバ装置１００は、各利用者Ｕの端末装置１０に対して、オンラインで何らかのＷｅｂサービスを提供する情報処理装置であってもよい。例えば、サーバ装置１００は、Ｗｅｂサービスとして、インターネット接続、検索サービス、ＳＮＳ（Social Networking Service）、電子商取引（ＥＣ：Electronic Commerce）、電子決済、オンラインゲーム、オンラインバンキング、オンライントレーディング、宿泊・チケット予約、動画・音楽配信、ニュース、地図、ルート検索、経路案内、路線情報、運行情報、天気予報等のサービスを提供してもよい。実際には、サーバ装置１００は、上記のようなＷｅｂサービスを提供する各種サーバと連携し、Ｗｅｂサービスを仲介してもよいし、Ｗｅｂサービスの処理を担当してもよい。

なお、サーバ装置１００は、利用者Ｕに関する利用者情報を取得可能である。例えば、サーバ装置１００は、利用者Ｕの性別、年代、居住地域といった利用者Ｕの属性に関する情報を取得する。そして、サーバ装置１００は、利用者Ｕを示す識別情報（利用者ＩＤ等）とともに利用者Ｕの属性に関する情報を記憶して管理する。

また、サーバ装置１００は、利用者Ｕの端末装置１０から、あるいは利用者ＩＤ等に基づいて各種サーバ等から、利用者Ｕの行動を示す各種の履歴情報（ログデータ）を取得する。例えば、サーバ装置１００は、利用者Ｕの位置や日時の履歴である位置履歴を端末装置１０から取得する。また、サーバ装置１００は、利用者Ｕが入力した検索クエリの履歴である検索履歴を検索サーバ（検索エンジン）から取得する。また、サーバ装置１００は、利用者Ｕが閲覧したコンテンツの履歴である閲覧履歴をコンテンツサーバから取得する。また、サーバ装置１００は、利用者Ｕの商品購入や決済処理の履歴である購入履歴（決済履歴）を電子商取引サーバや決済処理サーバから取得する。また、サーバ装置１００は、利用者Ｕのマーケットプレイスへの出品の履歴である出品履歴や販売履歴を電子商取引サーバや決済処理サーバから取得してもよい。また、サーバ装置１００は、利用者Ｕの投稿の履歴である投稿履歴を口コミの投稿サービスを提供する投稿サーバやＳＮＳサーバから取得する。なお、上記の各種サーバ等は、サーバ装置１００自体であってもよい。すなわち、サーバ装置１００が上記の各種サーバ等として機能してもよい。

〔１－１．ＦＩＤＯマイクロサービスによる機能分割〕
現在、ＦＩＤＯマイクロサービスによるＦＩＤＯ認証機能の分離が進められている。例えば、ＦＩＤＯサーバからＦＩＤＯ認証に必要な機能を細かく切り出す。これにより、ＩｄＰがＦＩＤＯ認証の実装をしなくて済むという利点がある。図２は、ＦＩＤＯマイクロサービスによるＦＩＤＯ認証機能の分離の概要を示す説明図である。

本実施形態では、利用者Ｕは大学等の学生（Student）で、ＩｄＰであるサーバ装置１００は大学等のサーバであり学生データベース（Student’s DB）を有する。図２では、ＩｄＰであるサーバ装置１００からＦＩＤＯ認証機能を分離し、ＦＳＰ（FIDO Service Provider）であるサーバ装置２００でＦＩＤＯ認証を実施している。このとき、ＦＳＰであるサーバ装置２００のデータベース（FIDO’s DB）にユーザの公開鍵（FIDO Pubkey）が既に登録されていることが前提である。なお、実際には、サーバ装置２００は、サーバ装置１００と同種／同じ構成のサーバ装置であってもよい。すなわち、サーバ装置２００は、サーバ装置１００の１つであってもよい。

例えば、図２に示すように、利用者Ｕの端末装置１０は、ネットワークＮ（図５参照）を介して、ＩｄＰであるサーバ装置１００に認証要求（Auth request）を送信する（ステップＳ１）。

続いて、ＩｄＰであるサーバ装置１００は、利用者Ｕの端末装置１０からの認証要求（Auth request）に応じて、ネットワークＮ（図５参照）を介して、ＦＳＰであるサーバ装置２００に、利用者ＵのユーザＩＤとともにＦＩＤＯ認証要求（FIDO Auth request）を送信する（ステップＳ２）。

続いて、ＦＳＰであるサーバ装置２００は、ＦＩＤＯ認証要求（FIDO Auth request）に応じて、利用者ＵのユーザＩＤに紐付けられた公開鍵を用いて署名検証を行い、ＦＩＤＯ認証を行う（ステップＳ３）。

続いて、ＦＳＰであるサーバ装置２００は、ネットワークＮ（図５参照）を介して、ＩｄＰであるサーバ装置１００にＦＩＤＯ認証結果（FIDO auth result）と認証コンテキスト（auth context）を送信（返信）する（ステップＳ４）。

続いて、ＩｄＰであるサーバ装置１００は、ＦＩＤＯ認証結果に基づき、ＦＩＤＯ認証に成功している場合には、利用者ＵのユーザＩＤを抽出し、パスワード入力によるパスワード認証を行うとともに、ＦＩＤＯ認証の完了（FIDO Flag ON）を記憶する（ステップＳ５）。

なお、実際には、ＩｄＰであるサーバ装置１００は、ステップＳ２において、先に利用者ＵのユーザＩＤ及びパスワードに基づくパスワード認証等の第１の認証を行い、パスワード認証に成功した場合に、第２認証として、ネットワークＮ（図５参照）を介して、ＦＳＰであるサーバ装置２００に、利用者ＵのユーザＩＤとともにＦＩＤＯ認証要求（FIDO Auth request）を送信するというように多要素認証の形態をとってもよい。

公開鍵は、ＦＳＰであるサーバ装置２００に限らず、ＩｄＰであるサーバ装置１００が管理してもよい。この方式では、ＩｄＰかＦＳＰが公開鍵を管理しておくため、鍵を特定できるユーザのみ認証可能である。

しかし、ＦＩＤＯ認証機能の分離により、ＦＩＤＯ認証が容易に提供できるようになったものの、登録時のユーザ負担が高いという課題がある。また、登録したサイトが消えてしまった場合、認証情報も消えてしまう可能性がある。このとき、ＶＣ（Verifiable Credentials：検証可能な資格証明書）が本人のものであることを保証する仕組みがない。

ＶＣは、属性情報を第三者に証明してもらうためのデジタル証明書であり、ＤＩＤ（Decentralized Identifier：分散型ＩＤ）で示されたアイデンティティ（属性情報と紐付けられていないアイデンティティ）に対し、属性情報を紐付ける役割を持つ。例えば、ＶＣは、運転免許証や学歴証明書、資格証明書、その他の機密データなどの物理的に存在する個人の属性を表す情報等を格納することができる。実際には、ＶＣは情報そのものを指すものではなく、その情報を格納する入れ物であり、その入れ物の真正性を検証できるもの（検証可能な輸送用コンテナのようなもの）である。

〔１－２．登録時〕
本実施形態では、ＩｄＰやＦＳＰは公開鍵情報の登録や管理を行わない（実際にはしてもよいが、必須ではない）。本実施形態では、ＶＣに認証用公開鍵を搭載する。例えば、認証用公開鍵を属性情報の１つとしてＶＣに格納する。図３は、ＶＣに公開鍵情報を搭載する方式における登録時の処理の概要を示す説明図である。

例えば、図３に示すように、利用者Ｕの端末装置１０は、ネットワークＮ（図５参照）を介して、ＩｄＰであるサーバ装置１００に登録要求（Reg request）を送信する（ステップＳ１１）。

続いて、ＩｄＰであるサーバ装置１００は、利用者Ｕの端末装置１０からの登録要求（Reg request）に応じて、ネットワークＮ（図５参照）を介して、ＦＳＰであるサーバ装置２００に、利用者ＵのユーザＩＤとともにＦＩＤＯ登録要求（FIDO Reg request）を送信する（ステップＳ１２）。

続いて、ＦＳＰであるサーバ装置２００は、ＦＩＤＯ登録要求（FIDO Reg request）に応じて、利用者ＵのユーザＩＤに紐付けられた登録用公開鍵を用いて署名検証を行い、ＦＩＤＯ登録を行う（ステップＳ１３）。

登録用公開鍵は、例えば認証器証明書（Attestation：アテステーション）の署名検証用の公開鍵等である。ＦＳＰであるサーバ装置２００は、登録用公開鍵を用いて認証器の真正性確認（署名検証）を行う。登録用公開鍵は別途ＨＰ（Ｗｅｂサイト）又はそれに類する手段などで公開されているものとする。

続いて、ＦＳＰであるサーバ装置２００は、ネットワークＮ（図５参照）を介して、ＩｄＰであるサーバ装置１００にＦＩＤＯ登録結果（FIDO Reg result）を送信（返信）する（ステップＳ１４）。なお、ＦＩＤＯ登録結果は、認証器の真正性確認（署名検証）の結果であってもよい。

続いて、ＩｄＰであるサーバ装置１００は、ＦＩＤＯ登録結果に基づき、ＦＩＤＯ登録に成功している場合には、利用者ＵのユーザＩＤ及びパスワードを含むユーザ登録を行う（ステップＳ１５）。

続いて、ＩｄＰであるサーバ装置１００は、ネットワークＮ（図５参照）を介して、認証器である利用者Ｕの端末装置１０から認証用公開鍵を受け取り、ＶＣ（Verifiable Credentials：検証可能な資格証明書）に認証用公開鍵を搭載し、利用者Ｕの端末装置１０に、認証用公開鍵を搭載したＶＣを発行する（ステップＳ１６）。

なお、実際には、ＩｄＰであるサーバ装置１００は、ネットワークＮ（図５参照）を介して、認証器である利用者Ｕの端末装置１０に対して、認証用秘密鍵と認証用公開鍵の鍵ペアの生成と、認証用公開鍵を搭載したＶＣの生成を要求してもよい。すなわち、認証器である利用者Ｕの端末装置１０が、ＩｄＰであるサーバ装置１００から指示／許可を受けて（ＩｄＰであるサーバ装置１００の制御下で）、認証用公開鍵を搭載したＶＣを生成してもよい。例えば、認証器である利用者Ｕの端末装置１０は、ＩｄＰであるサーバ装置１００からＶＣの生成に使用される登録パラメータを受け取り、登録パラメータに含まれるデータを用いて認証用公開鍵を搭載したＶＣを生成してもよい。このとき、ＩｄＰであるサーバ装置１００は、ＶＣの真正性の検証用に、認証器である利用者Ｕの端末装置１０から、生成された認証用公開鍵を搭載したＶＣを受け取って保管してもよい。

認証用公開鍵は、例えば認証器でのユーザ検証結果の証明書（Assertion：アサーション）の署名検証用の公開鍵等である。認証用公開鍵をＶＣに搭載することで、ＶＣの発行者（Issuer）であるＩｄＰが認めた認証器により生成された正規の認証用公開鍵であることが保証される。ＶＣの発行者（Issuer）であるＩｄＰ以外の各認証サーバ（Verifier）も、ＶＣの発行者（Issuer）であるＩｄＰを信頼している場合、ＶＣの発行者（Issuer）であるＩｄＰにより保証された正規の認証用公開鍵として、ＶＣに搭載された認証用公開鍵をＦＩＤＯ認証に使用することができる。すなわち、あるＲＰ／ＩｄＰにおいて一度生成された認証用公開鍵を、複数のＲＰ／ＩｄＰ間で使い回すことができる。

なお、必要であれば、ＶＣの発行を受けた利用者Ｕ（Holder）は、ＶＣの発行者（Issuer）以外の各認証サーバ（Verifier）にも、認証用公開鍵を搭載したＶＣを提供してもよい。あるいは、ＶＣの発行者（Issuer）であるＩｄＰが、直接、各認証サーバ（Verifier）に認証用公開鍵を提供してもよい。

本実施形態では、基本的に、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、認証用公開鍵を管理（登録・保管）しないものとする。すなわち、ＩｄＰやＦＳＰは、認証用公開鍵を「保有」しない。認証用公開鍵が必要な場合には、ＶＣに搭載された認証用公開鍵を使用するものとする。但し、必要であれば、ＩｄＰやＦＳＰでも認証用公開鍵を管理するようにしてもよい。なお、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、登録用公開鍵についても自身で管理しないようにしてもよい。

〔１－３．認証時〕
本実施形態では、ＶＣに登録した公開鍵情報を搭載する。例えば、端末装置１０が、ＶＣと、秘密鍵と公開鍵の鍵ペアとを保持し、公開鍵を搭載したＶＣを認証サーバ（ＦＩＤＯサーバ）であるサーバ装置１００に送信する。図４は、ＶＣに公開鍵情報を搭載する方式における認証時の処理の概要を示す説明図である。図４では、認証サーバ（Verifier）であるサーバ装置１００は複数存在する。複数のサーバ装置１００（１００－ｉ、ｉ＝１～ｎ：ｎは任意）の各々は、個別に、ＶＣに搭載された認証用公開鍵を用いてＦＩＤＯ認証を行う。

例えば、図４に示すように、利用者Ｕの端末装置１０は、ネットワークＮ（図５参照）を介して、認証サーバの１台（Verifier １）であるサーバ装置１００－１に認証要求（Auth request）とともに、認証用公開鍵を搭載したＶＣを送信する（ステップＳ２１）。

続いて、認証サーバの１台であるサーバ装置１００－１は、利用者Ｕの端末装置１０からの認証要求（Auth request）に応じて、ＶＣの真正性を検証するとともに、ＶＣに搭載された認証用公開鍵を取り出して通常のＦＩＤＯ認証を行い、ＦＩＤＯ認証に成功した場合、利用者ＵのユーザＩＤを抽出し、パスワード入力によるパスワード認証を行う（ステップＳ２２）。

認証サーバ（Verifier）は任意の事業者等のサーバであり、ＶＣの発行者（Issuer）であるＩｄＰも含む。各認証サーバ（Verifier）はＶＣの発行者（Issuer）を信頼する。また、認証サーバ（Verifier）は、ＶＣの真正性については、事前に公開されている登録用公開鍵（又は認証用公開鍵とは別の署名検証用公開鍵）で署名検証を行い、ＶＣの真正性によって正しく登録されていることを確認する。

さらに、認証サーバ（Verifier）は、ＶＣに搭載された認証用公開鍵を用いてＦＩＤＯ認証を行うことで、ＶＣの適切性を検証する。そのため、ユーザは任意の属性セットのみを持ち運んで認証を行うことが可能である。任意の属性セットは、例えば生体認証のための生体情報等の認証情報である。

また、認証サーバ（Verifier）は、認証用公開鍵を管理しないため、鍵の識別をするためのＤＩＤ（Decentralized Identifier）も必要ない。すなわち、公開鍵の参照ＤＩＤが不要となる。公開鍵の参照ＤＩＤは、公開鍵の場所を示す公開鍵ＵＲＬ等である。本実施形態では、参照ＤＩＤとユーザＩＤとを鍵ＩＤに紐付けて保管する必要がない。また、鍵ＩＤを用いて鍵レジストリから公開鍵を取得する必要もないので、鍵レジストリも不要となる。

なお、実際には、サーバ装置１００－１は、ネットワークＮ（図５参照）を介して、ＦＳＰであるサーバ装置２００にＦＩＤＯ認証要求（FIDO Auth request）とともに、認証用公開鍵を搭載したＶＣを送信し、ＦＳＰであるサーバ装置２００でＶＣに搭載された認証用公開鍵を用いたＦＩＤＯ認証を行い、ＦＳＰであるサーバ装置２００からＦＩＤＯ認証結果を受信してもよい。

続いて、認証サーバの１台であるサーバ装置１００－１は、認証に成功した場合、ネットワークＮ（図５参照）を介して、利用者Ｕの端末装置１０にサービスを提供する（ステップＳ２３）。

同様に、利用者Ｕの端末装置１０は、ネットワークＮ（図５参照）を介して、認証サーバの１台（Verifier ２）であるサーバ装置１００－２に認証要求（Auth request）とともに、認証用公開鍵を搭載したＶＣを送信する（ステップＳ２４）。

なお、サーバ装置１００－２に送信される認証用公開鍵を搭載したＶＣは、サーバ装置１００－１に送信される認証用公開鍵を搭載したＶＣと同じである。すなわち、認証用公開鍵及びＶＣは共通である。

続いて、認証サーバの１台であるサーバ装置１００－２は、利用者Ｕの端末装置１０からの認証要求（Auth request）に応じて、ＶＣの真正性を検証するとともに、ＶＣに搭載された認証用公開鍵を取り出して通常のＦＩＤＯ認証を行い、ＦＩＤＯ認証に成功した場合、利用者ＵのユーザＩＤを抽出し、パスワード入力によるパスワード認証を行う（ステップＳ２５）。

続いて、認証サーバの１台であるサーバ装置１００－２は、認証に成功した場合、ネットワークＮ（図５参照）を介して、利用者Ｕの端末装置１０にサービスを提供する（ステップＳ２６）。

また、他の認証サーバ（Verifier Ｎ）であるサーバ装置１００－ｎについても、上記のサーバ装置１００－１、サーバ装置１００－２と同様の処理を行う。

〔１－４．信頼できる登録先〕
本実施形態では、第１事業者（ＲＰ１）で登録し、第１事業者（ＲＰ１）で認証する場合、ユーザＩＤを特定して認証することに限らず、属性を持つ個人として認証することも可能になる。また、第２事業者（ＲＰ２）で認証する場合でも、新たな鍵ペアを生成することなく、第１事業者（ＲＰ１）と同じ公開鍵で認証可能となる。

このとき、第２事業者（ＲＰ２）は、ＶＣを参照して、ユーザが第１事業者（ＲＰ１）にも登録されたユーザであることを認識する。そこで、第２事業者（ＲＰ２）は、ユーザが第１事業者（ＲＰ１）の登録ユーザであることを考慮したサービスを提供することもできる。

また、官製システムで登録し、民間システムで認証及びログインする場合、ユーザＩＤを明示的に紐付けなくても利用可能である。官製システムの場合は、ユーザの本人確認の信頼性が高い（公的個人認証サービス等）。官製システムから、認証用公開鍵を搭載したＶＣが発行された場合は、ＶＣ及び認証用公開鍵をそのまま信頼しても問題ないと考えられる。また、官製システムの場合、マイナンバー（個人番号）や免許証番号、又は電子証明書等により、ユーザを特定することができる。例えば、第１事業者（ＲＰ１）が行政機関（又はそれに準ずる公共機関）で、第２事業者（ＲＰ２）が民間企業等である場合、民間システムで使用されているユーザＩＤを特定して認証しなくてもよい。

また、何を信頼するかにより、様々なサービスの提供の形態が考えられる。例えば、以下のようなケースが考えられる。

（１）ＶＣの中身を信頼するケース
ＶＣの中身により、ユーザが○○大学の学生であると証明された場合、学割の発行／適用を許可する。また、ＶＣの中身により、ユーザが△△株式会社の社員であると証明された場合、社割の発行／適用を許可する。あるいは、ユーザの入館を許可し、社員ゲートを開放する。

（２）ＶＣの発行者（Issuer）であるＩｄＰの属性を信頼するケース
ＶＣの発行者（Issuer）であるＩｄＰが第１事業者（ＲＰ１）である場合、ISMS認証（ISO27001）を取得済みの企業であることを条件に、ユーザのログインを許可する。また、ＶＣの発行者（Issuer）であるＩｄＰが第２事業者（ＲＰ２）である場合、ＦＩＤＯ認定試験に合格したサーバであることを条件に、ユーザのログインを許可する。しかし、金融サービスについては別途、認証サーバ（verifier）が本人確認をするものとする。

〔１－５．２回目以降の認証形態〕
本実施形態では、利用者Ｕの端末装置１０は、毎回、公開鍵を搭載したＶＣを送信する。ただし、他の実施形態として、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００が１回目のＦＩＤＯ認証で使用した公開鍵を保管しておいて、２回目以降は保管済みの公開鍵を用いてＦＩＤＯ認証してもよい。

これにより、登録と認証の分離（登録と認証とでＦＩＤＯサーバを分けること）が可能になる。また、複数のＦＩＤＯサーバを１回の登録で利用可能になる。さらに、ユーザＩＤ（Identifier）が不要になる（必須ではなくなる）と考えられる。

すなわち、ＶＣ提示後、２回目以降の認証形態として、毎回ＶＣを提示して認証してもよいし、最初のＶＣに包含されている鍵を認証サーバ（verifier）に登録するようにしてもよい。

例えば、第１事業者（ＲＰ１）でＶＣを発行し、そのＶＣを第２事業者（ＲＰ２）に持っていくと、それ以降はＶＣに搭載された第１事業者（ＲＰ１）用の認証用公開鍵で第２事業者（ＲＰ２）にもログインできるようになる。

また、最初の認証だけＶＣ依存の認証を行い、次回以降のために新たな鍵ペアを認証サーバ（verifier）に登録するようにしてもよい。すなわち、最初の１回だけＶＣに搭載された第１の認証用公開鍵を用いた認証を行い、新たな鍵ペアとして生成された第２の認証用公開鍵を認証サーバ（verifier）に登録し、２回目以降は第２の認証用公開鍵を用いた認証を行うようにしてもよい。

〔１－６．ＶＣによって伝達できる情報〕
書類送付、免許証／マイナンバーカードなどにより本人確認済みである場合、ＶＣの基本的な使い方として、様々な属性を持ち歩くことができる。

また、ユーザのＩＤの有無により、認証サーバ（verifier）からＶＣの発行者（Issuer）への問い合わせ方法が異なる。

登録済みのユーザなど、ユーザのＩＤありの場合には、認証サーバ（verifier）は、ユーザのＩＤを用いて後から該当ユーザをＶＣの発行者（Issuer）であるＩｄＰに問い合わせることが可能である。

初回利用時／未登録のユーザなど、ユーザのＩＤなしの場合には、認証サーバ（verifier）は、ユーザのＩＤを用いて後から該当ユーザをＶＣの発行者（Issuer）であるＩｄＰに問い合わせることができない。しかし、本実施形態では、ＶＣの発行者（Issuer）であるＩｄＰに、ＶＣのＩＤで該当ユーザを問い合わせることが可能である。

〔２．情報処理システムの構成例〕
次に、図５を用いて、実施形態に係るサーバ装置１００が含まれる情報処理システム１の構成について説明する。図５は、実施形態に係る情報処理システム１の構成例を示す図である。図５に示すように、実施形態に係る情報処理システム１は、端末装置１０とサーバ装置１００とサーバ装置２００とを含む。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。ネットワークＮは、例えば、ＬＡＮ（Local Area Network）や、インターネット等のＷＡＮ（Wide Area Network）である。

また、図５に示す情報処理システム１に含まれる各装置の数は図示したものに限られない。例えば、図５では、図示の簡略化のため、端末装置１０を１台のみ示したが、これはあくまでも例示であって限定されるものではなく、２台以上であってもよい。

端末装置１０は、利用者Ｕによって使用される情報処理装置である。例えば、端末装置１０は、スマートフォン（スマホ）やタブレット端末等のスマートデバイス、フィーチャーフォン（ガラケー・ガラホ）等の携帯電話、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、通信機能を備えたゲーム機やＡＶ機器、情報家電・デジタル家電、カーナビゲーションシステム、スマートウォッチやヘッドマウントディスプレイ等のウェアラブルデバイス（Wearable Device）、スマートグラス等である。また、端末装置１０は、ＩＯＴ（Internet of Things）に対応した住宅・建物、車、家電製品、電子機器等であってもよい。

また、かかる端末装置１０は、ＬＴＥ（Long Term Evolution）、４Ｇ（4th Generation）、５Ｇ（5th Generation：第５世代移動通信システム）等の無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local Area Network）等の近距離無線通信を介してネットワークＮに接続し、サーバ装置１００と通信することができる。

サーバ装置１００及びサーバ装置２００は、例えばＰＣやブレードサーバ（blade server）等のコンピュータ、あるいはメインフレーム又はワークステーション等である。なお、サーバ装置１００及びサーバ装置２００は、クラウドコンピューティングにより実現されてもよい。

〔３．端末装置の構成例〕
次に、図６を用いて、端末装置１０の構成について説明する。図６は、端末装置１０の構成例を示す図である。図６に示すように、端末装置１０は、通信部１１と、表示部１２と、入力部１３と、測位部１４と、センサ部２０と、制御部３０（コントローラ）と、記憶部４０とを備える。

（通信部１１）
通信部１１は、ネットワークＮ（図５参照）と有線又は無線で接続され、ネットワークＮを介して、サーバ装置１００との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ（Network Interface Card）やアンテナ等によって実現される。

（表示部１２）
表示部１２は、位置情報等の各種情報を表示する表示デバイスである。例えば、表示部１２は、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）や有機ＥＬディスプレイ（Organic Electro-Luminescent Display）である。また、表示部１２は、タッチパネル式のディスプレイであるが、これに限定されるものではない。

（入力部１３）
入力部１３は、利用者Ｕから各種操作を受け付ける入力デバイスである。例えば、入力部１３は、文字や数字等を入力するためのボタン等を有する。なお、入力部１３は、入出力ポート（I/O port）やＵＳＢ（Universal Serial Bus）ポート等であってもよい。また、表示部１２がタッチパネル式のディスプレイである場合、表示部１２の一部が入力部１３として機能する。また、入力部１３は、利用者Ｕから音声入力を受け付けるマイク等であってもよい。マイクはワイヤレスであってもよい。

（測位部１４）
測位部１４は、ＧＰＳ（Global Positioning System）の衛星から送出される信号（電波）を受信し、受信した信号に基づいて、自装置である端末装置１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。すなわち、測位部１４は、端末装置１０の位置を測位する。なお、ＧＰＳは、ＧＮＳＳ（Global Navigation Satellite System）の一例に過ぎない。

また、測位部１４は、ＧＰＳ以外にも、種々の手法により位置を測位することができる。例えば、測位部１４は、位置補正等のための補助的な測位手段として、下記のように、端末装置１０の様々な通信機能を利用して位置を測位してもよい。

（Ｗｉ－Ｆｉ測位）
例えば、測位部１４は、端末装置１０のＷｉ－Ｆｉ（登録商標）通信機能や、各通信会社が備える通信網を利用して、端末装置１０の位置を測位する。具体的には、測位部１４は、Ｗｉ－Ｆｉ通信等を行い、付近の基地局やアクセスポイントとの距離を測位することにより、端末装置１０の位置を測位する。

（ビーコン測位）
また、測位部１４は、端末装置１０のＢｌｕｅｔｏｏｔｈ（登録商標）機能を利用して位置を測位してもよい。例えば、測位部１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）機能によって接続されるビーコン（beacon）発信機と接続することにより、端末装置１０の位置を測位する。

（地磁気測位）
また、測位部１４は、予め測定された構造物の地磁気のパターンと、端末装置１０が備える地磁気センサとに基づいて、端末装置１０の位置を測位する。

（ＲＦＩＤ測位）
また、例えば、端末装置１０が駅改札や店舗等で使用される非接触型ＩＣカードと同等のＲＦＩＤ（Radio Frequency Identification）タグの機能を備えている場合、もしくはＲＦＩＤタグを読み取る機能を備えている場合、端末装置１０によって決済等が行われた情報とともに、使用された位置が記録される。測位部１４は、かかる情報を取得することで、端末装置１０の位置を測位してもよい。また、位置は、端末装置１０が備える光学式センサや、赤外線センサ等によって測位されてもよい。

測位部１４は、必要に応じて、上述した測位手段の一つ又は組合せを用いて、端末装置１０の位置を測位してもよい。

（センサ部２０）
センサ部２０は、端末装置１０に搭載又は接続される各種のセンサを含む。なお、接続は、有線接続、無線接続を問わない。例えば、センサ類は、ウェアラブルデバイスやワイヤレスデバイス等、端末装置１０以外の検知装置であってもよい。図６に示す例では、センサ部２０は、加速度センサ２１と、ジャイロセンサ２２と、気圧センサ２３と、気温センサ２４と、音センサ２５と、光センサ２６と、磁気センサ２７と、画像センサ（カメラ）２８とを備える。

なお、上記した各センサ２１～２８は、あくまでも例示であって限定されるものではない。すなわち、センサ部２０は、各センサ２１～２８のうちの一部を備える構成であってもよいし、各センサ２１～２８に加えてあるいは代えて、湿度センサ等その他のセンサを備えてもよい。

加速度センサ２１は、例えば、３軸加速度センサであり、端末装置１０の移動方向、速度、及び、加速度等の端末装置１０の物理的な動きを検知する。ジャイロセンサ２２は、端末装置１０の角速度等に基づいて３軸方向の傾き等の端末装置１０の物理的な動きを検知する。気圧センサ２３は、例えば端末装置１０の周囲の気圧を検知する。

端末装置１０は、上記した加速度センサ２１やジャイロセンサ２２、気圧センサ２３等を備えることから、これらの各センサ２１～２３等を利用した歩行者自律航法（ＰＤＲ：Pedestrian Dead-Reckoning）等の技術を用いて端末装置１０の位置を測位することが可能になる。これにより、ＧＰＳ等の測位システムでは取得することが困難な屋内での位置情報を取得することが可能になる。

例えば、加速度センサ２１を利用した歩数計により、歩数や歩くスピード、歩いた距離を算出することができる。また、ジャイロセンサ２２を利用して、利用者Ｕの進行方向や視線の方向、体の傾きを知ることができる。また、気圧センサ２３で検知した気圧から、利用者Ｕの端末装置１０が存在する高度やフロアの階数を知ることもできる。

気温センサ２４は、例えば端末装置１０の周囲の気温を検知する。音センサ２５は、例えば端末装置１０の周囲の音を検知する。光センサ２６は、端末装置１０の周囲の照度を検知する。磁気センサ２７は、例えば端末装置１０の周囲の地磁気を検知する。画像センサ２８は、端末装置１０の周囲の画像を撮像する。

上記した気圧センサ２３、気温センサ２４、音センサ２５、光センサ２６及び画像センサ２８は、それぞれ気圧、気温、音、照度を検知したり、周囲の画像を撮像したりすることで、端末装置１０の周囲の環境や状況等を検知することができる。また、端末装置１０の周囲の環境や状況等から、端末装置１０の位置情報の精度を向上させることが可能になる。

（制御部３０）
制御部３０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ、入出力ポート等を有するマイクロコンピュータや各種の回路を含む。また、制御部３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路等のハードウェアで構成されてもよい。制御部３０は、送信部３１と、受信部３２と、処理部３３とを有する。

（送信部３１）
送信部３１は、例えば入力部１３を用いて利用者Ｕにより入力された各種情報や、端末装置１０に搭載又は接続された各センサ２１～２８によって検知された各種情報、測位部１４によって測位された端末装置１０の位置情報等を、通信部１１を介してサーバ装置１００へ送信することができる。

（受信部３２）
受信部３２は、通信部１１を介して、サーバ装置１００から提供される各種情報や、サーバ装置１００からの各種情報の要求を受信することができる。

（処理部３３）
処理部３３は、表示部１２等を含め、端末装置１０全体を制御する。例えば、処理部３３は、送信部３１によって送信される各種情報や、受信部３２によって受信されたサーバ装置１００からの各種情報を表示部１２へ出力して表示させることができる。

また、処理部３３は、登録要求部３３Ａと、鍵生成部３３Ｂと、ＶＣ管理部３３Ｃと、認証要求部３３Ｄとを有する。なお、実際には、処理部３３は、アプリを起動又はプログラムを実行することで、下記の登録要求部３３Ａ、鍵生成部３３Ｂ、ＶＣ管理部３３Ｃ、及び認証要求部３３Ｄとして機能してもよい。

（登録要求部３３Ａ）
登録要求部３３Ａは、送信部３１を介して、ＩｄＰであるサーバ装置１００に、登録要求（Reg request）を送信する。そして、登録要求部３３Ａは、登録要求に対する応答として、受信部３２を介して、ＩｄＰであるサーバ装置１００から発行されたＶＣを受け取る。

（鍵生成部３３Ｂ）
鍵生成部３３Ｂは、秘密鍵と公開鍵との鍵ペアを生成する。例えば、鍵生成部３３Ｂは、登録用秘密鍵と登録用公開鍵との鍵ペアを生成する。また、鍵生成部３３Ｂは、認証用秘密鍵と認証用公開鍵との鍵ペアを生成する。なお、鍵生成部３３Ｂは、ＶＣの発行前／発行時に、送信部３１を介して、ＶＣの発行者（Issuer）であるＩｄＰに、認証用公開鍵を送信・提供してもよい。

（ＶＣ管理部３３Ｃ）
ＶＣ管理部３３Ｃは、ＶＣの発行者（Issuer）であるＩｄＰから発行されたＶＣ（Verifiable Credentials：検証可能な資格証明書）を管理する。例えば、ＶＣ管理部３３Ｃは、ＩｄＰであるサーバ装置１００から発行されたＶＣを記憶部４０に保管する。本実施形態では、ＶＣ管理部３３Ｃは、認証用公開鍵を搭載したＶＣを管理する。なお、ＶＣ管理部３３Ｃは、ＩｄＰであるサーバ装置１００から指示／許可を受けて（ＩｄＰであるサーバ装置１００の制御下で）、認証用公開鍵をＶＣに搭載してもよい。

（認証要求部３３Ｄ）
認証要求部３３Ｄは、送信部３１を介して、ＩｄＰであるサーバ装置１００に、認証要求（Auth request）を送信する。このとき、認証要求部３３Ｄは、送信部３１を介して、ＩｄＰであるサーバ装置１００に、認証要求とともに、認証用公開鍵を搭載したＶＣを送信する。本実施形態では、認証として、ＦＩＤＯ認証とパスワード認証とが実施される。そして、認証要求部３３Ｄは、認証に成功した場合、ＩｄＰであるサーバ装置１００にログインし、ＩｄＰであるサーバ装置１００（又はその先にある連携ＲＰ／ＳＰ）からサービスの提供を受ける。

（記憶部４０）
記憶部４０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置によって実現される。かかる記憶部４０には、各種プログラムや各種データ等が記憶される。

また、記憶部４０のセキュア領域（セキュアエレメント）には、登録用秘密鍵と登録用公開鍵との鍵ペア（４０Ａ）と、認証用秘密鍵と認証用公開鍵との鍵ペア（４０Ｂ）と、認証用公開鍵を搭載したＶＣ（４０Ｃ）とが記憶される。このとき、各鍵ペアとＶＣとは異なるセキュア領域に記憶されてもよい。なお、実際には、セキュア領域に記憶されるのは、秘密鍵とＶＣだけでも良い。公開鍵は、ノーマル領域に記憶されてもよいし、記憶されなくてもよい。

〔４．サーバ装置の構成例〕
次に、図７を用いて、実施形態に係るサーバ装置１００の構成について説明する。図７は、実施形態に係るサーバ装置１００の構成例を示す図である。図７に示すように、サーバ装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを備える。

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。また、通信部１１０は、ネットワークＮ（図５参照）と有線又は無線で接続される。

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ＨＤＤ、ＳＳＤ、光ディスク等の記憶装置によって実現される。図７に示すように、記憶部１２０は、利用者情報データベース１２１と、履歴情報データベース１２２とを有する。

（利用者情報データベース１２１）
利用者情報データベース１２１は、利用者Ｕに関する利用者情報を記憶する。例えば、利用者情報データベース１２１は、利用者Ｕの属性等の種々の情報を記憶する。図８は、利用者情報データベース１２１の一例を示す図である。図８に示した例では、利用者情報データベース１２１は、「利用者ＩＤ（Identifier）」、「年齢」、「性別」、「自宅」、「勤務地」、「興味」といった項目を有する。

「利用者ＩＤ」は、利用者Ｕを識別するための識別情報を示す。なお、「利用者ＩＤ」は、利用者Ｕの連絡先（電話番号、メールアドレス等）であってもよいし、利用者Ｕの端末装置１０を識別するための識別情報であってもよい。

また、「年齢」は、利用者ＩＤにより識別される利用者Ｕの年齢を示す。なお、「年齢」は、利用者Ｕの具体的な年齢（例えば３５歳など）を示す情報であってもよいし、利用者Ｕの年代（例えば３０代など）を示す情報であってもよい。あるいは、「年齢」は、利用者Ｕの生年月日を示す情報であってもよいし、利用者Ｕの世代（例えば８０年代生まれなど）を示す情報であってもよい。また、「性別」は、利用者ＩＤにより識別される利用者Ｕの性別を示す。

また、「自宅」は、利用者ＩＤにより識別される利用者Ｕの自宅の位置情報を示す。なお、図８に示す例では、「自宅」は、「ＬＣ１１」といった抽象的な符号を図示するが、緯度経度情報等であってもよい。また、例えば、「自宅」は、地域名や住所であってもよい。

また、「勤務地」は、利用者ＩＤにより識別される利用者Ｕの勤務地（学生の場合は学校）の位置情報を示す。なお、図８に示す例では、「勤務地」は、「ＬＣ１２」といった抽象的な符号を図示するが、緯度経度情報等であってもよい。また、例えば、「勤務地」は、地域名や住所であってもよい。

また、「興味」は、利用者ＩＤにより識別される利用者Ｕの興味を示す。すなわち、「興味」は、利用者ＩＤにより識別される利用者Ｕが関心の高い対象を示す。例えば、「興味」は、利用者Ｕが検索エンジンに入力して検索した検索クエリ（キーワード）等であってもよい。なお、図８に示す例では、「興味」は、各利用者Ｕに１つずつ図示するが、複数であってもよい。

例えば、図８に示す例において、利用者ＩＤ「Ｕ１」により識別される利用者Ｕの年齢は、「２０代」であり、性別は、「男性」であることを示す。また、例えば、利用者ＩＤ「Ｕ１」により識別される利用者Ｕは、自宅が「ＬＣ１１」であることを示す。また、例えば、利用者ＩＤ「Ｕ１」により識別される利用者Ｕは、勤務地が「ＬＣ１２」であることを示す。また、例えば、利用者ＩＤ「Ｕ１」により識別される利用者Ｕは、「スポーツ」に興味があることを示す。

ここで、図８に示す例では、「Ｕ１」、「ＬＣ１１」及び「ＬＣ１２」といった抽象的な値を用いて図示するが、「Ｕ１」、「ＬＣ１１」及び「ＬＣ１２」には、具体的な文字列や数値等の情報が記憶されるものとする。以下、他の情報に関する図においても、抽象的な値を図示する場合がある。

なお、利用者情報データベース１２１は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、利用者情報データベース１２１は、利用者Ｕの端末装置１０に関する各種情報を記憶してもよい。また、利用者情報データベース１２１は、利用者Ｕのデモグラフィック（人口統計学的属性）、サイコグラフィック（心理学的属性）、ジオグラフィック（地理学的属性）、ベヘイビオラル（行動学的属性）等の属性に関する情報を記憶してもよい。例えば、利用者情報データベース１２１は、氏名、家族構成、出身地（地元）、職業、職位、収入、資格、居住形態（戸建、マンション等）、車の有無、通学・通勤時間、通学・通勤経路、定期券区間（駅、路線等）、利用頻度の高い駅（自宅・勤務地の最寄駅以外）、習い事（場所、時間帯等）、趣味、興味、ライフスタイル等の情報を記憶してもよい。

（履歴情報データベース１２２）
履歴情報データベース１２２は、利用者Ｕの行動を示す履歴情報（ログデータ）に関する各種情報を記憶する。図９は、履歴情報データベース１２２の一例を示す図である。図９に示した例では、履歴情報データベース１２２は、「利用者ＩＤ」、「位置履歴」、「検索履歴」、「閲覧履歴」、「購入履歴」、「投稿履歴」といった項目を有する。

「利用者ＩＤ」は、利用者Ｕを識別するための識別情報を示す。また、「位置履歴」は、利用者Ｕの位置や移動の履歴である位置履歴を示す。また、「検索履歴」は、利用者Ｕが入力した検索クエリの履歴である検索履歴を示す。また、「閲覧履歴」は、利用者Ｕが閲覧したコンテンツの履歴である閲覧履歴を示す。また、「購入履歴」は、利用者Ｕによる購入の履歴である購入履歴を示す。また、「投稿履歴」は、利用者Ｕによる投稿の履歴である投稿履歴を示す。なお、「投稿履歴」は、利用者Ｕの所有物に関する質問を含んでいてもよい。

例えば、図９に示す例において、利用者ＩＤ「Ｕ１」により識別される利用者Ｕは、「位置履歴＃１」の通りに移動し、「検索履歴＃１」の通りに検索し、「閲覧履歴＃１」の通りにコンテンツを閲覧し、「購入履歴＃１」の通りに所定の店舗等で所定の商品等を購入し、「投稿履歴＃１」の通りに投稿したことを示す。

ここで、図９に示す例では、「Ｕ１」、「位置履歴＃１」、「検索履歴＃１」、「閲覧履歴＃１」、「購入履歴＃１」及び「投稿履歴＃１」といった抽象的な値を用いて図示するが、「Ｕ１」、「位置履歴＃１」、「検索履歴＃１」、「閲覧履歴＃１」、「購入履歴＃１」及び「投稿履歴＃１」には、具体的な文字列や数値等の情報が記憶されるものとする。

なお、履歴情報データベース１２２は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、履歴情報データベース１２２は、利用者Ｕの所定のサービスの利用履歴等を記憶してもよい。また、履歴情報データベース１２２は、利用者Ｕの実店舗の来店履歴又は施設の訪問履歴等を記憶してもよい。また、履歴情報データベース１２２は、利用者Ｕの端末装置１０を用いた決済（電子決済）での決済履歴等を記憶してもよい。

（制御部１３０）
図７に戻り、説明を続ける。制御部１３０は、コントローラ（Controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等によって、サーバ装置１００の内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等の記憶領域を作業領域として実行されることにより実現される。図７に示す例では、制御部１３０は、取得部１３１と、受付部１３２と、登録処理部１３３と、発行部１３４と、抽出部１３５と、管理部１３６と、認証処理部１３７と、提供部１３８とを有する。

（取得部１３１）
取得部１３１は、利用者Ｕ（ユーザ）により入力された検索クエリを取得する。例えば、取得部１３１は、利用者Ｕが検索エンジン等に検索クエリを入力してキーワード検索を行った際に、通信部１１０を介して、当該検索クエリを取得する。すなわち、取得部１３１は、通信部１１０を介して、利用者Ｕにより検索エンジンやサイト又はアプリの検索窓に入力されたキーワードを取得する。

また、取得部１３１は、通信部１１０を介して、利用者Ｕに関する利用者情報を取得する。例えば、取得部１３１は、利用者Ｕの端末装置１０から、利用者Ｕを示す識別情報（利用者ＩＤ等）や、利用者Ｕの位置情報、利用者Ｕの属性情報等を取得する。また、取得部１３１は、利用者Ｕのユーザ登録時に、利用者Ｕを示す識別情報や、利用者Ｕの属性情報等を取得してもよい。そして、取得部１３１は、利用者情報を、記憶部１２０の利用者情報データベース１２１に登録する。

また、取得部１３１は、通信部１１０を介して、利用者Ｕの行動を示す各種の履歴情報（ログデータ）を取得する。例えば、取得部１３１は、利用者Ｕの端末装置１０から、あるいは利用者ＩＤ等に基づいて各種サーバ等から、利用者Ｕの行動を示す各種の履歴情報を取得する。そして、取得部１３１は、各種の履歴情報を、記憶部１２０の履歴情報データベース１２２に登録する。

（受付部１３２）
受付部１３２は、登録時に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から登録要求を受け取る。なお、受付部１３２は、ＶＣ（Verifiable Credentials：検証可能な資格証明書）を発行する前に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から、認証用公開鍵を受け取ってもよい。なお、受付部１３２は、上記の取得部１３１であってもよい。

また、受付部１３２は、認証時に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から、認証要求とともに、認証用公開鍵を搭載したＶＣを受け取る。

また、受付部１３２は、パスワード認証が行われた際に、通信部１１０を介して、利用者Ｕの端末装置１０から利用者ＵのユーザＩＤ及びパスワードを受け取る。例えば、受付部１３２は、利用者Ｕのユーザ登録時やユーザ認証に、通信部１１０を介して、利用者Ｕの端末装置１０から利用者ＵのユーザＩＤ及びパスワードを受け取る。なお、実際には、受付部１３２は、ユーザＩＤが入力済みである場合には、パスワードのみ受け取ってもよい。

（登録処理部１３３）
登録処理部１３３は、登録要求に応じて、認証器として端末装置１０を用いる利用者Ｕの登録処理を行う。このとき、登録処理部１３３は、登録時に、ＦＩＤＯ認証を実施する他のサーバ装置（認証サーバ）に、事前に公開された登録用公開鍵を用いたＦＩＤＯ登録を要求し、応答としてＦＩＤＯ登録結果を受信し、ＦＩＤＯ登録結果に基づいて、ＦＩＤＯ登録の成否を判定し、ＦＩＤＯ登録に成功した場合に、利用者Ｕの登録処理を行う。例えば、登録処理部１３３は、ＦＩＤＯ登録に成功した場合に、利用者ＵのユーザＩＤ及びパスワードを含むユーザ登録を行う。

なお、ＦＩＤＯ登録結果は、認証器の真正性確認（署名検証）の結果であってもよい。すなわち、登録処理部１３３は、認証器の真正性確認（署名検証に成功した場合に、利用者ＵのユーザＩＤ及びパスワードを含むユーザ登録を行うようにしてもよい。

（発行部１３４）
発行部１３４は、通信部１１０を介して、認証器である利用者Ｕの端末装置１０に、検証可能な資格証明書であるＶＣを発行する。例えば、発行部１３４は、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から認証用公開鍵を取得した後、認証器である利用者Ｕの端末装置１０に、認証用公開鍵を搭載したＶＣを発行する。あるいは、発行部１３４は、通信部１１０を介して、認証器である利用者Ｕの端末装置１０に、検証可能な資格証明書であるＶＣの生成に使用される情報（登録パラメータ）を送信・提供し、認証用公開鍵を搭載したＶＣの生成を要求する。例えば、発行部１３４は、ＶＣの発行として、ＶＣの生成に使用される情報（登録パラメータ）と、認証用公開鍵を搭載したＶＣの生成の指示／許可とを、認証器である利用者Ｕの端末装置１０に送信・提供してもよい。なお、発行部１３４は、後述する提供部１３８であってもよい。

（抽出部１３５）
抽出部１３５は、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出す。なお、実際には、抽出部１３５は、ＶＣの真正性が確認された場合に、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出すようにしてもよい。

（管理部１３６）
管理部１３６は、ＶＣに搭載された認証用公開鍵を保管する。例えば、管理部１３６は、ＶＣから取り出された認証用公開鍵を保管してもよい。あるいは、管理部１３６は、認証器である利用者Ｕの端末装置１０から受け取った認証用公開鍵を保管してもよい。なお、管理部１３６は、必須ではない。例えば、２回目以降のＦＩＤＯ認証に用いるため、ＶＣに搭載された認証用公開鍵を保管する必要がある場合にのみ、管理部１３６を設置／用意するものとする。

（認証処理部１３７）
認証処理部１３７は、認証時に、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する。例えば、認証処理部１３７は、認証時に、ＶＣの真正性を検証するとともに、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する。

このとき、認証処理部１３７は、認証時に、ＦＩＤＯ認証を実施する他のサーバ装置（認証サーバ）に、認証用公開鍵を搭載したＶＣ、又はＶＣから取り出された認証用公開鍵を送信してＦＩＤＯ認証を要求し、応答としてＦＩＤＯ認証結果を受信し、ＦＩＤＯ認証結果に基づいて、ＦＩＤＯ認証の成否を判定してもよい。

また、認証処理部１３７は、１回目はＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施し、２回目以降は管理部１３６に保管されている認証用公開鍵を用いてＦＩＤＯ認証を実施してもよい。

（提供部１３８）
提供部１３８は、ＦＩＤＯ認証に成功した場合、通信部１１０を介して、利用者Ｕの端末装置１０（又は利用者Ｕ自身、あるいは利用者Ｕが保有する他の機器）に、サービスを提供する。また、提供部１３８は、通信部１１０を介して、他のサーバ装置（認証サーバ）に、認証用公開鍵を提供してもよい。

〔５．処理手順〕
次に、図１０を用いて実施形態に係るサーバ装置１００による処理手順について説明する。図１０は、実施形態に係る処理手順を示すフローチャートである。なお、以下に示す処理手順は、サーバ装置１００の制御部１３０によって繰り返し実行される。

続いて、サーバ装置１００の受付部１３２は、登録時に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から登録要求を受け取る（ステップＳ１０１）。

続いて、サーバ装置１００の登録処理部１３３は、登録要求に応じてＦＩＤＯ登録を実施する（ステップＳ１０２）。例えば、登録処理部１３３は、通信部１１０を介して、ＦＩＤＯ認証を実施する他のサーバ装置（認証サーバ）に、事前に公開された登録用公開鍵を用いたＦＩＤＯ登録を要求し、応答としてＦＩＤＯ登録結果を受信し、ＦＩＤＯ登録結果に基づいて、ＦＩＤＯ登録の成否を判定する。なお、登録処理部１３７は、ＦＩＤＯ登録に失敗した場合（ステップＳ１０２：Ｎｏ）、一連の処理を終了する。あるいは、ＦＩＤＯ登録を必要とするサービスへの登録を行わないようにする。なお、ＦＩＤＯ登録結果は、認証器の真正性確認（署名検証）の結果であってもよい。すなわち、登録処理部１３３は、認証器の真正性確認（署名検証）の結果に基づいて、認証器の真正性確認（署名検証）の成否を判定してもよい。

続いて、サーバ装置１００の登録処理部１３３は、ＦＩＤＯ登録に成功した場合（ステップＳ１０２：Ｙｅｓ）、登録器として端末装置１０を用いる利用者Ｕの登録処理を行う（ステップＳ１０３）。例えば、登録処理部１３３は、利用者ＵのユーザＩＤ及びパスワードを含むユーザ登録を行う。

続いて、サーバ装置１００の発行部１３４は、通信部１１０を介して、認証器である利用者Ｕの端末装置１０に、認証用公開鍵を搭載したＶＣを発行する（ステップＳ１０４）。このとき、サーバ装置１００の発行部１３４は、ＶＣを発行する前に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０に、認証用公開鍵の生成・提供を要求し、認証器である利用者Ｕの端末装置１０から受け取った認証用公開鍵を搭載したＶＣを発行してもよい。あるいは、発行部１３４は、通信部１１０を介して、認証器である利用者Ｕの端末装置１０に対し、検証可能な資格証明書であるＶＣの生成に使用される情報（登録パラメータ）を送信・提供し、認証用公開鍵を搭載したＶＣの生成を要求してもよい。

続いて、サーバ装置１００の受付部１３２は、認証時に、通信部１１０を介して、認証器である利用者Ｕの端末装置１０から、認証要求とともに、認証用公開鍵を搭載したＶＣを受け取る（ステップＳ１０５）。

続いて、サーバ装置１００の抽出部１３５は、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出す（ステップＳ１０６）。このとき、サーバ装置１００の管理部１３６は、ＶＣから取り出された認証用公開鍵を保管して２回目以降のＦＩＤＯ認証に用いる場合、ＶＣに搭載された認証用公開鍵を保管する。

続いて、サーバ装置１００の認証処理部１３７は、ＶＣの真正性を検証する（ステップＳ１０７）。なお、認証処理部１３７は、ＶＣの真正性が確認されない場合（ステップＳ１０７：Ｎｏ）、一連の処理を終了する。あるいは、ＦＩＤＯ認証を必要とするサービスの提供を行わないようにする。

なお、実際には、サーバ装置１００の抽出部１３５は、ＶＣの真正性を検証する前（ステップＳ１０６）ではなく、ＶＣの真正性が確認された場合（ステップＳ１０７：Ｙｅｓ）に、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出すようにしてもよい。

続いて、サーバ装置１００の認証処理部１３７は、ＶＣの真正性が確認された場合（ステップＳ１０７：Ｙｅｓ）、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する（ステップＳ１０８）。例えば、認証処理部１３７は、ＦＩＤＯ認証を実施する他のサーバ装置（認証サーバ）に、認証用公開鍵を搭載したＶＣ、又はＶＣから取り出された認証用公開鍵を送信してＦＩＤＯ認証を要求し、応答としてＦＩＤＯ認証結果を受信し、ＦＩＤＯ認証結果に基づいて、ＦＩＤＯ認証の成否を判定する。なお、認証処理部１３７は、ＦＩＤＯ認証に失敗した場合（ステップＳ１０８：Ｎｏ）、一連の処理を終了する。あるいは、ＦＩＤＯ認証を必要とするサービスの提供を行わないようにする。

続いて、サーバ装置１００の提供部１３８は、ＦＩＤＯ認証に成功した場合、通信部１１０を介して、利用者Ｕの端末装置１０（又は利用者Ｕ自身、あるいは利用者Ｕが保有する他の機器）に、サービスを提供する（ステップＳ１０９）。

〔６．変形例〕
上述した端末装置１０及びサーバ装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、実施形態の変形例について説明する。

上記の実施形態において、サーバ装置１００が実行している処理の一部又は全部は、実際には、端末装置１０が実行してもよい。例えば、スタンドアローン（Stand-alone）で（端末装置１０単体で）処理が完結してもよい。この場合、端末装置１０に、上記の実施形態におけるサーバ装置１００の機能が備わっているものとする。また、上記の実施形態では、端末装置１０はサーバ装置１００と連携しているため、利用者Ｕから見れば、サーバ装置１００の処理も端末装置１０が実行しているように見える。すなわち、他の観点では、端末装置１０は、サーバ装置１００を備えているともいえる。

また、上記の実施形態において、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、ＦＩＤＯ認証と他の認証とを組み合わせて多段階認証としてもよい。例えば、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、ＦＩＤＯ認証とパスワード認証とを組み合わせて２段階認証としてもよい。あるいは、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、ＦＩＤＯ認証と秘密の質問とを組み合わせて２段階認証としてもよい。

また、上記の実施形態において、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、ＦＩＤＯ認証において、認証の３要素である「知識情報」、「所持情報」、「生体情報」のうち、２つ以上を組み合わせて認証するようにしてもよい。すなわち、ＩｄＰであるサーバ装置１００やＦＳＰであるサーバ装置２００は、多要素認証（ＭＦＡ：Multi-Factor Authentication）を採用してもよい。

〔７．効果〕
上述してきたように、本願に係る情報処理装置（端末装置１０及びサーバ装置１００）は、認証時に、認証器から認証用公開鍵を搭載したＶＣを受け取る受付部１３２と、認証用公開鍵を搭載したＶＣから、認証用公開鍵を取り出す抽出部１３５と、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理部１３７と、ＦＩＤＯ認証に成功した場合、サービスを提供する提供部１３８と、を備えることを特徴とする。

また、本願に係る情報処理装置は、認証器から、認証用公開鍵を取得する取得部と、認証器に、認証用公開鍵を搭載したＶＣを発行する発行部１３４と、をさらに備える。

あるいは、本願に係る情報処理装置は、認証器に、検証可能な資格証明書であるＶＣの生成に使用される情報を提供し、認証用公開鍵を搭載したＶＣの生成を要求する発行部１３４と、をさらに備える。

また、提供部１３８は、他の情報処理装置に、認証用公開鍵を搭載したＶＣを提供する。

また、認証処理部１３７は、ＦＩＤＯ認証を実施する他の情報処理装置に、認証用公開鍵を搭載したＶＣ、又はＶＣから取り出された認証用公開鍵を送信してＦＩＤＯ認証を要求し、応答としてＦＩＤＯ認証結果を受信し、ＦＩＤＯ認証結果に基づいて、ＦＩＤＯ認証の成否を判定する。

また、本願に係る情報処理装置は、認証器を用いるユーザの登録処理を行う登録処理部１３３をさらに備える。受付部１３２は、登録時に、認証器から登録要求を受け取る。登録処理部１３３は、ＦＩＤＯ認証を実施する他の情報処理装置に、事前に公開された登録用公開鍵を用いたＦＩＤＯ登録を要求し、応答としてＦＩＤＯ登録結果を受信し、ＦＩＤＯ登録結果に基づいて、ＦＩＤＯ登録の成否を判定し、ＦＩＤＯ登録に成功した場合、ユーザの登録処理を行う。

また、認証処理部１３７は、ＶＣの真正性を検証するとともに、ＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施する。

また、本願に係る情報処理装置は、ＶＣに搭載された認証用公開鍵を保管する管理部１３６をさらに備える。認証処理部１３７は、１回目はＶＣから取り出された認証用公開鍵を用いてＦＩＤＯ認証を実施し、２回目以降は管理部１３６に保管されている認証用公開鍵を用いてＦＩＤＯ認証を実施する。

上述した各処理のいずれかもしくは組合せにより、本願に係る情報処理装置は、認証の効率をさらに向上させることができる。

〔８．ハードウェア構成〕
また、上述した実施形態に係る端末装置１０やサーバ装置１００は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。以下、サーバ装置１００を例に挙げて説明する。図１１は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力Ｉ／Ｆ（Interface）１０６０、入力Ｉ／Ｆ１０７０、ネットワークＩ／Ｆ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラム等に基づいて動作し、各種の処理を実行する。演算装置１０３０は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等により実現される。

一次記憶装置１０４０は、ＲＡＭ（Random Access Memory）等、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等により実現される。二次記憶装置１０５０は、内蔵ストレージであってもよいし、外付けストレージであってもよい。また、二次記憶装置１０５０は、ＵＳＢ（Universal Serial Bus）メモリやＳＤ（Secure Digital）メモリカード等の取り外し可能な記憶媒体であってもよい。また、二次記憶装置１０５０は、クラウドストレージ（オンラインストレージ）やＮＡＳ（Network Attached Storage）、ファイルサーバ等であってもよい。

出力Ｉ／Ｆ１０６０は、ディスプレイ、プロジェクタ、及びプリンタ等といった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェースであり、例えば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力Ｉ／Ｆ１０７０は、マウス、キーボード、キーパッド、ボタン、及びスキャナ等といった各種の入力装置１０２０から情報を受信するためのインターフェースであり、例えば、ＵＳＢ等により実現される。

また、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０はそれぞれ出力装置１０１０及び入力装置１０２０と無線で接続してもよい。すなわち、出力装置１０１０及び入力装置１０２０は、ワイヤレス機器であってもよい。

また、出力装置１０１０及び入力装置１０２０は、タッチパネルのように一体化していてもよい。この場合、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０も、入出力Ｉ／Ｆとして一体化していてもよい。

なお、入力装置１０２０は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、又は半導体メモリ等から情報を読み出す装置であってもよい。

ネットワークＩ／Ｆ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

演算装置１０３０は、出力Ｉ／Ｆ１０６０や入力Ｉ／Ｆ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。例えば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

例えば、コンピュータ１０００がサーバ装置１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器から取得したプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行してもよい。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器と連携し、プログラムの機能やデータ等を他の機器の他のプログラムから呼び出して利用してもよい。

〔９．その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

例えば、上述したサーバ装置１００は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 情報処理システム
１０ 端末装置
３３ 処理部
３３Ａ 登録要求部
３３Ｂ 鍵生成部
３３Ｃ ＶＣ管理部
３３Ｄ 認証要求部
１００ サーバ装置（ＩｄＰ）
１１０ 通信部
１２０ 記憶部
１２１ 利用者情報データベース
１２２ 履歴情報データベース
１３０ 制御部
１３１ 取得部
１３２ 受付部
１３３ 登録処理部
１３４ 発行部
１３５ 抽出部
１３６ 管理部
１３７ 認証処理部
１３８ 提供部
２００ サーバ装置（ＦＳＰ）

Claims (10)

1. 認証時に、認証器から認証用公開鍵を搭載したＶＣを受け取る受付部と、
   前記認証用公開鍵を搭載したＶＣから、前記認証用公開鍵を取り出す抽出部と、
   前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理部と、
   前記ＦＩＤＯ認証に成功した場合、サービスを提供する提供部と、
   を備えることを特徴とする情報処理装置。
2. 前記認証器から、前記認証用公開鍵を取得する取得部と、
   前記認証器に、前記認証用公開鍵を搭載したＶＣを発行する発行部と、
   をさらに備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記認証器に、検証可能な資格証明書であるＶＣの生成に使用される情報を提供し、前記認証用公開鍵を搭載したＶＣの生成を要求する発行部と、
   をさらに備えることを特徴とする請求項１に記載の情報処理装置。
4. 前記提供部は、他の情報処理装置に、前記認証用公開鍵を搭載したＶＣを提供する
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記認証処理部は、ＦＩＤＯ認証を実施する他の情報処理装置に、前記認証用公開鍵を搭載したＶＣ、又は前記ＶＣから取り出された前記認証用公開鍵を送信してＦＩＤＯ認証を要求し、応答としてＦＩＤＯ認証結果を受信し、前記ＦＩＤＯ認証結果に基づいて、前記ＦＩＤＯ認証の成否を判定する
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記認証器を用いるユーザの登録処理を行う登録処理部をさらに備え、
   前記受付部は、登録時に、前記認証器から登録要求を受け取り、
   前記登録処理部は、ＦＩＤＯ認証を実施する他の情報処理装置に、事前に公開された登録用公開鍵を用いたＦＩＤＯ登録を要求し、応答としてＦＩＤＯ登録結果を受信し、前記ＦＩＤＯ登録結果に基づいて、前記ＦＩＤＯ登録の成否を判定し、前記ＦＩＤＯ登録に成功した場合、前記ユーザの登録処理を行う
   ことを特徴とする請求項１に記載の情報処理装置。
7. 前記認証処理部は、前記ＶＣの真正性を検証するとともに、前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施する
   ことを特徴とする請求項１に記載の情報処理装置。
8. 前記ＶＣに搭載された前記認証用公開鍵を保管する管理部をさらに備え、
   前記認証処理部は、１回目は前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施し、２回目以降は前記管理部に保管されている前記認証用公開鍵を用いてＦＩＤＯ認証を実施する
   ことを特徴とする請求項１に記載の情報処理装置。
9. 情報処理装置が実行する情報処理方法であって、
   認証時に、認証器から認証用公開鍵を搭載したＶＣを受け取る受付工程と、
   前記認証用公開鍵を搭載したＶＣから、前記認証用公開鍵を取り出す抽出工程と、
   前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理工程と、
   前記ＦＩＤＯ認証に成功した場合、サービスを提供する提供工程と、
   を含むことを特徴とする情報処理方法。
10. 認証時に、認証器から認証用公開鍵を搭載したＶＣを受け取る受付手段と、
    前記認証用公開鍵を搭載したＶＣから、前記認証用公開鍵を取り出す抽出手段と、
    前記ＶＣから取り出された前記認証用公開鍵を用いてＦＩＤＯ認証を実施する認証処理手段と、
    前記ＦＩＤＯ認証に成功した場合、サービスを提供する提供手段と、
    をコンピュータに実行させることを特徴とする情報処理プログラム。

Images