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

Abstract

【課題】ユーザ以外によるアカウントリカバリー時における本人確認判定の手法をさらに向上させる。【解決手段】本願に係る情報処理装置は、認証対象者と、認証対象者が指定した被権限委譲者との情報を管理する管理部と、認証対象者からのアカウントリカバリーの要求に対して、被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する認証処理部と、を備える。例えば、管理部は、認証対象者である子供と、被権限委譲者である親との情報を管理する。認証処理部は、子供からのアカウントリカバリーの要求に対して、親の承認で子供のアカウントリカバリーを実施する。【選択図】図１０

Description

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

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

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

しかしながら、上記の従来技術では、ユーザ以外によるアカウントリカバリー時における本人確認判定の手法に関してまだまだ改善の余地がある。

本願は、上記に鑑みてなされたものであって、ユーザ以外によるアカウントリカバリー時における本人確認判定の手法をさらに向上させることを目的とする。

本願に係る情報処理装置は、認証対象者と、前記認証対象者が指定した被権限委譲者との情報を管理する管理部と、前記認証対象者からのアカウントリカバリーの要求に対して、前記被権限委譲者の承認で前記認証対象者のアカウントリカバリーを実施する認証処理部と、を備えることを特徴とする。

実施形態の一態様によれば、ユーザ以外によるアカウントリカバリー時における本人確認判定の手法をさらに向上させることができる。

図１は、実施形態に係る情報処理方法の概要を示す説明図である。 図２は、本人確認の事例を示す図である。 図３は、アイデンティティサービスの概要を示す説明図である。 図４は、認証時に本人確認を要求する実施例の概要を示す説明図である。 図５は、アテステーションの仕組みの概要を示す説明図である。 図６は、認証強度の管理の概要の概要を示す説明図である。 図７は、認証強度の管理におけるＦＩＤＯ登録の実施例の概要を示す説明図である。 図８は、アテステーションの再実施の実施例の概要を示す説明図である。 図９は、動的な秘密の質問作成の実施例の概要を示す説明図である。 図１０は、子供から親へのアカウントリカバリーの権限委譲の実施例の概要を示す説明図である。 図１１は、実施形態に係る情報処理システムの構成例を示す図である。 図１２は、実施形態に係る端末装置の構成例を示す図である。 図１３は、実施形態に係るサーバ装置の構成例を示す図である。 図１４は、利用者情報データベースの一例を示す図である。 図１５は、履歴情報データベースの一例を示す図である。 図１６は、認証情報データベースの一例を示す図である。 図１７は、実施形態に係る処理手順を示すフローチャートである。 図１８は、ハードウェア構成の一例を示す図である。

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

〔１．情報処理方法の概要〕
まず、図１を参照し、実施形態に係る情報処理装置が行う情報処理方法の概要について説明する。図１は、実施形態に係る情報処理方法の概要を示す説明図である。なお、図１では、ユーザ以外によるアカウントリカバリー時における本人確認判定の手法をさらに向上させる場合を例に挙げて説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

〔１－１．本人強度管理〕
図２に示すように、一般的な認証システムでは、本人確認（Identity proofing）により、ユーザが本人かどうかを確認する。図２は、本人確認の事例を示す図である。本人確認では、本人があらかじめ登録した属性情報と、提示された属性情報が一致することの確認することによって、ユーザ本人とみなす。サーバ装置１００は、本人確認が適切に行われていることが前提で、本人に特化したパーソナルなアイデンティティサービスを提供することができる。例えば、ユーザの自己申告の属性情報では本人強度は低いため、高い本人確度が要求されるサービスではサービスを提供できない。

また、ユーザの個人属性情報は、本人確認の方法によって様々で信頼度にばらつきがあったり、時間の経過によって情報が陳腐化したり、実際の個人属性情報に対応して管理情報が更新されないなどの理由で信頼度が低下したりするため、従来技術では、情報の信頼性を適切に維持することが困難である。

また、技術進歩や脆弱性の発見、社会的要請や企業方針等により、セキュリティポリシーは頻繁に変更されることがある。

図３に示すように、本実施形態では、サーバ装置１００は、本人確認（身元確認）する際の個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。図３は、アイデンティティサービスの概要を示す説明図である。

例えば、サーバ装置１００は、個人属性情報の信頼度を適切に継続的に管理し、アイデンティティサービスを提供するアクセス制御時に、セキュリティポリシーに満たしてなければ満たすように、新たな認証や本人確認処理を発動する。

サーバ装置１００は、アイデンティティサービスを提供するアクセス制御時に、認証中のオンラインユーザに対する属性の確度を、認証確度と本人確度との掛け合わせにより求める。認証確度：ｐ１、本人確度：ｐ２とした場合、認証中のオンラインユーザに対する属性の確度は、下記の式（１）で表される。ここでは、一例として、両方の確率を掛け算する。

元々の本人確度が低ければ、ＩＤと紐づけられた属性の信憑性がない。認証確度が弱ければ、そもそもユーザに紐づいたＩＤが適切ではない（なりすまし）の可能性がある。ＩＤ：ｉｄ、ユーザ：ｕ、属性：Ａ、認証確度：ｐ１、本人確度：ｐ２とした場合、評価関数は、下記の式（２）で表される。ここで「＊」は掛け合わせを意味し、どのような演算を定義してもよい。

図３に示すように、ユーザ：ｕとＩＤ：ｉｄとのリンクＬ１は、各認証試行の成功後に確立する（認証セッション）。認証セッションの有効時間をこえると、強度は０になる。このリンクＬ１の強度が、認証確度：ｐ１を示す。

属性：Ａは、認証サーバが管理する。属性：Ａは、属性集合（ａ_１, ａ_２, …ａ_n）としての強度を持つ。属性：Ａは、個々の属性ごとの強度を持っていてもよいが、本人確認文書（本人確認書類）の形態に依存する。

また、ＩＤ：ｉｄと属性：ＡとのリンクＬ２は本人確認時に確立する。強度は属性のタイプによって変化（減衰、あるいは、増加など）する。このリンクＬ２の強度が、本人確度：ｐ２を示す。

また、ＩＤ：ｉｄと認証情報：パスワードとのリンクＬ３も本人強度の１つと考えうるが、ＩＤを開設した人が（あるいは管理者が）設定するので、確度は１と考えて良い。

このように、サーバ装置１００は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると０になる。本人確度は、個人属性情報のタイプによって変化する。

〔１－１－１．アイデンティティ管理機能〕
（１）ユーザの属性の管理
認証サーバであるサーバ装置１００は、ユーザの属性を管理する。例えば、サーバ装置１００は、登録、更新、削除などのライフサイクル処理を実施する。

（２）属性のメタ情報の管理
また、サーバ装置１００は、ユーザの属性と紐づけて、属性のメタ情報を管理する。例えば、サーバ装置１００は、ユーザの属性を入手する際の本人確認方法、本人確認書類、本人確認書類のメタ情報（発行者など）、本人確認日時等を管理する。

（３）本人確度の管理
また、サーバ装置１００は、本人確度を管理する。例えば、サーバ装置１００は、上記属性とメタ情報を使って、所定の評価関数より算出し、継続的に管理する。また、サーバ装置１００は、アクセス制御などの必要時をトリガーとする、あるいは、定期的に更新する。このとき、サーバ装置１００は、減衰を考慮に入れた評価を実施する。また、サーバ装置１００は、セキュリティポリシーを使って確度情報の管理方法を記載し、制御してもよい。例えば、サーバ装置１００は、１日ごとに更新する。あるいは、サーバ装置１００は、人確認書類の有効期限が期限切れしていたらアラートを投げる、あるいは、認証時に本人確認の実施要求（お願い）をする。あるいは、サーバ装置１００は、１日ごとに本人確度を（本人確認書類発行日から）0.01ずつ減らす。

〔１－１－２．認証時に本人確認要求〕
図４を参照して、認証時に本人確認を要求する実施例について説明する。図４は、認証時に本人確認を要求する実施例の概要を示す説明図である。

図４に示すように、ユーザである利用者Ｕは、端末装置１０を用いて、ネットワークＮ（図１１参照）を介して、認証サーバであるサーバ装置１００との間でＩＤとパスワードによる認証を行う（ステップＳ１）。なお、当該認証は、事前に行われていてもよい。例えば、ユーザである利用者Ｕは、最初に認証を受けた後、サーバ装置１００へのログイン状態を維持し続けていてもよい。

続いて、ユーザである利用者Ｕは、端末装置１０を用いて、ネットワークＮ（図１１参照）を介して、認証サーバであるサーバ装置１００に対してサービス要求を送信する（ステップＳ２）。

続いて、認証サーバであるサーバ装置１００は、ユーザである利用者Ｕからのサービス要求に応じて、認証確度、本人確度、及び評価関数を算出する（ステップＳ３）。

続いて、認証サーバであるサーバ装置１００は、アイデンティティ管理機能を有し、セキュリティポリシーを参照し、制御判断を行い、セキュリティポリシー及び制御判断に基づき、ユーザである利用者Ｕの本人確認要求の実施を決定する（ステップＳ４）。例えば、サーバ装置１００は、本人確認文書：運転免許証（紙コピー）、有効期限: 2021年12月である場合、セキュリティポリシーに基づき、属性情報が有効期限切れなら本人確認を要求する。

続いて、認証サーバであるサーバ装置１００は、ネットワークＮ（図１１参照）を介して、認証器としての端末装置１０に対して、属性情報がセキュリティポリシーを満たしていないことを示すエラーや新たな本人確認処理の要求を含むサービス応答を送信する（ステップＳ５）。本実施形態では、認証器としての端末装置１０は、ユーザである利用者Ｕの端末装置１０である。このとき、認証サーバであるサーバ装置１００は、認証器としての端末装置１０に対して、チャレンジを送信する。

続いて、認証器としての端末装置１０は、認証サーバであるサーバ装置１００からのサービス応答に応じて、ユーザである利用者Ｕの身分証明書（運転免許証、マイナンバーカード等）に含まれる属性情報を取得する（ステップＳ６）。このとき、端末装置１０は、ユーザである利用者Ｕに対して身分証明書に含まれる属性情報の入力を要求し、属性情報の入力を受け付けてもよい。属性情報の入力方法は、手入力に限らず、データのアップロード、画像データスキャン及び画像解析、音声入力等であってもよい。あるいは、端末装置１０は、自身が内部に保有している属性情報を抽出してもよい。

続いて、認証器としての端末装置１０は、ネットワークＮ（図１１参照）を介して、認証サーバであるサーバ装置１００に対して、ＩＤと属性情報との組（セット）を含むサービス要求を送信する（ステップＳ７）。このとき、認証器としての端末装置１０は、認証用秘密鍵を用いてサーバ装置１００からのチャレンジに署名して送信する。

続いて、認証サーバであるサーバ装置１００は、認証器としての端末装置１０からのサービス要求に応じて、ユーザである利用者ＵのＩＤと属性情報に基づいて、ユーザである利用者Ｕの本人確認文書を確認し、変更点があればデータを更新し、セキュリティポリシーとの合致を検証する（ステップＳ８）。このとき、認証サーバであるサーバ装置１００は、認証器としての端末装置１０からの署名付きチャレンジに対して、認証用公開鍵を用いて署名を検証する。

続いて、認証サーバであるサーバ装置１００は、ネットワークＮ（図１１参照）を介して、認証器としての端末装置１０に対して、ＯＫを示すサービス応答を送信する（ステップＳ９）。

なお、本人確認の確度関数に、データの確度を時間の経過とともに減衰することを考慮にいれたものにしてもよい。

また、リスクベース認証の考え方を導入してもよい。例えば、利用環境が普段と異なる場合には、閾値を高く設定する（そのようなセキュリティポリシーにする）。

また、セキュリティポリシーを以下のものにしてもよい。
（１）評価関数が所定の閾値よりも低ければ、本人確認必要とする。
（２）ユーザの属性の自己申告の入力（初めての記載か更新）があれば、該当する本人確認書類を要求する。
（３）ユーザの属性の自己申告があれば、本人確認書類なしとして登録する。

このように、本実施形態では、サーバ装置１００は、ユーザ本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する。そして、サーバ装置１００は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。

このとき、サーバ装置１００は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

これにより、サーバ装置１００は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。また、サーバ装置１００は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。

また、サーバ装置１００は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。

また、サーバ装置１００は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

〔１－２．認証器管理〕
本実施形態では、認証器出生証明文書（アテステーション：Attestation）を管理し、認証の方法を変えることができる認証システムを実現する。

図５を参照して、通常（従来）のＦＩＤＯ認証において、認証器出生証明文書（アテステーション）を使って、認証サーバが認証器の信頼性を判断する仕組みについて説明する。図５は、アテステーションの仕組みの概要を示す説明図である。

図５に示すように、アテステーション用の鍵ペア（秘密鍵、公開鍵）を認証器ベンダーが出荷時に生成・配布する。本実施形態では、認証器ベンダー等が、アテステーション用秘密鍵を出荷時に認証器に格納する。認証サーバであるサーバ装置１００は、アテステーション用公開鍵を認証器ベンダー等から事前に入手する。

また、ユーザは、認証器の登録時に、アテステーション用の鍵ペアを使って、認証用の鍵ペアを配置する。本実施形態では、認証器としての端末装置１０は、認証器の登録時に認証用の鍵ペアを生成する。そして、認証器としての端末装置１０は、認証用秘密鍵を登録して格納する。また、認証器としての端末装置１０は、アテステーション用秘密鍵で署名したデータ（署名付きデータ）とともに／に含めて、認証用公開鍵を認証サーバであるサーバ装置１００に送付する。認証サーバであるサーバ装置１００は、認証器としての端末装置１０から受け取った署名付きデータに対してアテステーション用公開鍵で署名検証し、成功した場合、認証器としての端末装置１０から受け取った認証用公開鍵を登録して格納する。

しかし、通常のＦＩＤＯ認証において、ユーザが、アテステーションの仕組みを使ってＦＩＤＯ認証器を登録する場合、その後、認証サーバのセキュリティポリシーが変わっても、認証方法を変えることができない。その理由は、ユーザの認証確度の拠り所がアテステーション文書であるからである。

そこで、本実施形態では、認証サーバであるサーバ装置１００は、ＦＩＤＯ登録時に受け取ったユーザのアテステーション文書を保管し、管理する。

〔１－２－１．認証強度の管理〕
図６を参照して、認証強度の管理の概要について説明する。図６は、認証強度の管理の概要の概要を示す説明図である。

図６に示すように、ユーザ：ｕとＩＤ：ｉｄとのリンクＬ１は、各認証試行が成功後に確立する（認証セッション）。認証セッションの有効時間をこえると、強度は０になる。このリンクＬ１の強度が、認証確度：ｐ１を示す。

認証確度：ｐ１は、公開鍵信頼性強度に基づく。すなわち、信頼性の低いアテステーションで公開鍵を作成したら、毎回の認証試行における認証強度は低くなる。

なお、認証強度の管理では、ＩＤ：ｉｄと属性：ＡとのリンクＬ２は関係ない。すなわち、本人確度：ｐ２は考慮しない。ただし、実際には、認証確度：ｐ１と本人確度：ｐ２を組み合わせて認証強度の管理を行うオプションはあり得る。

また、ＩＤ：ｉｄと認証情報：公開鍵とのリンクＬ３’は、公開鍵信頼性強度を示す。
認証情報：公開鍵は、ＦＩＤＯ登録時に設定される。この信頼性を計る尺度として認証器出生証明文書（アテステーション文書）が使用される。

認証器出生証明文書（アテステーション文書）は、公開鍵を作成した認証器・デバイスの信頼性を証明する。この内容によって公開鍵信頼性強度が決まる。

本実施形態では、認証サーバであるサーバ装置１００は、ＦＩＤＯ登録機能と、ＦＩＤＯ認証機能とに加え、認証器出生証明管理機能と、認証強度管理機能とを有する。

〔１－２－２．ＦＩＤＯ登録の実施〕
図７を参照して、認証強度の管理におけるＦＩＤＯ登録の実施例について説明する。図７は、認証強度の管理におけるＦＩＤＯ登録の実施例の概要を示す説明図である。

図７に示すように、認証サーバであるサーバ装置１００は、認証器としての端末装置１０に対して、認証要求として、ランダム文字列であるチャレンジを送信する（ステップＳ１１）。

続いて、認証器としての端末装置１０は、認証サーバからの認証要求に応じて、ユーザである利用者Ｕに対して、生体認証など所定の認証手段でユーザ検証を行う（ステップＳ１２）。

続いて、認証器としての端末装置１０は、ユーザ検証に成功した場合、保有しているアテステーション用秘密鍵１で認証サーバからのチャレンジに署名するとともに、認証用鍵ペア（認証用秘密鍵１、認証用公開鍵１）を生成し、認証用秘密鍵１を保管する（ステップＳ１３）。

続いて、認証器としての端末装置１０は、認証サーバであるサーバ装置１００に対して、認証要求に対する認証応答として、署名付きチャレンジと、認証用公開鍵１と、アテステーション文書１とを送信する（ステップＳ１４）。

続いて、認証サーバであるサーバ装置１００は、認証器からの認証応答に応じて、保有しているアテステーション用公開鍵１で署名付きチャレンジの署名検証を行うとともに、認証用公開鍵１を保管する（ステップＳ１５）。

なお、実際には、認証サーバであるサーバ装置１００は、署名検証に成功した場合にのみ、認証用公開鍵１を保管するようにしてもよい。

続いて、認証サーバであるサーバ装置１００は、署名検証に成功した場合、ユーザである利用者Ｕを示すユーザＩＤを抽出する（ステップＳ１６）。

続いて、認証サーバであるサーバ装置１００は、抽出されたユーザＩＤと紐づけてアテステーション文書１を保管する（ステップＳ１７）。なお、アテステーション文書は、認証強度を評価するものの一例である。

〔１－２－３．アテステーションの再実施〕
認証サーバであるサーバ装置１００は、セキュリティ強化を決定した際に、既に保管しているユーザのアテステーション文書１では認証強度（レベル）を満たさない場合、設定した強度を満たすアテステーションを再実施する。

例えば、現在使用している認証器Ａの脆弱性が見つかったとする。そして、バグのある認証器Ａからの認証要求は許可しないセキュリティポリシーに更新したとする。この場合、ユーザから認証器Ａを使った認証要求を受けると、認証器Ａのファームウェア更新を促すと同時に、更新した認証器Ａでの再登録を促し、アテステーション文書を更新する。あるいは、新たな認証器Ｂでの再登録を促し、アテステーション文書を更新する。

図８を参照して、アテステーションの再実施の実施例について説明する。図８は、アテステーションの再実施の実施例の概要を示す説明図である。

図８に示すように、認証サーバであるサーバ装置１００は、事前に、ユーザの認証器出生証明文書（アテステーション文書）を参照し、強度不足を確認した場合、次回以降の認証の機会に再登録を促すように設定する（ステップＳ２０）。

そして、認証サーバであるサーバ装置１００は、認証の機会に、認証器としての端末装置１０に対して、認証要求として、ランダム文字列であるチャレンジを送信するとともに、ユーザの認証器出生証明文書の再登録を促す（ステップＳ２１）。

続いて、認証器としての端末装置１０は、認証サーバからの認証要求に応じて、ユーザである利用者Ｕに対して、生体認証など所定の認証手段でユーザ検証を行う（ステップＳ２２）。

続いて、認証器としての端末装置１０は、ユーザ検証に成功した場合、保有しているアテステーション用秘密鍵２で認証サーバからのチャレンジに署名する（ステップＳ２３）。

例えば、現在使用している認証器Ａのファームウェア更新（又は認証用アプリ更新）や、新たな認証器Ｂの使用開始により、認証器としての端末装置１０は、アテステーション用秘密鍵１とは異なるアテステーション用秘密鍵２を保管した状態となる。すなわち、認証器ベンダー等が、新たなアテステーション用の鍵ペア（秘密鍵、公開鍵）を生成・配布した状態となる。

このとき、認証器としての端末装置１０は、保有している認証用秘密鍵１を削除してもよい。これにより、上記のＦＩＤＯ登録の再実施（図８参照）が必要となる。すなわち、認証器としての端末装置１０は、今回のアテステーションの再実施の後、ＦＩＤＯ登録を再度実施し、新たな認証用鍵ペアの生成・配布を行う。また、認証器としての端末装置１０は、認証強度（レベル）を満たさないアテステーション用秘密鍵１が内部に残っている場合、アテステーション用秘密鍵１を削除してもよい。

続いて、認証器としての端末装置１０は、認証サーバであるサーバ装置１００に対して、認証要求に対する認証応答として、署名付きチャレンジと、アテステーション文書２とを送信する（ステップＳ２４）。

続いて、認証サーバであるサーバ装置１００は、認証器からの認証応答に応じて、保有しているアテステーション用公開鍵２で署名付きチャレンジの署名検証を行う（ステップＳ２５）。

なお、認証サーバであるサーバ装置１００は、認証器としての端末装置１０がアテステーション用秘密鍵２を保管した（又は取得可能となった）タイミングで、ペアとなるアテステーション用公開鍵２を取得し保管しているものとする。例えば、認証サーバであるサーバ装置１００は、アテステーション用公開鍵２を認証器ベンダー等から入手して保管する。

続いて、認証サーバであるサーバ装置１００は、署名検証に成功した場合、ユーザである利用者Ｕを示すユーザＩＤを抽出する（ステップＳ２６）。

続いて、認証サーバであるサーバ装置１００は、抽出されたユーザＩＤと紐づけてアテステーション文書２を保管し、認証器出生証明文書を更新する（ステップＳ２７）。

このとき、認証サーバであるサーバ装置１００は、ユーザＩＤと紐づけられていたアテステーション文書１を破棄（削除）してもよい。例えば、認証サーバであるサーバ装置１００は、ユーザＩＤと紐づけられていたアテステーション文書１を、アテステーション文書２で上書きしてもよい。

これにより、セキュリティポリシーを変わっても、本人確認強度（レベル）を、セキュリティポリシーを満たすように柔軟に変えることができる。また、ユーザの認証処理（手順）を変えることなく、セキュリティポリシーに合わせた本人確認強度にすることができる。

このように、本実施形態では、認証サーバであるサーバ装置１００は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でＦＩＤＯ認証を実施する。そのために、サーバ装置１００は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する。

例えば、サーバ装置１００は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。あるいは、サーバ装置１００は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。あるいは、サーバ装置１００は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。

また、サーバ装置１００は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。サーバ装置１００は、認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。このとき、サーバ装置１００は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。

例えば、サーバ装置１００は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。あるいは、サーバ装置１００は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。さらに、サーバ装置１００は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。

〔１－３．動的な秘密の質問作成〕
本人確認をする際の判断となる情報は事前に登録が必要で手間がかかる。また、登録がされてない限り、本人であると確認できない。

そこで、本実施形態では、本人確認をするための「秘密の質問」（ユーザ本人固有の質問）を動的に生成する。例えば、ユーザの行動ログをもとにして、ユーザの「秘密の質問」を動的に作成する。

図９を参照して、動的な秘密の質問作成の実施例について説明する。図９は、動的な秘密の質問作成の実施例の概要を示す説明図である。

図９に示すように、認証サーバであるサーバ装置１００は、事前に、ユーザである利用者Ｕのログを分析し、質問の雛形を生成する（ステップＳ３０）。

ユーザである利用者Ｕの端末装置１０は、認証サーバであるサーバ装置１００に対し、ユーザである利用者Ｕを示すユーザＩＤを含むアクセス要求を行う（ステップＳ３１）。

続いて、認証サーバであるサーバ装置１００は、ユーザである利用者Ｕの端末装置１０からのアクセス要求に応じて、ユーザである利用者Ｕに対する質問・回答を生成するとともに、認証画面（質問を含む）を生成する（ステップＳ３２）。

続いて、認証サーバであるサーバ装置１００は、認証器としての端末装置１０に対して、認証要求として、質問を含む認証画面を提供（表示）する（ステップＳ３３）。

続いて、ユーザである利用者Ｕは、認証器としての端末装置１０に表示された認証画面に対して、認証画面に含まれる質問への回答を入力する（ステップＳ３４）。

続いて、認証器としての端末装置１０は、認証サーバであるサーバ装置１００からの認証要求に対する認証応答として、ユーザである利用者Ｕにより入力された回答を送信する（ステップＳ３５）。

続いて、認証サーバであるサーバ装置１００は、認証器としての端末装置１０からの回答を検証し、認証結果に関する結果画面を生成する（ステップＳ３６）。

例えば、認証サーバであるサーバ装置１００は、質問とともに作成した回答と、認証器としての端末装置１０からの回答とを照合し、合致している場合に、成功と判断する。なお、完全一致に限らず、部分一致も可としてもよい。

続いて、認証サーバであるサーバ装置１００は、認証器としての端末装置１０に対して、アクセス応答として、認証結果に関する結果画面や、要求画面を送信する（ステップＳ３７）。

〔１－３－１．ログ分析〕
本実施形態では、認証サーバであるサーバ装置１００は、ユーザである利用者Ｕの行動ログの形式を特定する。

例えば、サーバ装置１００は、利用者Ｕの商品購入やサービス利用の履歴である購入履歴を特定する。また、サーバ装置１００は、ＳＮＳへの利用者Ｕの投稿の履歴である投稿履歴を特定する。また、サーバ装置１００は、端末装置１０の決済アプリを用いた電子決済の履歴である決済履歴を特定する。

そして、認証サーバであるサーバ装置１００は、形式が特定された行動ログの中から、質問項目の特定・抽出を行う。

例えば、サーバ装置１００は、利用者Ｕの購入履歴から、日時、商品、価格、商品モデル/ブランド、商品の種類、購買店、複数の購買履歴からの頻度、パターン、よく買う店舗、周期等を、質問項目として特定・抽出する。

また、サーバ装置１００は、利用者ＵのＳＮＳの投稿履歴から、日時、交信相手、投稿先、会話の内容等、複数の投稿からの頻度、パターン、よく会話する相手等を、質問項目として特定・抽出する。

また、サーバ装置１００は、利用者Ｕの決済履歴から、日時、店舗、金額、複数の取引からの頻度、パターン、よく行く店舗等を、質問項目として特定・抽出する。

あるいは、認証サーバであるサーバ装置１００は、所定のログ形式の検索ではなく、機械学習など統計的な分析手法によりデータ質問項目を特定してもよい。

また、認証サーバであるサーバ装置１００は、上記事前に選ばれた質問項目に、統計的な分析手法により特定した質問項目を追加して、次回以降に利用してもよい。

〔１－３－２．質問作成〕
（１）質問対象ログの抽出
認証サーバであるサーバ装置１００は、ユーザである利用者Ｕの行動ログのデータセットから、質問の対象となる１つのイベントを取り出す。例えば、サーバ装置１００は、利用者Ｕの購入履歴から、「2022年1月14日午後3時15分、YショッピングのAAAストアから、商品BBBを1つ（価格5000円）を購入した。」というイベントを取り出す。

（２）質問テンプレートの作成
認証サーバであるサーバ装置１００は、質問対象ログから質問項目（１つ以上）を決めた質問テンプレートを作成する。例えば、サーバ装置１００は、購入日時（時刻）を質問項目として決定した場合、「時刻xxxx、YショッピングのAAAストアから、パソコンBBBを1つ（価格5000円）を購入した。」という質問テンプレートを作成する。

（３）質問項目生成ポリシーの決定
認証サーバであるサーバ装置１００は、質問項目を生成する上でのポリシー（質問項目生成ポリシー）を決定する。例えば、サーバ装置１００は、質問項目生成ポリシーとして、フリーテキスト、あるいは、曖昧化した時間帯にした選択式にする等のポリシーを決定する。

（４）質問と正解の生成
認証サーバであるサーバ装置１００は、質問項目生成ポリシーに従って、質問と、その回答（正解）とを生成する。例えば、サーバ装置１００は、「何時ごろ、Yショッピングで電化製品を書いましたか？」という質問と、回答の選択肢として「（a）１～4時、（b）4～7時、（c）7～10時」、正解として「（a）１～4時」を生成する。

（５）その他
なお、認証サーバであるサーバ装置１００は、質問にダミーのもの（ダミー質問）を入れてもよい。例えば、サーバ装置１００は、ユーザである利用者Ｕの行動ログに基づいておらず、利用者Ｕが回答できない質問（無回答が正解）を生成してもよい。この場合、全ての質問の回答の選択肢に、「正解なし」や「スキップ」を設定してもよい。また、フリーテキストでの回答入力の場合、未入力（空欄）の回答を受け付けるようにしてもよい。ダミーの作成にも様々な方法が考えられる。

また、認証サーバであるサーバ装置１００は、サービスごとではなく、複数のサービスをまたぐログを活用して質問を作成するようにしてもよい。これにより、単体の質問で攻撃されないようにセキュリティを強化できる。

また、認証サーバであるサーバ装置１００は、プライバシー対策として、匿名性（Ｋ－匿名性などの評価尺度）を加味した質問を生成してもよい。例えば、位置情報を曖昧化してもよい。

また、認証サーバであるサーバ装置１００は、質問項目を１つに限らず、２つ以上にすると好ましい。すなわち、質問項目が限定的でなければよい。

このように、本実施形態では、サーバ装置１００は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する。そして、サーバ装置１００は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する。

例えば、サーバ装置１００は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。あるいは、サーバ装置１００は、機械学習を用いた統計的な分析手法により質問項目を特定する。

また、サーバ装置１００は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから１以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。

このとき、サーバ装置１００は、秘密の質問とともに、ダミーの質問を生成し、秘密の質問とともに、ダミーの質問をユーザに提示するようにしてもよい。また、サーバ装置１００は、正解とともに、ダミーの回答を生成し、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させるようにしてもよい。

なお、サーバ装置１００は、ユーザの複数の行動ログに基づいて１つの質問を生成するようにしてもよい。

また、サーバ装置１００は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させるようにしてもよい。

例えば、サーバ装置１００は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。このとき、サーバ装置１００は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。

あるいは、サーバ装置１００は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。あるいは、サーバ装置１００は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。

このとき、サーバ装置１００は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメール（注文内容確認メール、商品発送の連絡メール等）のデータを入力させるようにしてもよい。例えば、サーバ装置１００は、ユーザが行った複数の購買行動に関連する各メールの内容（文面）の組合せと、あらかじめ登録された正解データとを照合することで、本人確認することが可能になる。称号は、データ自体であってもよいし、ハッシュ値であってもよい。さらに、複数の購買行動に関連する各メールの内容（文面）と、それぞれの購入日時（又はメール受信日時）とを組み合わせてもよい。

〔１－４．本人確認判定〕
認証サーバであるサーバ装置１００は、本人確認（Identity proofing）において、ユーザが本人かどうかを確認する場合、本人があらかじめ登録した属性情報と、入力された属性情報が一致することの確認することによって、ユーザ本人とみなす。なお、（当人）認証に失敗してアカウントにアクセスできなくなった時には、アカウントリカバリーを行う。

現状のアカウントリカバリーでは、リカバリー画面において本人確認を受ける際に、本人の属性情報を始め、いくつかの質問項目を回答する形式となっている場合がある。質問項目には、住所など一般的な質問がある一方で、決済アプリ連携やメンバーカード（自社発行のクレジットカード）の保有に関する質問など特別な質問もある。また、「秘密の質問」などの本人確認方法を採用していることもある。

しかし、従来の「秘密の質問」などの本人確認方法は、質問が固定的であるため、質問に対する正解を予想したり調べたりするなどして攻撃対象となる可能性がある。

そこで、本実施形態では、非固定的でプライバシー保護を考慮にいれた「秘密の質問」を動的に作成し、安全に本人確認を実現する。例えば、「秘密の質問」の入力を促す画面を動的に作成する。

本実施形態では、認証サーバであるサーバ装置１００は、認証機能と、本人確認判定機能と、本人確認画面生成機能とを有する。サーバ装置１００は、確認属性を一通り表示するが、毎回違うものが出たり、ダミー質問を入れたりする。

〔１－４－１．本人確認判定ロジック〕
本実施形態では、認証サーバであるサーバ装置１００は、本人確認判定ロジックとして、下記の式（３）、式（４）を用いる。

ここで、重みＷについて、Ｗ＝｛ｗ_１，ｗ_２，…，ｗ_ｎ｝とし、ｗ_１＋ｗ_２＋…＋ｗ_ｎ＝１とする。また、ｆ＿Ａ_ｎ（ｘ）は、属性Ａ_ｎの判定関数であり、ｘの確度を返す。判定関数ｆ（Ａ）の値が、所定の閾値よりも大きければ本人とみなす。なお、ａ_１，ａ_２，…が空であってもよい。また、ａ_１とａ_２が独立ではなければｆ（ａ_１，ａ_２）としてよい。また、ダミーの質問に含まれるＡ_ｎに該当する重みはｗ_ｎ＝０とする。

本人確認のための属性入力画面が変わっても、対応する上記の判定関数を調整するだけで本人確認判定が可能、柔軟に対応できる。

〔１－４－２．画面作成ロジック〕
本実施形態では、認証サーバであるサーバ装置１００は、Ｃ：「動的な秘密の質問作成」のログ生成ロジックを使って、所定のログ形式（ショッピング、オークション等）から複数の質問テンプレートを作成する。例えば、サーバ装置１００は、「Yショッピングで、何時ごろ、電化製品を書いましたか？」等の質問テンプレートを作成する。

これにより、統一的な共通画面で、多様な属性情報を質問項目に入れ、本人確認を実現できる。また、共通の画面なので、人によって異なる属性情報が現れることにより、登録属性を推測されるなどのプライバシー漏洩を防止できる。

なお、認証サーバであるサーバ装置１００は、必ず含める静的な質問に加えて実施する付加的な質問については、積極的に質問する属性情報を変化させる。この場合も、判定関数を調整すればよい。ただし、本人確認試行（セッション）ごとに判定関数を登録する。例えば、ＩＤ、時間帯、コンテキストによって変える。あるいは、ランダムにする。また、ダミー質問を適度に入れる。

また、認証サーバであるサーバ装置１００は、画面をステップにしてもよい（multi-step proofing）。例えば、ある質問に答えられて、初めて次の所定の質問が見れるようにする。

〔１－４－３．秘密の質問の回答としての行動ログ自体の利用〕
本実施形態では、認証サーバであるサーバ装置１００は、事前に秘密の「行動履歴（文書）」を登録し、本人確認の質問に使用する。このとき、サーバ装置１００は、ＩＤと紐づけて種類と行動履歴（文書）を登録する。

（１）登録時
サーバ装置１００は、本人確認の質問に使う行動履歴（文書）を分類して種類を特定し、登録する。例えば、サーバ装置１００は、行動履歴（文書）の種類を「Yショッピングでのかばんの購買」と分類して登録する。

また、サーバ装置１００は、行動履歴（文書）として、例えば「Yショッピングでの購買結果（メール）」を登録する。これ自体（購買結果のメール内容）をユーザにフリーテキストで作らせてもよい。

（２）本人確認時
サーバ装置１００は、本人確認時に、ＩＤに紐づけられた種類とダミー種類とを入れた選択肢を作成し、リストで表示し、ユーザに選択させる。例えば、サーバ装置１００は、ユーザに上記選択した「種類」に対応した「行動履歴（文書）」の入力を求める。

なお、種類だけではなく、行動履歴（文書）についても、サーバ装置１００は、本人確認時に、ＩＤに紐づけられた行動履歴（文書）とダミー行動履歴（文書）とを入れた選択肢を作成し、リストで表示し、ユーザに選択させるようにしてもよい。

そして、サーバ装置１００は、行動履歴（文書）のハッシュ値を照合するなどして、行動履歴（文書）の真正性を確認する。例えば、サーバ装置１００は、ユーザに入力（又は選択）された複数の行動履歴（文書）の内容から１つのハッシュ値を求め、あらかじめ登録されたハッシュ値（正解データ）と照合して、これらの行動履歴（文書）の真正性を確認するとともに、ユーザの本人性を確認する。

また、サーバ装置１００は、アカウントリカバリー等で本人確認をする際に、事業者が提供するＰＩＭ（Product Information Management（商品情報管理））系、メディア系、生活ツール系、金融系なども対象に質問を生成してもよい。特に、コマース、決済のユーザがＡＲＰＵ（Average Revenue Per User）が高いユーザであるため、アカウントリカバリーをさせる優先度が高い。

また、サーバ装置１００は、ニュースのコメントやＱＡサービスを利用するユーザの優先度を高めてもよい。

また、メッセージアプリなども含め一般的なＳＮＳのユーザは、日常生活の行動や写真などパーソナルデータを預けているので、リカバリーの優先度がやはり高い。また、メールサービス等、通信の秘密という個人情報も絡む部分でライフラインになっている各種サービスのユーザについてもリカバリーの必要性は高い。サーバ装置１００は、これらのユーザの優先度を高めてもよい。

例えば、メールやカレンダーなどのＰＩＭサービスにおいては、メールアドレスを登録して送受信している他社サービス名や、よく受信する旅行やコマースなどのカテゴリ名、そのサービスの予約や購買など、メールチームが件名や文面の解析結果を本願実施形態で説明した技術に適用することができる。

また、ユーザがフォローしているニュースのテーマやよく閲覧するコンテンツのカテゴリ等の解析結果を、本願実施形態で説明した技術に適用することができる。また、これら以外にも、天気、自宅の位置情報、最寄り駅、経路・乗車履歴、ナビゲーションサービスの目的地等、各種サービスの履歴の解析結果を、本願実施形態で説明した技術に適用することができる。また、証券口座情報や取り扱っている株式や投資信託、銀行口座やカード請求関連情報なども質問に活用できる。

〔１－５．アカウントリカバリーの権限委譲〕
本実施形態では、認証サーバであるサーバ装置１００は、ユーザから、そのユーザの行動に対して責任ある立場の者へアカウントリカバリーの権限委譲（権限委任）を許容してもよい。例えば、子供（認証対象者、権限委譲者）の端末装置のアカウントリカバリーを実施する際に、アカウントリカバリーの権限をその子供の親（被権限委譲者）に委譲することを許可してもよい。

図１０を参照して、子供から親へのアカウントリカバリーの権限委譲の実施例について説明する。図１０は、子供から親へのアカウントリカバリーの権限委譲の実施例の概要を示す説明図である。

図１０に示すように、子供である利用者Ｕ（Ｕ１）は、認証サーバであるサーバ装置１００に対して、リカバリー協力者として、親である他の利用者Ｕ（Ｕ２）のアカウントを登録する（ステップＳ４０）。

例えば、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）は、認証サーバであるサーバ装置１００に対して、リカバリー協力者として、子供である利用者Ｕ（Ｕ１）を示す子ＩＤとともに、親である他の利用者Ｕ（Ｕ２）を示す親ＩＤを送信する。認証サーバであるサーバ装置１００は、子供を示す子ＩＤと、親を示す親ＩＤとを紐づけて登録する。これにより、認証サーバであるサーバ装置１００は、親である他の利用者Ｕ（Ｕ２）のＦＩＤＯ認証が可能となる。

このとき、認証サーバであるサーバ装置１００は、子供である利用者Ｕ（Ｕ１）が親である他の利用者Ｕ（Ｕ２）から許可を受けたことを証明できた場合にのみ、リカバリー協力者として、親である他の利用者Ｕ（Ｕ２）のアカウントを登録できるようにしてもよい。例えば、サーバ装置１００は、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）と通信し、親である他の利用者Ｕ（Ｕ２）の同意を求めてもよい。あるいは、子供である利用者Ｕ（Ｕ１）が端末装置１０同士の近距離無線通信で、親である他の利用者Ｕ（Ｕ２）から許可を受けてから登録を要求するようにしてもよい。

また、認証サーバであるサーバ装置１００は、親である他の利用者Ｕ（Ｕ２）が既知のユーザ（登録済みのユーザ）である場合には、子供を示す子ＩＤと、親を示す親ＩＤとを紐づけて登録するだけでよいが、親である他の利用者Ｕ（Ｕ２）が未知のユーザ（未登録のユーザ）である場合には、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）に対して、登録（ユーザ登録、認証器の登録）を要求してもよい。

続いて、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）は、アカウントリカバリーが必要になった場合、認証サーバであるサーバ装置１００に対して、リカバリー要求（子ＩＤ、親ＩＤ）を送信する（ステップＳ４１）。

例えば、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）は、アカウントリカバリーが必要になった場合、子供である利用者Ｕ（Ｕ１）の操作に応じて、あるいは自動的に、認証サーバであるサーバ装置１００に対して、リカバリー要求（子ＩＤ、親ＩＤ）を送信する。親ＩＤは、アカウントリカバリーの権限の委譲先を示す。なお、認証サーバであるサーバ装置１００側で、子ＩＤと親ＩＤとが１対１で対応付けられて保管されている場合、リカバリー要求として、子ＩＤのみ送信するようにしてもよい。

続いて、認証サーバであるサーバ装置１００は、子供である利用者Ｕ（Ｕ１）の端末装置１０からのリカバリー要求に応じて、チャレンジを生成する（ステップＳ４２）。

続いて、認証サーバであるサーバ装置１００は、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）に対して、チャレンジと親ＩＤとを含むリカバリー許可要求を送信する（ステップＳ４３）。

続いて、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）は、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）に対して、サーバ装置１００からのリカバリー許可要求を送信（転送）する（ステップＳ４４）。

本実施形態では、親は子供の近くにいるものとする。例えば、子供である利用者Ｕ（Ｕ１）がＢＬＥ（Bluetooth（登録商標） Low Energy）など端末装置１０同士の近距離無線通信で、親である他の利用者Ｕ（Ｕ２）に対して、サーバ装置１００からのリカバリー許可要求を送信してもよい。

続いて、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）は、ＦＩＤＯ認証（認証器を用いてユーザ検証）を行い、サーバ装置１００からのリカバリー許可要求に対する承認として、秘密鍵を用いてチャレンジに署名する（ステップＳ４５）。

続いて、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）は、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）に対して、リカバリー許可要求に対する応答として、署名付きチャレンジを含むリカバリー許可応答を送信する（ステップＳ４６）。

続いて、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）は、認証サーバであるサーバ装置１００に対して、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）からのリカバリー許可応答（署名付きチャレンジ）を送信（転送）する（ステップＳ４７）。

続いて、認証サーバであるサーバ装置１００は、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）からのリカバリー許可応答（署名付きチャレンジ）に応じて、公開鍵を用いて署名を検証し、リカバリー協力者を確認する（ステップＳ４８）。

続いて、認証サーバであるサーバ装置１００は、署名の検証に成功し、親である他の利用者Ｕ（Ｕ２）がリカバリー協力者であることを確認できた場合、リカバリー制御を行う（ステップＳ４９）。

続いて、認証サーバであるサーバ装置１００は、リカバリー要求をした子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）に対して、リカバリー制御に基づくリカバリー応答を送信する（ステップＳ５０）。これにより、サーバ装置１００は、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）のアカウントリカバリーを実施する。

なお、子供から親へのアカウントリカバリーの権限委譲は一例に過ぎない。実際には、企業等の従業員からその上司又はシステム管理者等へのアカウントリカバリーの権限委譲であってもよい。また、利用者Ｕに対して端末装置１０を貸与している者へのアカウントリカバリーの権限委譲であってもよい。すなわち、認証対象者である権限委譲者から被権限委譲者へのアカウントリカバリーの権限委譲であればよい。

また、子供である利用者Ｕ（Ｕ１）の端末装置１０（１０Ａ）をＦＩＤＯクライアントとし、親である他の利用者Ｕ（Ｕ２）の端末装置１０（１０Ｂ）を認証器としてもよい。すなわち、ＦＩＤＯクライアントを使用するユーザと、認証器によりユーザ検証されるユーザとは別人であってもよい。

このように、本実施形態では、サーバ装置１００は、認証対象者と、認証対象者が指定した被権限委譲者との情報を管理する。そして、サーバ装置１００は、認証対象者からのアカウントリカバリーの要求に対して、被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する。このとき、サーバ装置１００は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。

例えば、サーバ装置１００は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信する。なお、認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。その結果、サーバ装置１００は、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信する。そして、サーバ装置１００は、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。

このとき、サーバ装置１００は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。そして、サーバ装置１００は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。

例えば、サーバ装置１００は、認証対象者である子供と、被権限委譲者である親との情報を管理する。そして、サーバ装置１００は、子供からのアカウントリカバリーの要求に対して、親の承認で子供のアカウントリカバリーを実施する。このとき、サーバ装置１００は、親に対してＦＩＤＯ認証を実施する。

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

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

端末装置１０は、利用者Ｕによって使用される情報処理装置である。例えば、端末装置１０は、スマートフォンやタブレット端末等のスマートデバイス、フィーチャーフォン、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、通信機能を備えたゲーム機やＡＶ機器、カーナビゲーションシステム、スマートウォッチやヘッドマウントディスプレイ等のウェアラブルデバイス（Wearable Device）、スマートグラス等である。

また、かかる端末装置１０は、ＬＴＥ（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）等の技術を用いて端末装置１０の位置を測位することが可能になる。これにより、ＧＰＳ等の測位システムでは取得することが困難な屋内での位置情報を取得することが可能になる。

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

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

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

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

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

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

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

（記憶部４０）
記憶部４０は、例えば、ＲＡＭ（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）等によって、サーバ装置１００の内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等の記憶領域を作業領域として実行されることにより実現される。図１３に示す例では、制御部１３０は、取得部１３１と、生成部１３２と、認証処理部１３３と、管理部１３４と、提供部１３５とを有する。

（取得部１３１）
取得部１３１は、通信部１１０を介して、ユーザである利用者Ｕの端末装置１０から、利用者Ｕにより入力されたデータを取得する。例えば、取得部１３１は、利用者Ｕの端末装置１０から、利用者Ｕによる各種の登録情報を取得する。

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

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

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

（生成部１３２）
生成部１３２は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する。例えば、生成部１３２は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。あるいは、生成部１３２は、機械学習を用いた統計的な分析手法により質問項目を特定する。

また、生成部１３２は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから１以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。

このとき、生成部１３２は、秘密の質問とともに、ダミーの質問を生成してもよい。また、生成部１３２は、正解とともに、ダミーの回答を生成してもよい。また、生成部１３２は、ユーザの複数の行動ログに基づいて１つの質問を生成してもよい。

（認証処理部１３３）
認証処理部１３３は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する。このとき、認証処理部１３３は、秘密の質問とともに、ダミーの質問をユーザに提示してもよい。また、認証処理部１３３は、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させる。

なお、認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させてもよい。このとき、認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメールのデータを入力させてもよい。

例えば、認証処理部１３３は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。このとき、認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。

あるいは、認証処理部１３３は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。あるいは、認証処理部１３３は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。

また、認証処理部１３３は、ユーザ（利用者Ｕ）本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する。

また、認証処理部１３３は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でＦＩＤＯ認証を実施する。例えば、認証処理部１３３は、信頼できる認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。

また、認証処理部１３３は、認証対象者（権限委譲者）からのアカウントリカバリーの要求に対して、認証対象者が指定した被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する。

例えば、認証処理部１３３は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信する。なお、認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。

そして、認証処理部１３３は、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信する。このとき、認証処理部１３３は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。

そして、認証処理部１３３は、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。このとき、認証処理部１３３は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。

例えば、認証処理部１３３は、認証対象者である子供からのアカウントリカバリーの要求に対して、被権限委譲者である親の承認で子供のアカウントリカバリーを実施する。このとき、認証処理部１３３は、親に対してＦＩＤＯ認証を実施する。

（管理部１３４）
管理部１３４は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。また、管理部１３４は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

例えば、管理部１３４は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。あるいは、管理部１３４は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。

また、管理部１３４は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。

また、管理部１３４は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

また、管理部１３４は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると０になる。本人確度は、個人属性情報のタイプによって変化する。

また、管理部１３４は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する。また、管理部１３４は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。

例えば、管理部１３４は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。あるいは、管理部１３４は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。

また、管理部１３４は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。また、管理部１３４は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。

例えば、管理部１３４は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。また、管理部１３４は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。また、管理部１３４は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。

また、管理部１３４は、他人へのアカウントリカバリーの権限委譲（例えば、子供から親へのアカウントリカバリーの権限委譲）に関して、認証対象者（権限委譲者）と、認証対象者が指定した被権限委譲者との情報を管理する。例えば、管理部１３４は、認証対象者である子供と、被権限委譲者である親との情報を管理する。このとき、管理部１３４は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。

（提供部１３５）
提供部１３５は、通信部１１０を介して、ＦＩＤＯ認証に成功したユーザにアイデンティティサービスを提供する。すなわち、提供部１３５は、ユーザである利用者Ｕの端末装置１０に対して、ユーザである利用者Ｕへのアイデンティティサービスを提供する。

また、提供部１３５は、通信部１１０を介して、ユーザである利用者Ｕの端末装置１０に対して、画面情報（入力画面等）を提供してもよい。このとき、利用者Ｕの端末装置１０は、提供された画面情報に基づいて、入力画面等を表示する。

また、提供部１３５は、通信部１１０を介して、ユーザである利用者Ｕの端末装置１０に対して、ＦＩＤＯ認証の成否に関する情報を提供してもよい。また、提供部１３５は、通信部１１０を介して、ユーザである利用者Ｕの端末装置１０に対して、ＦＩＤＯ認証に関連した各種情報を提供してもよい。

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

図１７に示すように、サーバ装置１００の認証処理部１３３は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でＦＩＤＯ認証を実施する（ステップＳ１０１）。

続いて、サーバ装置１００の管理部１３４は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する（ステップＳ１０２）。

続いて、サーバ装置１００の管理部１３４は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する（ステップＳ１０３）。

続いて、サーバ装置１００の管理部１３４は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する（ステップＳ１０４）。

続いて、サーバ装置１００の管理部１３４は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する（ステップＳ１０５）。

続いて、サーバ装置１００の生成部１３２は、認証に失敗してアカウントにアクセスできなくなった時には、ユーザのアカウントリカバリーを実施する前に、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する（ステップＳ１０６）。

続いて、サーバ装置１００の認証処理部１３３は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する（ステップＳ１０７）。例えば、認証処理部１３３は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。

続いて、サーバ装置１００の管理部１３４は、他人へのアカウントリカバリーの権限委譲（例えば、子供から親へのアカウントリカバリーの権限委譲）に関して、認証対象者（権限委譲者）と、認証対象者が指定した被権限委譲者との情報を管理する（ステップＳ１０８）。

続いて、サーバ装置１００の認証処理部１３３は、認証対象者（権限委譲者）からのアカウントリカバリーの要求に対して、認証対象者が指定した被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する（ステップＳ１０９）。

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

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

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

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

また、上記の実施形態において、サーバ装置１００は、ユーザの行動に関連してユーザが入手した文書のデータを入力させ、入力された文書のデータを自然言語処理（文章解析）してベクトル化した値と、正解としてあらかじめ保管している値とを照合し、本人確認してもよい。すなわち、サーバ装置１００は、ハッシュ値に限らず、文書のベクトル値を照合して本人確認してもよい。

また、上記の実施形態において、サーバ装置１００は、動的に秘密の質問を作成する際に、検索履歴を用いてもよい。例えば、サーバ装置１００は、ユーザが入力（又は選択）した複数の検索クエリの組合せのハッシュ値と、あらかじめ登録された正解データとを照合して、本人確認してもよい。なお、ハッシュ値に限らず、検索クエリの組合せを自然言語処理（文章解析）してベクトル化した値であってもよい。

また、上記の実施形態において、サーバ装置１００は、アテステーション用公開鍵や認証用公開鍵、及び認証器出生証明文書（アテステーション文書）をブロックチェーン（ＢＣ）で管理してもよい。例えば、ＦＩＤＯ公開鍵を分散台帳装置が管理する。分散台帳装置は、ネットワークを構成する各ノードが同じ台帳を管理／共有することができる分散型台帳技術（ＤＬＴ：Distributed Ledger Technology）に対応したサーバ装置である。分散台帳装置は、このネットワークを構成するノードの１つであってもよい。ブロックチェーンのブロックにハッシュが入るので、公開鍵が改ざんされていないかを認証できる。また、公開鍵の適切性を検証してから、認証を行うことができる。

〔７．効果〕
上述してきたように、本願に係る情報処理装置（端末装置１０及びサーバ装置１００）は、ユーザ本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する認証処理部１３３と、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する管理部１３４と、を備える。

管理部１３４は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

管理部１３４は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。

管理部１３４は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。

管理部１３４は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。

管理部１３４は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。

管理部１３４は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると０になる。本人確度は、個人属性情報のタイプによって変化する。

また、他の観点では、本願に係る情報処理装置（端末装置１０及びサーバ装置１００）は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でＦＩＤＯ認証を実施する認証処理部１３３と、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する管理部１３４と、を備える。

管理部１３４は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。

管理部１３４は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。

管理部１３４は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。

管理部１３４は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。

認証処理部１３３は、認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。管理部１３４は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。

例えば、管理部１３４は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。

また、管理部１３４は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。

また、管理部１３４は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。

また、他の観点では、本願に係る情報処理装置（端末装置１０及びサーバ装置１００）は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する生成部１３２と、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する認証処理部１３３と、を備える。

例えば、生成部１３２は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。

あるいは、生成部１３２は、機械学習を用いた統計的な分析手法により質問項目を特定する。

生成部１３２は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから１以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。

生成部１３２は、秘密の質問とともに、ダミーの質問を生成する。認証処理部１３３は、秘密の質問とともに、ダミーの質問をユーザに提示する。

生成部１３２は、正解とともに、ダミーの回答を生成する。認証処理部１３３は、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させる。

生成部１３２は、ユーザの複数の行動ログに基づいて１つの質問を生成する。

認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させる。

認証処理部１３３は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。

認証処理部１３３は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。

認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。

認証処理部１３３は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。

認証処理部１３３は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメールのデータを入力させる。

また、他の観点では、本願に係る情報処理装置（端末装置１０及びサーバ装置１００）は、認証対象者と、認証対象者が指定した被権限委譲者との情報を管理する管理部１３４と、認証対象者からのアカウントリカバリーの要求に対して、被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する認証処理部１３３と、を備える。

管理部１３４は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。

認証処理部１３３は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信し、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信し、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。

認証処理部１３３は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。

認証処理部１３３は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。

認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。

管理部１３４は、認証対象者である子供と、被権限委譲者である親との情報を管理する。認証処理部１３３は、子供からのアカウントリカバリーの要求に対して、親の承認で子供のアカウントリカバリーを実施する。このとき、認証処理部１３３は、親に対してＦＩＤＯ認証を実施する。

上述した各処理のいずれかもしくは組合せにより、本願に係る情報処理装置は、ユーザ以外によるアカウントリカバリー時における本人確認判定の手法をさらに向上させることができる。

〔８．ハードウェア構成〕
また、上述した実施形態に係る端末装置１０やサーバ装置１００は、例えば図１８に示すような構成のコンピュータ１０００によって実現される。以下、サーバ装置１００を例に挙げて説明する。図１８は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力Ｉ／Ｆ（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