JP2019140423A - 端末登録システムおよび端末登録方法 - Google Patents

Abstract

【課題】複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供する。【解決手段】登録済み端末１は、秘密鍵とサービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報１１０をAuthenticator１０が備える。Registration Manager１００は、登録済み端末１のAuthenticator１０からサービスサイト一覧情報１１０を取得する。そして、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。【選択図】図２

Description

本発明は、端末登録システムおよび端末登録方法に関する。

パスワード認証に替わる利用者認証技術として、パスワードレス認証のデファクト標準技術（ＦＩＤＯ：Fast IDentity Online）という、公開鍵暗号を用いたＷｅｂサービスの利用者認証技術がある（非特許文献１参照）。
ＦＩＤＯでは、サービス毎に異なる公開鍵・秘密鍵ペアを生成し、公開鍵をサービスサイト側に配置して、秘密鍵を端末内に閉じ込める。秘密鍵の利用（チャレンジ・レスポンス認証における署名）は端末上で生体認証を行うことが前提となっており、かつ、秘密鍵の利用はAuthenticator内で行われ、端末外に秘密鍵が出ていくことはないことからセキュリティが高い。
ＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。標準技術においてRegistrationは、ＦＩＤＯ以外の認証方法でアカウントにログインした上で実行することが想定されている。
サービス事業者にとって複数の認証手段を用意するのは運用負担が大きく、セキュリティホールにもなり得る。そのため、アカウント作成のタイミング等に端末のRegistrationを行った後には、ＦＩＤＯのみを唯一の認証とすることが考えられる。このような環境で、アカウントに異なる別の端末を紐付けるユースケースを考える。

図９は、標準技術（ＦＩＤＯ）の特徴を説明する図である。
図９に示すように、端末１および端末２は、生体認証等でアクセス制御される。端末１および端末２と、サービスサイトＡ２１およびサービスサイトＢ２２とは、ＦＩＤＯプロトコルで認証される。利用者は端末１を使ってサービスサイトＡ２１とサービスサイトＢ２２にアクセスし、端末２を使ってサービスサイトＡ２１とサービスサイトＢ２２にアクセスしている。
サービスサイトＡ２１およびサービスサイトＢ２２は、端末毎に個別の鍵を登録する。また、端末１および端末２は、サイト毎に個別の鍵ペアを生成する。
サービスサイトＡ２１には公開鍵１−Ａと２−Ａが、サービスサイトＢ２２には公開鍵１−Ｂと２−Ｂとが登録済みである。
端末１のAuthenticator１０（セキュア領域）には、公開鍵１−Ａとペアになる秘密鍵１−Ａと、公開鍵１−Ｂとペアになる秘密鍵１−Ｂとが格納されている。
端末２のAuthenticator１０（セキュア領域）には、公開鍵２−Ａとペアになる秘密鍵２−Ａと、公開鍵２−Ｂとペアになる秘密鍵２−Ｂとが格納されている。

図１０は、標準技術（ＦＩＤＯ）において、新規端末の登録を説明する図である。図１０における端末２は、端末１とは別に新しく追加される端末（以下、新規端末２という）である。新規端末２は、端末の追加、変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）によって生じる。新規端末２でＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。
図１０に示すように、新規端末２を利用する場合、新規端末２のAuthenticator１０内には鍵がないことから、サービス毎に再度鍵ペアの生成・登録を行う必要がある。

端末外部のAuthenticatorを利用してＦＩＤＯ認証を行うためのプロトコルとしてＣＴＡＰ（Client To Authenticator Protocol）が規定されている（非特許文献２参照）。
ＣＴＡＰを利用することで、登録済み端末（図１０の端末１）の秘密鍵を用いてＦＩＤＯ認証を行い、ログインした上で、新規端末（図１０の端末２）の鍵のRegistrationを行う方法として、以下の手法１と手法２が考えられる。

図１１は、ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法１を説明する図である。なお、図１１の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。
手順１：新規端末２で登録対象のサービスサイトにアクセスする。
手順２：新規端末２は、端末１を外部Authenticatorとして利用する（ＣＴＡＰを用いる）ことで、登録済みの秘密鍵によってＦＩＤＯ認証を行ってログインする。
手順３：サービスサイト（サービスサイトＡ２１）と新規端末２間で通信セッションが確立する。
手順４：確立した通信セッション経由で新規端末２自身のAuthenticatorの鍵をRegistrationする。

図１２は、ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法２を説明する図である。
手順１：端末１で登録対象のサービスサイト（サービスサイトＡ２１）にアクセスする。
手順２：端末1自身のAuthenticator内の登録済みの秘密鍵によってＦＩＤＯ認証を行ってログインする。
手順３：サービスサイトと端末1間で通信セッションが確立
手順４：端末１は、新規端末２を外部Authenticatorとして利用（ＣＴＡＰを用いる）し、外部Authenticator（新規端末２）の鍵をRegistrationする。

FIDO Alliance,"SIMPLER, STRONGER AUTHENTICATION", FIDO is the World’s Largest Ecosystem for Standards-Based, Interoperable Authentication ［online］,［平成３０年１月２０日検索］,インターネット 〈 https://fidoalliance.org/〉 R. Lindemann, et al., FIDO 2.0: Client To Authenticator Protocol, FIDO Alliance Review Draft, 2016.［平成３０年１月２０日検索］,インターネット 〈 URL :https://fidoalliance.org/specs/fido-v2.0-rd-20161004/fido-client-to-authenticator-protocol-v2.0-rd-20161004.html〉 西村ら, "同一所有者に属する端末間のユーザ認証用秘密鍵のセキュアな共有に関する一検討", 電子情報通信学会 技術研究報告, IN2016-172, pp.449-454, 2017. A. Takakuwa, et al., "The Transfer Access Protocol - Moving to New Authenticators in the FIDO Ecosystem", Technical Report UW-CSE-17-06-01, The University of Washington, 2017.

従来技術であるＣＴＡＰを用いた手法では、新規端末（図１１および図１２の新規端末２）を登録する対象のサービスサイトに個々にアクセスし、登録処理を開始することが前提となる。
登録済み端末（図１１および図１２の端末１）で多数のサービスサイトを利用している場合、端末２を新規に導入したタイミングで、それら全てのサービスサイトについて利用可能な状態にすることが求められる。

図１３は、多数のサービスサイトについて利用可能な状態にする際の課題を説明する図である。図１３は、図１１の手法１の例を示したが、図１２の手法２についても同様である。
図１３に示すように、登録済み端末１は、多数のサービスサイト（サービスサイトＡ２１、サービスサイトＢ２２、サービスサイトＣ２３、およびサービスサイトＤ２４）を利用している。端末１のAuthenticator１０（セキュア領域）には、公開鍵１−Ａとペアになる秘密鍵１−Ａと、公開鍵１−Ｂとペアになる秘密鍵１−Ｂと、公開鍵１−Ｃとペアになる秘密鍵１−Ｃと、公開鍵１−Ｄとペアになる秘密鍵１−Ｄと、が格納されている。
端末２を新規に導入したタイミングで、それら全てのサービスサイトを使えるようにしたい要請がある。このため、ユーザが対象サイトへ個々にアクセス（例えばＵＲＬ入力、検索サイト経由）してRegistrationを開始する。しかしながら、従来手法には下記のような問題がある。

（１）ユーザが個々のサービスサイトに能動的にアクセス（ＵＲＬ入力、検索エンジン経由でのページ遷移等）し、Registrationを行う必要がある。このため、サービスサイトの数に応じて作業負担が増すという課題がある。
（２）登録済み端末１で利用中の全サービスサイトについて漏れなく新規端末２のRegistrationを行う必要がある。このため、ユーザが利用中のサービスサイト全てを把握しておく負担があるという課題がある。

このような背景を鑑みて本発明がなされたのであり、本発明は、複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、前記登録済み端末は、前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorが備え、前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、前記新規端末で新規に生成した暗号鍵のRegistrationを行う登録機能部を備えることを特徴とする端末登録システムとした。

また、請求項７に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、前記登録済み端末は、前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorに有し、登録機能部は、前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証するステップと、前記新規端末で新規に生成した暗号鍵のRegistrationを行うステップと、を実行する端末登録方法とした。

このようにすることで、ＦＩＤＯ認証を行うサービスサイトにおいて、登録済み端末を用いて新規端末をRegistrationするユースケースを対象とする場合、登録機能部が取得したサービスサイト一覧情報をもとに、登録対象のサービスサイトに対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。また、ユーザは新規端末の利用開始時にRegistrationをしたいサービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。

請求項２に記載の発明は、前記登録機能部が、前記登録済み端末側に配置され、前記登録済み端末の前記Authenticatorに登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、前記新規端末をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行うことを特徴とする請求項１に記載の端末登録システムとした。

このようにすることで、元々使っていた登録済み端末側に登録結果が表示されるので、ユーザは使いなれた登録済み端末側で登録結果を確認することができる。

請求項３に記載の発明は、前記登録機能部が、前記新規端末側に配置され、前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインし、前記新規端末は、確立されたセッション上で、自身のAuthenticatorに関するRegistrationを行うことを特徴とする請求項１に記載の端末登録システムとした。

このようにすることで、新規端末側に登録結果が表示されるので、ユーザはいまから使いたい新規端末側で登録結果を確認することができる。

請求項４に記載の発明は、前記登録機能部が、前記登録済み端末および前記新規端末とは異なる外部装置に配置され、前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、前記新規端末を外部Authenticatorとして用い、新規にRegistrationを行うことを特徴とする請求項１に記載の端末登録システムとした。

このようにすることで、外部装置側に登録機能部が配置されるので、端末側の必要機能を最低限にした機能構成とすることができる。

請求項５に記載の発明は、前記登録機能部が、ユーザに対して、各サービスサイトへの登録進捗状況を通知することを特徴とする請求項１に記載の端末登録システムとした。

このようにすることで、ユーザはサービスサイトへの登録進捗状況（例えば対象サイト数、登録完了数、登録失敗）を確認することができる。また、失敗したサイトを明示することで、有効でないサイトを確認することができる。

請求項６に記載の発明は、前記登録機能部が、各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行うことを特徴とする請求項１に記載の端末登録システムとした。

このようにすることで、通信障害等によってあるサービスサイトへの登録が失敗した際にリトライにより接続される可能性を高めることができる。また、リトライ回数を設けることで、接続可能性の低い（無い）場合のアクセス時間を低減することができる。

本発明によれば、複数のサービスサイトへの新規端末の登録に際し、ユーザ利便性を向上させる端末登録システムおよび端末登録方法を提供することができる。

本発明の概要を示す図である。 本発明の第１の実施形態に係る端末登録システムを示す構成図である。 上記第１の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 本発明の第２の実施形態に係る端末登録システムを示す構成図である。 上記第２の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 本発明の第３の実施形態に係る端末登録システムを示す構成図である。 上記第３の実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。 リトライ制御・進捗状況通知を示すシーケンス図である。 標準技術（ＦＩＤＯ）の特徴を説明する図である。 標準技術（ＦＩＤＯ）において、新規端末の登録を説明する図である。 ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法１を説明する図である。 ＣＴＡＰを用いた新規端末の鍵のRegistrationの手法２を説明する図である。 多数のサービスサイトについて利用可能な状態にする際の課題を説明する図である。 秘密鍵のセキュアな共有技術を説明する図であり、（ａ）は集中型共有方式による共有技術を示す図、（ｂ）は分散型共有方式による共有技術を示す図である。 再登録の利便性向上技術を説明する図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における端末登録システム等について説明する。
［システム構成と処理概要］
まず、本発明と既存技術との関係性について説明する。
<秘密鍵のセキュアな共有技術>
図１４は、秘密鍵のセキュアな共有技術を説明する図であり、図１４（ａ）は集中型共有方式による共有技術を示し、図１４（ｂ）は分散型共有方式による共有技術を示す。
本人確認情報に基づいて秘密鍵を端末間でセキュアに共有する技術が提案されている（非特許文献３参照）。
図１４（ａ）に示すように、集中型共有方式では、端末１，２は、キーストア３０に認証鍵を保管しておく。端末１，２は、本人確認情報をもとにアクセス制御を行ってキーストア３０にアクセスし、キーストア３０に保管された同一の鍵を共用する。
図１４（ｂ）に示すように、分散型共有方式では、登録済み端末１と新規端末２の鍵共有を行っておく。例えば、登録済み端末１は、本人確認情報をもとに新規端末２との間で所有者一致を確認し、所有者一致が確認できた場合には登録済み端末１の認証鍵を新規端末２に複製する。
上記集中型共有方式および上記分散型共有方式のいずれの共有技術でも、新端末のRegistrationを新たに行わずともＦＩＤＯ認証を利用することができる。しかし、ＦＩＤＯ仕様は、秘密鍵を端末に閉じ込めることを前提としており、前記いずれかの共有技術を利用するためには、ＦＩＤＯ標準仕様に準拠した端末をそのまま利用できず、独自に拡張した端末を利用する必要がある。

<再登録の利便性向上技術>
図１５は、再登録の利便性向上技術を説明する図である。
図１５に示すように、登録済み端末１の秘密鍵で作成した署名を新規端末２に事前に付与しておく。これにより、新規端末２のRegistrationを任意のタイミングかつユーザ作業なしで実施可能とする技術が提案されている（非特許文献４参照）。
本技術により、ユーザは、新規端末２の初回時に能動的に全てのサービスサイト２１にアクセスしてRegistration作業を行っておかずとも、サービスサイト２１への初回アクセス時に自動的に（ユーザ作業なしに）Registrationが行われる。このため、サービスサイト数に比例したユーザの作業負担がない。しかし、本技術は、自動でRegistrationを行うためにＦＩＤＯプロトコルに拡張が必要であり、また、新規端末２上で署名情報を管理する機能追加が必要である。本技術は、上記図１４の場合と同様に、ＦＩＤＯ標準仕様に準拠した端末をそのまま利用できず、独自に拡張した端末を利用する必要がある。

本発明は、登録済み端末を用いた複数のサービスサイトに対する新規端末の登録に際し、ユーザ利便性を向上させるものである。

［システム構成と処理概要］
図１は、本発明の概要を示す図である。
図１に示すように、端末登録システムは、登録済み端末１のAuthenticator１０が保管するサービスサイト一覧情報１１０と、複数のサービスサイトへの新規端末２のRegistrationを実行する機能部であるRegistration Manager１００（登録機能部）と、を備える。
サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬ（Uniform Resource Locator）を紐付けて管理するためのＵＲＬ一覧である。サービスサイト一覧情報１１０は、登録済み端末１のAuthenticator１０（認証装置）に保管される。

Registration Manager１００は、下記のように登録済み端末１と新規端末２との双方を制御する。
Registration Manager１００は、登録済み端末１から、登録済み端末１のAuthenticator１０が保管しているサービスサイト一覧情報１１０を取得する（図１の符号ａ参照）。
Registration Manager１００は、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。Registration Manager１００は、上記Registration処理を、サービスサイト一覧情報１１０に保管されたＵＲＬの全サイト分、自動実行する。
例えば、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、全サービスサイト（サービスサイトＡ２１，サービスサイトＢ２２，…）に対して、登録済み端末１を用いた新規端末２の登録を自動実行する（図１の符号ｂ参照）。

ここで、Registration Manager１００は、ユーザに対する登録進捗状況の表示や、通信障害等による失敗時にリトライ制御なども実行する（図８で後記する）。図１の例では、Registration Manager１００は、登録済み端末１の秘密鍵１−Ａを用いて登録対象のサービスＡサイトへＦＩＤＯ認証を行う（図１の符号ｃ参照）。そしてRegistration Manager１００は、新規端末２で新規に生成した暗号鍵のRegistration（登録処理）を行う（図１の符号ｄ参照）。
以上は、サービスサイトＡ２１に対する、登録済み端末１を用いた新規端末２の登録を自動実行する例であるが、サービスサイトＢ２２に対しても同様に処理する（図１の符号ｅ，ｆ参照）。

このように、Registration Manager１００は、全サービスサイトに対して、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証と、新規端末２で新規に生成した暗号鍵のRegistrationを行う。
なお、Registration Manager１００は、登録済み端末１側、新規端末２側、登録済み端末１および新規端末２の外部のいずれに配置されてもよい。Registration Manager１００を、登録済み端末１側に配置する例を第１の実施形態で、新規端末２側に配置する例を第２の実施形態で、端末の外部に配置する例を第３の実施形態でそれぞれ説明する。

（第１の実施形態）
第１の実施形態は、Registration Manager１００を登録済み端末１側に配置する例である。
図２は、本発明の第１の実施形態に係る端末登録システムを示す構成図である。なお、図２の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。

［端末登録システムの全体構成］
図２に示すように、本実施形態に係る端末登録システムは、登録済み端末（端末１）、新規端末（端末２）に加え、ネットワーク上に、サービスサイト２０と、ＤＮＳ（Domain Name System）サーバ３０（図３参照）と、を含んで構成される。登録済み端末（端末１）と、新規端末（端末２）と、サービスサイト２０と、ＤＮＳサーバ３０とは、通信ネットワーク（図示省略）で接続されており、相互に通信可能である。

<サービスサイト>
サービスサイト２０は、Ｗｅｂアプリケーションサーバ（Web application server）２１１と、ＦＩＤＯサーバ２１２と、を備える。
Ｗｅｂアプリケーションサーバ２１１は、ソフトウェアの実行環境や連携機能などを持つＷｅｂサーバである。Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２と接続・連携して複雑な処理を行う機能を持つ。Ｗｅｂアプリケーションサーバ２１１は、例えばＥＣ（Electronic Commerce）サイトを運営するサービス事業者が運用するＷｅｂサーバであり、サービスを利用するユーザの登録と認証とを行う。

ＦＩＤＯサーバ２１２は、ＦＩＤＯ認証をつかさどるものであり、Ｗｅｂアプリケーションサーバ２１１の中で認証を行う部分だけが切り離されてライブラリとして使用される。

<端末１，２の構成>
端末１，２は、認証用端末であり、例えばスマートフォン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートフォンを例に採る。
端末１，２は、通常のアプリケーション等が動作する領域である通常領域と、マルウェア等が混入しないように管理された領域（外部から不正に侵入できないように管理された領域）であるAuthenticator１０内（セキュア領域）とを論理的に備える。
通常領域は、一般のアプリケーションプログラムが実行される環境である。通常領域は、ユーザエージェント１１と、ＦＩＤＯクライアント１２とが備わる。

Authenticator１０は、外部から不正に侵入できないように管理された領域に存在し、生体情報（指紋情報など）が保管される。Authenticator１０は、ＣＰＵ（Central Processing Unit）やＯＳ（Operating System）の特権モードで実行され、特定のプログラムや特定の手順によってのみ、Authenticator１０のプログラムの呼び出しやデータへのアクセスが可能となる。
Authenticator１０は、チャレンジ・レスポンス認証を行うために鍵を認証する。また、生体認証を行ってから鍵を使えるようにするなど、鍵の取り扱いに関する部分を取り扱う。具体的には、Authenticator１０は、指紋認証などの認証画面を表示し、ユーザを認証する。また、Authenticator１０は、サービスサイト２０から取得した乱数、等をユーザ秘密鍵で署名し、サービスサイト２０に送信する。

ユーザエージェント１１は、ユーザがサービスサイト２０のＷｅｂアプリケーションサーバ２１１にアクセスするためのブラウザ等である。ユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＷｅｂサービスを利用して鍵登録要求および認証要求を発行する。

ＦＩＤＯクライアント１２は、サービスサイト２０のＦＩＤＯサーバ２１２と対になるものであり、ＦＩＤＯサーバ２１２（ＦＩＤＯのライブラリ）に対して自分のユーザプロトコルを送信し、ＦＩＤＯサーバ２１２との間で認証メッセージをやり取りする。
ＦＩＤＯクライアント１２は、メッセージの組み立てや、プロトコルの組み立てを行うのに対し、Authenticator１０は、ＦＩＤＯクライアント１２が行うメッセージの組み立てやプロトコルの組み立てのうち、鍵の取り扱いに関する部分を取り扱う。

<ＦＩＤＯの認証（authentication）／登録（registration）>
・認証（authentication）
サービスサイト２０のＷｅｂアプリケーションサーバ２１１からの「ユーザ認証の開始」の要求を受けたＦＩＤＯサーバ２１２は、自ら生成した乱数などの情報を、端末１，２のユーザエージェント１１を介してＦＩＤＯクライアント１２に送信する。ＦＩＤＯ認証要求を受信したＦＩＤＯクライアント１２は、Authenticator１０にユーザ登録を要求する。Authenticator１０は、指紋認証などの認証画面を表示し、ユーザを認証する。認証に成功した場合、Authenticator１０は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１から取得した乱数、等を秘密鍵で署名し、サービスサイト２０のＦＩＤＯサーバ２１２に送信する。ＦＩＤＯサーバ２１２は、受信した署名を検証（ユーザを認証）し、認証結果をＷｅｂアプリケーションサーバ２１１に返却する。

・登録（registration）
サービスサイト２０のＷｅｂアプリケーションサーバ２１１からの「ユーザ登録の開始」の要求を受けたＦＩＤＯサーバ２１２は、自ら生成した乱数などの情報を、端末１，２のユーザエージェント１１を介してＦＩＤＯクライアント１２に送信する。ＦＩＤＯ登録要求を受信したＦＩＤＯクライアント１２は、Authenticator１０にユーザ登録を要求する。Authenticator１０は、指紋などの生体情報の登録画面を表示し、ユーザに生体情報を登録させる。登録が完了すると、Authenticator１０は、公開鍵暗号の鍵ペアを生成してユーザに紐づける。また、公開鍵やサーバから取得した乱数などから、Authenticator１０の秘密鍵で署名生成し、ＦＩＤＯクライアント１２経由でサービスサイト２０のＦＩＤＯサーバ２１２に送信する。ＦＩＤＯサーバ２１２は、受信した署名を検証（Authenticatorの正当性確認）し、ユーザの公開鍵を登録して、その結果をＷｅｂアプリケーションサーバ２１１に返却する。

<端末１（登録済み端末）>
登録済み端末１は、Authenticator１０内に、公開鍵１−Ａとペアになる秘密鍵１−Ａと、公開鍵１−Ｂとペアになる秘密鍵１−Ｂと、公開鍵１−Ｃとペアになる秘密鍵１−Ｃと、サービスサイト一覧情報１１０と、を保管する。
サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬを紐付けて管理する。例えば、図２に示すように、サービスサイト一覧情報１１０は、秘密鍵「0A295BE44F…」とサイトＵＲＬ「https://svcA.com」とを、また秘密鍵「129CC8B6A2..」とサイトＵＲＬ「https://svcB.org」とを、秘密鍵「FE0085B126…」とサイトＵＲＬ「https://svcC.net」とを紐付ける。
サービスサイト一覧情報１１０は、秘密鍵と対象サイトのＵＲＬを紐付けに加え、ユーザ名を紐付け対象としてもよい。このようにすれば、複数のユーザ名のユーザが一のＵＲＬを使用したり、逆に、ユーザ名毎に秘密鍵と対象サイトのＵＲＬの組み合わせを変えることができる。
なお、従来のユーザ認証技術において、秘密鍵と対象サイトのＵＲＬを紐付けて管理するものはなかった。

<Registration Manager１００>
本実施形態では、登録済み端末１側に、Registration Manager１００が配置される。
Registration Manager１００は、登録済み端末１のAuthenticator１０に登録されている全ての秘密鍵について、対象のサービスサイトにログインした上で、新規端末２をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行う。

以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
まず、端末登録システムの端末登録方法の動作概要について述べる。
図２に示すように、Registration Manager１００は、登録済み端末１側に配置されている。
手順１：Registration Manager１００は、Authenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２〜手順４の処理を実行する。
手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
手順３：Registration Manager１００は、登録済み端末１の内部Authenticator１０に登録されている秘密鍵を利用して対象のサービスサイト２０にＦＩＤＯ認証を行ってログインし、セッションを確立する。
手順４：新規端末２をＣＴＡＰによって外部Authenticator１０として用い、秘密鍵のRegistrationを行う。

より詳細に説明する。Registration Manager１００は、サービスサイト一覧情報１１０を取得することで、サービスサイト一覧情報１１０の秘密鍵を登録済み端末１が持っていることはわかるが、それをサービスサイト２０に提示する手段は持っていない。サービスサイト２０からすれば、登録済み端末１のRegistration Manager１００がアクセスしてきた場合、それがどのユーザであるかは認証できていない状態である。そこで、上記手順３において、Registration Manager１００は、登録済み端末１の内部Authenticator１０に登録されている秘密鍵を利用して対象のサービスサイト２０にＦＩＤＯ認証を行ってログインし、セッションを確立する。次に、上記手順４において、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、秘密鍵のRegistrationを行うことで、新規端末２を登録する、という流れになる。

［制御シーケンス］
図３は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
図３おいて、端末１は登録済み端末であり、Authenticator１０内にサービスサイト一覧情報１１０を保管する。また、端末１には、Registration Manager１００が配置されている。端末２は新規端末である。
ＤＮＳサーバ（Domain Name System）３０は、ドメイン名をＩＰアドレス形式に変換する最もプリミティブな機能に加えて、該当のＵＲＬ上で提供されているサービスのＵＲＬを返すための拡張(ＳＲＶ（SeRVice record）レコード)があり、それを使う。ＤＮＳサーバ３０は、サイトＵＲＬ上で提供されている再登録等を実行するサービスのロケーションをＳＲＶレコードの形式で提供する。
ユーザは新規端末２の追加、変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）を行う。この場合、新規端末２でＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。つまりＦＩＤＯでは、Ｗｅｂサービス毎に秘密鍵のRegistrationを行う必要がある。

ユーザの開始操作は、登録済み端末１のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ１０１）、Registration Manager１００は、登録済み端末１のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ１０２）。登録済み端末１のＦＩＤＯクライアント１２は、新規端末２のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ１０３）。登録済み端末１のＦＩＤＯクライアント１２は、ＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ１０４）。

Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図２参照）の取得要求を送信する（ステップＳ１０５）。
登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ１０６）。ユーザ確認は、生体情報（指紋、顔、虹彩、静脈）やＰＩＮ（Personal Identification Number）コード認証を用いた情報等のユーザ認証である。
登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ１０７）。
以上までが図２の手順１の「サービスサイト一覧情報の取得」である。
以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図２の手順２〜４に対応する；図３の一点鎖線囲み参照）。

Registration Manager１００は、取得したサービスサイト一覧情報１１０（図２参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリ（query）を送信して、サイト上で提供されている再登録サービスにアクセスするためのＵＲＬ（以下、登録用エンドポイントという）を問合せる（ステップＳ１０８）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信して、Registration Manager１００は登録用エンドポイントを取得する（ステップＳ１０９）。

Registration Manager１００は、登録済み端末１のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ１１０）。
登録済み端末１のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ１１１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ１１２）。
以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、登録済み端末１のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。

図３の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１の内部Authenticator１０に保管された秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証を行うものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ１１３）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを登録済み端末１のユーザエージェント１１に送信する（ステップＳ１１４）。登録済み端末１のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ１１５）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ１１６）。

登録済み端末１のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証によりユーザ確認を行う（ステップＳ１１７）。なお、ＦＩＤＯ認証は、全サービスサイトに対して繰り返し行う必要がある。ユーザ負担を減らすため、ステップＳ１１７における生体認証はできるだけ簡便であることが好ましく、例えば指紋による生体認証が挙げられる。また、標準技術（ＦＩＤＯ）の拡張機能では所定時間内の再度の認証は省略することが認められている。ＦＩＤＯは、端末で、生体認証による本人確認と、サーバ認証とを分けており、サービスサイト２０にパスワードを送らないので個人情報が漏れるリスクがない。

ここで、ＦＩＤＯ標準のAuthenticationオペレーションにおいては、乱数(チャレンジ文字列)は、ＦＩＤＯサーバ２１２が生成（ステップＳ１１３の前段）し、その乱数に対してAuthenticator１０の秘密鍵で署名をして返送する。
登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名する（ステップＳ１１８）。
Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ１１９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを登録済み端末１のユーザエージェント１１に送信し（ステップＳ１２０）、ユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ１２１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ１２２）。

以上、上記ステップＳ１１３〜ステップＳ１２２では、登録済み端末１の内部Authenticator１０（登録済みの鍵を保持）を利用してログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ１２３）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と登録済み端末１のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ１２４）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ１２５）。

図３の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、Registrationを行うものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ１２６）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを登録済み端末１のユーザエージェント１１に送信する（ステップＳ１２７）。登録済み端末１のユーザエージェント１１は、登録済み端末１のＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ１２８）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ１２９）。

新規端末２のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ１３０）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。

新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ１３１）。新規端末２のAuthenticator１０は、生成した秘密鍵を登録済み端末１のＦＩＤＯクライアント１２に送信する（ステップＳ１３２）。
登録済み端末１のＦＩＤＯクライアント１２は、生成した秘密鍵を登録済み端末１のユーザエージェント１１に送信する（ステップＳ１３３）。登録済み端末１のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ１３４）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration ResponseをＦＩＤＯサーバ２１２に送信する（ステップＳ１３５）。

以上、上記ステップＳ１２６〜ステップＳ１３５では、新規端末（端末２）をＣＴＡＰによって外部Authenticatorとして用い、新規に生成した秘密鍵のRegistrationを行う、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ１３６）。Ｗｅｂアプリケーションサーバ２１１は、登録済み端末１のユーザエージェント１１にＦＩＤＯRegistration Requestの登録完了を送信する（ステップＳ１３７）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ１３８）。

Registration Manager１００は、全サービスサイトに対して、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証と、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ１３９）。

上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分の繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。また、ユーザに対し登録進捗状況を表示すると、ユーザに対する利便性が向上する。リトライ制御や登録進捗状況の表示制御については、図８で後記する。

以上説明したように、本実施形態に係る端末登録システムは、登録済み端末１を用いて、複数のサービスサイト２０に対する新規端末２を登録するシステムであり、登録済み端末１は、秘密鍵とサービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報１１０をAuthenticator１０が備える。Registration Manager１００は、登録済み端末１のAuthenticator１０からサービスサイト一覧情報１１０を取得する。そして、Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録済み端末１の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、新規端末２で新規に生成した暗号鍵のRegistrationを行う。本実施形態では、登録済み端末１側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１のAuthenticator１０に登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、新規端末２をＣＴＡＰによって外部Authenticator１０として用い、Registrationを行う。

これにより、ＦＩＤＯしか認証手段を持たないサービスサイトにおいて、登録済み端末１を用いて新規端末２をRegistrationするユースケースを対象とすることができる。Registration Manager１００が、登録済み端末１のAuthenticator１０から取得したサービスサイト一覧情報１１０をもとに、登録対象のサービスサイトに対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。

また、Registration Manager１００が登録済み端末１に格納されたサービスサイト一覧を取得し、その全てについてRegistrationを開始することで、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。

また、Registrationの契機となる各サイトへのアクセスを自動的に実行することで、サービスサイトが増えた時のユーザの作業負担が軽減される。

本実施形態では、登録済み端末１側にRegistration Manager１００が配置されるので、元々使っていた登録済み端末１に登録結果が表示される。登録済み端末１は、ユーザにとって使いなれた端末である。ユーザは使いなれた登録済み端末１側で登録結果を確認することができる。

（第２の実施形態）
第２の実施形態は、Registration Manager１００を新規端末２側に配置する例である。
図４は、本発明の第２の実施形態に係る端末登録システムを示す構成図である。図２と同一構成部分には同一番号を付して重複箇所の説明を省略する。なお、図４の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。

端末１は、登録済み端末１であり、端末２は、新規端末２である。
登録済み端末１は、Authenticator１０内に、公開鍵１−Ａとペアになる秘密鍵１−Ａと、公開鍵１−Ｂとペアになる秘密鍵１−Ｂと、公開鍵１−Ｃとペアになる秘密鍵１−Ｃと、サービスサイト一覧情報１１０と、を保管する。

本実施形態では、新規端末２側に、Registration Manager１００が配置される。
Registration Manager１００は、登録済み端末１のAuthenticator１０から全サイトのサービスサイト一覧情報１１０を取得し、各サイトについて、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインする。新規端末２は、確立されたセッション上で、自身のAuthenticatorに関するRegistration処理を実行する。

以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
まず、端末登録システムの端末登録方法の動作概要について述べる。
図４に示すように、Registration Manager１００は、新規端末２側に配置されている。
手順１：Registration Manager１００は、登録済み端末１のAuthenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２〜手順４の処理を実行する。
手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
手順３：Registration Manager１００は、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、セッションを確立する。
手順４：新規端末２は、確立されたセッション上で、自身のAuthenticatorに関するRegistration処理を実行する。

［制御シーケンス］
図５は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
図５おいて、端末１は登録済み端末であり、Authenticator１０内にサービスサイト一覧情報１１０を保管する。端末２は、新規端末であり、Registration Manager１００が配置されている。
ユーザの開始操作は、新規端末２のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ２０１）、Registration Manager１００は、新規端末２のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ２０２）。新規端末２のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ２０３）。新規端末２のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ２０４）。

Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図４参照）の取得要求を送信する（ステップＳ２０５）。
登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ２０６）。ユーザ確認は、生体情報（指紋、虹彩、静脈）やＰＩＮを用いた情報等のユーザ認証である。

登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ２０７）。
以上までが図４の手順１の「サービスサイト一覧情報の取得」である。
以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図４の手順２〜４に対応する；図５の一点鎖線囲み参照）。

Registration Manager１００は、取得したサービスサイト一覧情報１１０（図４参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリを送信して登録用エンドポイントを問合せる（ステップＳ２０８）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信してRegistration Manager１００は登録用エンドポイントを取得する（ステップＳ２０９）。

Registration Manager１００は、新規端末２のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ２１０）。
新規端末２のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ２１１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ２１２）。
以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、新規端末２のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。

図５の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１の外部Authenticator１０から全サイトのＵＲＬリストを取得し、各サイトについて、登録済み端末１をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインするものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ２１３）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを新規端末２のユーザエージェント１１に送信する（ステップＳ２１４）。新規端末２のユーザエージェント１１は、新規端末２のＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ２１５）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ２１６）。

登録済み端末１のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ２１７）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。

登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名をする（ステップＳ２１８）。
Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ１１９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを新規端末２のユーザエージェント１１に送信し（ステップＳ２２０）、新規端末２のユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ２２１）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ２２２）。

以上、上記ステップＳ２１３〜ステップＳ２２２では、登録済み端末１をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ２２３）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と新規端末２のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ２２４）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ２２５）。

図５の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、確立されたセッション上で、新規端末２は自身のAuthenticatorに関するRegistration処理を実行するものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ１２６）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを新規端末２のユーザエージェント１１に送信する（ステップＳ２２７）。新規端末２のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ２２８）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ２２９）。

新規端末２のAuthenticator１０は、生体情報（指紋、顔、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ２３０）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。

新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ２３１）。新規端末２のAuthenticator１０は、生成した秘密鍵を新規端末２のＦＩＤＯクライアント１２に送信する（ステップＳ２３２）。
新規端末２のＦＩＤＯクライアント１２は、生成した秘密鍵を新規端末２のユーザエージェント１１に送信する（ステップＳ２３３）。新規端末２のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ２３４）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration ResponseをＦＩＤＯサーバ２１２に送信する（ステップＳ２３５）。

以上、上記ステップＳ２２６〜ステップＳ２３５では、確立されたセッション上で、新規端末２は自身のAuthenticatorに関するRegistration処理を実行する、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ２３６）。Ｗｅｂアプリケーションサーバ２１１は、新規端末２のユーザエージェント１１にＦＩＤＯRegistration Requestの登録完了を送信する（ステップＳ２３７）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ２３８）。

Registration Manager１００は、全サービスサイトに対して、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ２３９）。

上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分を繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。リトライ制御や登録進捗状況の表示制御については、図８で後記する。

このように、本実施形態に係る端末登録システムは、新規端末２側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１のAuthenticator１０から全サービスサイトのＵＲＬリストを取得し、各サービスサイトについて、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、新規端末２は、確立されたセッション上で、自身のAuthenticator１０に関するRegistrationを行う。

これにより、本実施形態では、第１の実施形態と同様の効果、すなわちRegistration Manager１００が、登録済み端末１のAuthenticator１０から取得したＵＲＬ一覧に対して、自動的にアクセスを行ってRegistrationを行うので、複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。

また、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。

本実施形態では、新規端末２側にRegistration Manager１００が配置されるので、新規端末２に登録結果が表示される。ユーザはいまから使いたい新規端末２側で登録結果を確認することができる。また一般に、新規端末２は、いままで使っていた端末より高機能な場合が多いので、より高機能な新規端末２の資源（例えば高解像度・大画面・高速描画、高速通信など）でRegistrationと登録結果表示を行うことができる。

（第３の実施形態）
第３の実施形態は、Registration Manager１００を登録済み端末１および新規端末２とは異なる外部装置３側に配置する例である。
図６は、本発明の第３の実施形態に係る端末登録システムを示す構成図である。図２および図４と同一構成部分には同一番号を付して重複箇所の説明を省略する。なお、図６の円筒形状で表記されるＣＴＡＰは、ＣＴＡＰの利用を示し、円筒形状で表記されるSessionは、通信経路でSessionが確立していることを示す。

端末１は、登録済み端末１であり、端末２は、新規端末２である。
登録済み端末１は、Authenticator１０内に、公開鍵１−Ａとペアになる秘密鍵１−Ａと、公開鍵１−Ｂとペアになる秘密鍵１−Ｂと、公開鍵１−Ｃとペアになる秘密鍵１−Ｃと、サービスサイト一覧情報１１０と、を保管する。
外部装置３は、例えばＰＣ（personal computer）である。外部装置３は、ＰＣのＵＳＢ（Universal Serial Bus）ポートに挿すＵＳＢトークンであってもよい。ＵＳＢトークンは、ＰＣを使うための鍵であり、ＵＳＢトークンがないか有効にされていないと、特定のデータを開けない、あるいはネットワークに接続できない。また、このＵＳＢトークンに、指紋認証などの生体認証手段を設けてもよい。
外部装置３は、通常領域にユーザエージェント１１と、ＦＩＤＯクライアント１２とを備え、セキュア領域にAuthenticator１０を備える。
外部装置３のAuthenticator１０は、ＦＩＤＯ標準のAuthenticationオペレーションを実行する端末１，２から見た場合、外部Authenticatorに対応する。

本実施形態では、登録済み端末１および新規端末２とは異なる外部装置３側に、Registration Manager１００が配置される。
Registration Manager１００は、登録済み端末１から全サービスサイトのＵＲＬ一覧を取得し、各サイトについて、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistrationを行う。

以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
まず、端末登録システムの端末登録方法の動作概要について述べる。
図６に示すように、Registration Manager１００は、外部装置３側に配置されている。
手順１：Registration Manager１００は、登録済み端末１のAuthenticator１０から登録済み端末１のサービスサイト一覧情報１１０を取得する。
Registration Manager１００は、取得したサービスサイト一覧情報１１０の全ＵＲＬについて、下記手順２〜手順４の処理を実行する。
手順２：Registration Manager１００は、取得したサービスサイト一覧情報１１０をもとに、登録対象ＵＲＬのサービスサイト２０へアクセスする。
手順３：Registration Manager１００は、登録済み端末１をＣＴＡＰによって外部Authenticator１０として用い、ＦＩＤＯ認証を行ってログインし、セッションを確立する。
手順４：ログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行する。

［制御シーケンス］
図７は、本実施形態に係る端末登録システムの端末登録方法を示すシーケンス図である。
図７おいて、ユーザの開始操作は、外部装置３のRegistration Manager１００（以下、Registration Manager１００という）に送信され（ステップＳ３０１）、Registration Manager１００は、外部装置３のＦＩＤＯクライアント１２に新規端末２でＦＩＤＯ認証するための要求を送信する（ステップＳ３０２）。外部装置３のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ３０３）。また、外部装置３のＦＩＤＯクライアント１２は、新規端末２のAuthenticator１０との間でＣＴＡＰチャネルを確立する（ステップＳ３０４）。すなわち、外部装置３は、登録済み端末１のAuthenticator１０と新規端末２のAuthenticator１０との両者の間で、それぞれＣＴＡＰチャネルを確立する。

外部装置３のＦＩＤＯクライアント１２は、登録済み端末１のAuthenticator１０および新規端末２のAuthenticator１０の間でＣＴＡＰチャネルが確立された場合、このＣＴＡＰチャネル確立をRegistration Manager１００に通知する（ステップＳ３０５）。

Registration Manager１００は、登録済み端末１のAuthenticator１０にサービスサイト一覧情報１１０（図７参照）の取得要求を送信する（ステップＳ３０６）。
登録済み端末１のAuthenticator１０は、意図しないリストの不正取得防止のためユーザ確認を行う（ステップＳ３０７）。ユーザ確認は、生体情報（指紋、顔、虹彩、静脈）やＰＩＮを用いた情報等のユーザ認証である。
登録済み端末１のAuthenticator１０は、生体認証等によりユーザ確認が取れた場合、Authenticator１０内に保管しているサービスサイト一覧情報１１０をRegistration Manager１００に送信する（ステップＳ３０８）。
以上までが図６の手順１の「サービスサイト一覧情報の取得」である。
以降のシーケンスは、サービスサイト一覧情報中の全サイト分の繰り返しである（図６の手順２〜４に対応する；図７の一点鎖線囲み参照）。

Registration Manager１００は、取得したサービスサイト一覧情報１１０（図６参照）を参照して、ＤＮＳサーバ３０に対してＤＮＳクエリを送信して登録用エンドポイントを問合せる（ステップＳ３０９）。ＤＮＳサーバ３０は、Registration Manager１００に登録用エンドポイントを送信してRegistration Manager１００は登録用エンドポイントを取得する（ステップＳ３１０）。

Registration Manager１００は、外部装置３のユーザエージェント１１に取得した登録用エンドポイントを送信する（ステップＳ３１１）。外部装置３のユーザエージェント１１は、サービスサイト２０のＷｅｂアプリケーションサーバ２１１に対し登録用エンドポイントへのアクセスを行う（ステップＳ３１２）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、サービスサイト２０のＦＩＤＯサーバ２１２にＦＩＤＯ認証要求を出力してＦＩＤＯ認証を開始する（ステップＳ３１３）。
以下のシーケンスで、サービスサイト２０のＦＩＤＯサーバ２１２と登録済み端末１のAuthenticator１０との間で、サービスサイト２０のＷｅｂアプリケーションサーバ２１１、外部装置３のユーザエージェント１１およびＦＩＤＯクライアント１２を介してＦＩＤＯ標準のAuthenticationオペレーションを行う。

図７の破線囲みに示すＦＩＤＯ標準のAuthenticationオペレーションは、登録済み端末１から全サービスサイトのサービスサイト一覧情報１１０を取得し、各サイトについて、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistrationを行うものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Authentication Requestを発行し（ステップＳ３１４）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Authentication Requestを外部装置３のユーザエージェント１１に送信する（ステップＳ３１５）。外部装置３のユーザエージェント１１は、外部装置３のＦＩＤＯクライアント１２にＦＩＤＯ Authentication Requestを送信し（ステップＳ３１６）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Requestを登録済み端末１のAuthenticator１０に送信する（ステップＳ３１７）。

登録済み端末１のAuthenticator１０は、生体情報（指紋、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ３１８）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。

登録済み端末１のAuthenticator１０は、ユーザ確認が取れた場合、ＦＩＤＯサーバ２１２が生成した乱数に対してAuthenticator１０の秘密鍵で署名をする（ステップＳ１１８）。
Authenticator１０は、秘密鍵で署名したＦＩＤＯAuthentication ResponseをＦＩＤＯクライアント１２に送信し（ステップＳ３２０）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Authentication Responseを外部装置３のユーザエージェント１１に送信し（ステップＳ３２１）、外部装置３のユーザエージェント１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ３２２）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、ＦＩＤＯ Authentication Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ３２３）。

以上、上記ステップＳ３１４〜ステップＳ３２３では、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインする、ＦＩＤＯ標準のAuthenticationオペレーションに対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ認証ＯＫをサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信し（ステップＳ３２４）、サービスサイト２０のＷｅｂアプリケーションサーバ２１１と外部装置３のユーザエージェント１１との間でTLS Sessionを確立する（ステップＳ３２５）。TLS Sessionが確立されると、Ｗｅｂアプリケーションサーバ２１１は、ＦＩＤＯサーバ２１２にＦＩＤＯ登録開始を通知する（ステップＳ３２６）。

図７の破線囲みに示すＦＩＤＯ標準のRegistrationオペレーションは、登録済み端末１を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行するものである。

サービスサイト２０のＦＩＤＯサーバ２１２は、Ｗｅｂアプリケーションサーバ２１１にＦＩＤＯ Registration Requestを発行し（ステップＳ３２７）、Ｗｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Requestを外部装置３のユーザエージェント１１に送信する（ステップＳ３２８）。外部装置３のユーザエージェント１１は、ＦＩＤＯクライアント１２にＦＩＤＯ Registration Requestを送信し（ステップＳ３２９）、ＦＩＤＯクライアント１２は、このＦＩＤＯ Registration Requestを新規端末２のAuthenticator１０に送信する（ステップＳ３３０）。

新規端末２のAuthenticator１０は、生体情報（指紋、虹彩、静脈）による生体認証等によりユーザ確認を行う（ステップＳ３３１）。なお、ユーザ負担を減らすため、生体認証は、例えば指紋による生体認証を行う。また、所定時間内の認証を省略してもよい。

新規端末２のAuthenticator１０は、ユーザ確認が取れた場合、ＣＴＡＰを用いてＦＩＤＯAuthentication（未登録）の秘密鍵を新規に生成する（ステップＳ３３２）。新規端末２のAuthenticator１０は、生成した秘密鍵を外部装置３のＦＩＤＯクライアント１２に送信する（ステップＳ３３３）。
外部装置３のＦＩＤＯクライアント１２は、生成した秘密鍵を外部装置３のユーザエージェント１１に送信する（ステップＳ３３４）。外部装置３のユーザエージェント１１は、このＦＩＤＯ Authentication（未登録）の秘密鍵をＦＩＤＯ Registration Responseとしてサービスサイト２０のＷｅｂアプリケーションサーバ２１１に送信する（ステップＳ３３５）。サービスサイト２０のＷｅｂアプリケーションサーバ２１１は、このＦＩＤＯ Registration Responseをサービスサイト２０のＦＩＤＯサーバ２１２に送信する（ステップＳ３３６）。

以上、上記ステップＳ３２７〜ステップＳ３３６では、新規端末２を外部Authenticatorとして用い、新規にRegistration処理を実行する、ＦＩＤＯ標準のRegistrationオペレーションを実行に対応する。

サービスサイト２０のＦＩＤＯサーバ２１２は、ＦＩＤＯ Registration Responseを受け取ると、サービスサイト２０のＷｅｂアプリケーションサーバ２１１にＦＩＤＯ認証ＯＫを送信する（ステップＳ３３７）。Ｗｅｂアプリケーションサーバ２１１は、外部装置３のユーザエージェント１１にＦＩＤＯ Registration Requestの登録完了を送信する（ステップＳ３３８）。ユーザエージェント１１は、Registration Manager１００にＦＩＤＯRegistration Requestの登録完了を通知する（ステップＳ３３９）。

Registration Manager１００は、全サービスサイトに対して、新規端末２で新規に生成した鍵のRegistrationが完了したことを確認する。Registration Manager１００は、全サービスサイトに対する新規端末２の鍵のRegistrationが完了した場合、ユーザに完了通知を発行して本シーケンスを終了する（ステップＳ３４０）。

上述したように、Registration Manager１００は、サービスサイト一覧情報中の全サイト分を繰り返すので、通信障害等により、あるサービスサイトの登録が完了しない場合も考えられる。リトライ制御や登録進捗状況の表示制御については、図８で後記する。

このように、本実施形態に係る端末登録システムは、登録済み端末１および新規端末２とは異なる外部装置３側にRegistration Manager１００が配置される。Registration Manager１００は、登録済み端末１から全サービスサイトのＵＲＬ一覧を取得し、各サービスサイトについて、登録済み端末１を外部Authenticator１０として用いてＦＩＤＯ認証を行いログインした上で、新規端末２を外部Authenticator１０として用い、新規にRegistrationを行う。

これにより、本実施形態では、第１の実施形態および第２の実施形態と同様の効果、すなわち複数のサービスサイトへのRegistrationに関するユーザ利便性を向上させることができる。また、ユーザ自身が利用している（新規端末の利用開始時にRegistrationをしたい）サービスサイトを管理する負担がない。さらに、サービスサイトが増えた時のユーザの作業負担が軽減される。

本実施形態では、外部装置３側にRegistration Manager１００が配置されるので、端末側の必要機能を最低限にした機能構成とすることができる。端末のリソースを保つことができる。また、端末の機能上で制約がある場合は、より高機能な外部装置３側で選ぶことも可能である。

［リトライ制御・進捗状況通知］
次に、リトライ制御・進捗状況通知の例について説明する。
図８は、リトライ制御・進捗状況通知を示すシーケンス図である。
Registration Manager１００は、登録済み端末１側、新規端末２側、または端末１，２の外部のいずれに配置されていてもよい。登録対象のサービスサイト２０は、サービスサイトＡ２１，サービスサイトＢ２２，サービスサイトＣ２３であるとする。
ユーザの開始操作は、Registration Manager１００に送信され（ステップＳ４０１）、Registration Manager１００は、登録済み端末１からサービスサイト一覧情報１１０を取得する（ステップＳ４０２）。そして、Registration Manager１００は、ユーザに登録開始の通知を行う（ステップＳ４０３）。
なお、ユーザの開始操作からサービスサイト一覧情報１１０の取得に至る具体的なシーケンスについては、図３、図５、および図７により詳述した。

図８の符号ｇに示すように、端末には、ユーザに進捗状況として「登録開始」および、登録対象サイト数「３」であることが通知される。この通知は、例えば、端末の表示画面において、該当アプリの通知欄に表示される。この例では、「登録開始」「対象：３ 完了：０ 失敗：０」が表示される。

Registration Manager１００は、各サービスサイトについて、登録済み端末１または新規端末２をＣＴＡＰによって外部Authenticatorとして用い、Registrationを行う。
すなわち、Registration Manager１００は、サービスサイトＡ２１への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始し（ステップＳ４０４）、登録済み端末１との間でＦＩＤＯ標準のAuthenticationオペレーションを実行する（ステップＳ４０５）。Registration Manager１００は、サービスサイトＡ２１からＦＩＤＯ認証結果を受信する（ステップＳ４０６）。

そして、Registration Manager１００は、サービスサイトＡ２１に対しＦＩＤＯ認証登録要求を出力してＦＩＤＯ認証登録を開始し（ステップＳ４０７）、新規端末２との間でＦＩＤＯ標準のRegistrationオペレーションを実行する（ステップＳ４０８）。Registration Manager１００は、サービスサイトＡ２１からＦＩＤＯ認証登録結果を受信する（ステップＳ４０９）。
なお、ＦＩＤＯ標準のAuthenticationオペレーションおよびＦＩＤＯ標準のRegistrationオペレーションについては、図３、図５、および図７により詳述した。

Registration Manager１００は、サービスサイトＡ２１への登録が完了すると、ユーザに登録進捗状況の更新を通知する（ステップＳ４１０）。
図８の符号ｈに示すように、端末には、ユーザに進捗状況として、「登録進捗」「対象：３ 完了：１ 失敗：０」表示される。

以下同様に、Registration Manager１００は、サービスサイトＢ２２への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始する（ステップＳ４１１）。
しかしながら、Registration Manager１００が発行したＦＩＤＯ認証開始要求は、サービスサイトＢ２２に到達していない（図８の符号ｉと×印参照）。通信障害等によりサービスサイトＢ２２へＦＩＤＯ認証開始要求が到達していないと想定される。
図８の符号ｊに示すように、Registration Manager１００は、サービスサイトＢ２２からの応答がない場合、一定時間後に一回目のリトライを実行する。
Registration Manager１００は、再度、サービスサイトＢ２２に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４１２）。
リトライによりサービスサイトＢ２２へのＦＩＤＯ認証開始要求の送信が成功し、登録済み端末１との間でＦＩＤＯ標準のAuthenticationオペレーションを実行する（ステップＳ４１３）。Registration Manager１００は、サービスサイトＢ２２からＦＩＤＯ認証結果を受信する（ステップＳ４１４）。

そして、Registration Manager１００は、サービスサイトＢ２２に対しＦＩＤＯ認証登録要求を出力してＦＩＤＯ認証登録を開始し（ステップＳ４１５）、新規端末２との間でＦＩＤＯ標準のRegistrationオペレーションを実行する（ステップＳ４１６）。Registration Manager１００は、サービスサイトＢ２２からＦＩＤＯ認証登録結果を受信する（ステップＳ４１７）。

Registration Manager１００は、サービスサイトＢ２２への登録が完了すると、ユーザに登録進捗状況の更新を通知する（ステップＳ４１８）。
図８の符号ｋに示すように、端末には、ユーザに進捗状況として、「登録進捗」「対象：３ 完了：２ 失敗：０」表示される。

次に、Registration Manager１００は、サービスサイトＣ２３への登録に対し、ＦＩＤＯ認証開始要求を出力してＦＩＤＯ認証を開始する（ステップＳ４１９）。
しかしながら、Registration Manager１００が発行したＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｌと×印参照）。この段階では、通信障害等によりサービスサイトＣ２３へＦＩＤＯ認証開始要求が到達していないと想定される。

図８の符号ｍに示すように、Registration Manager１００は、サービスサイトＣ２３からの応答がない場合、一定時間後に一回目のリトライを実行する。
Registration Manager１００は、一回目のリトライで、サービスサイトＣ２３に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４２０）。
一回目のリトライによるサービスサイトＣ２３へのＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｎと×印参照）。
図８の符号ｏに示すように、Registration Manager１００は、サービスサイトＣ２３からの応答がない場合、一定時間後に二回目のリトライを実行する。
Registration Manager１００は、二回目のリトライで、サービスサイトＣ２３に、ＦＩＤＯ認証開始要求を送信する（ステップＳ４２１）。

二回目のリトライによってもサービスサイトＣ２３へのＦＩＤＯ認証開始要求は、サービスサイトＣ２３に到達していない（図８の符号ｐと×印参照）。この場合、重度の通信障害があるか、サービスサイトＣ２３がネットワークに接続されていないことが想定される。
図８の符号ｑに示すように、Registration Manager１００は、一定回数（ここでは二回）のリトライ後、サービスサイトＣ２３への登録失敗と判断し、サービスサイトＣ２３への登録処理を終了する。
Registration Manager１００は、サービスサイトＣ２３への登録終了（登録失敗）を通知する（ステップＳ４２２）。
図８の符号ｒに示すように、端末には、ユーザに進捗状況として、「登録完了」「対象：３ 完了：２ 失敗：１」表示される。この場合、図８の符号ｓに示すように、登録に失敗したサービスサイトを明示するとよりよい。例えば、登録失敗したサービスサイトＣ２３のＵＲＬを表示する。

このように、Registration Manager１００は、ユーザに対して、各サービスサイトへの登録進捗状況を通知することで、ユーザはサービスサイトへの登録進捗状況（対象サイト数、登録完了数、登録失敗）を確認することができる。また、失敗したサイトを明示することで、有効でないサイトを確認することができる。

また、Registration Manager１００は、各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行うことで、通信障害等によってあるサービスサイトへの登録が失敗した際にリトライにより接続される可能性を高めることができる。また、リトライ回数を設けることで、接続可能性の低い（無い）場合のアクセス時間を低減することができる。

なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、明細書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。

１ 登録済み端末（端末）
２ 新規端末（端末）
３ 外部装置
１０ Authenticator（認証装置）
１１ ユーザエージェント
１２ ＦＩＤＯクライアント
２０，２１，２２，２３，２４ サービスサイト
３０ ＤＮＳサーバ
１００ Registration Manager（登録機能部）
１１０ サービスサイト一覧情報
２１１ Ｗｅｂアプリケーションサーバ
２１２ ＦＩＤＯサーバ

Claims (7)

1. 秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、
   登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、
   前記登録済み端末は、
   前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorが備え、
   前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証し、前記新規端末で新規に生成した暗号鍵のRegistrationを行う登録機能部
   を備えることを特徴とする端末登録システム。
2. 前記登録機能部は、前記登録済み端末側に配置され、
   前記登録済み端末の前記Authenticatorに登録されている全ての秘密鍵について、登録対象サービスサイトにログインし、前記新規端末をＣＴＡＰ（Client To Authenticator Protocol）によって外部Authenticatorとして用い、Registrationを行う
   ことを特徴とする請求項１に記載の端末登録システム。
3. 前記登録機能部は、前記新規端末側に配置され、
   前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末をＣＴＡＰによって外部Authenticatorとして用い、ＦＩＤＯ認証を行ってログインし、
   前記新規端末は、確立されたセッション上で、自身のAuthenticatorに関するRegistrationを行う
   ことを特徴とする請求項１に記載の端末登録システム。
4. 前記登録機能部は、前記登録済み端末および前記新規端末とは異なる外部装置に配置され、
   前記登録済み端末の前記Authenticatorからサービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、各サービスサイトについて、前記登録済み端末を外部Authenticatorとして用いてＦＩＤＯ認証を行いログインした上で、前記新規端末を外部Authenticatorとして用い、新規にRegistrationを行う
   ことを特徴とする請求項１に記載の端末登録システム。
5. 前記登録機能部は、
   ユーザに対して、各サービスサイトへの登録進捗状況を通知する
   ことを特徴とする請求項１に記載の端末登録システム。
6. 前記登録機能部は、
   各サービスサイトへの登録が失敗した場合、所定回数のリトライを実行するリトライ制御を行う
   ことを特徴とする請求項１に記載の端末登録システム。
7. 秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、
   前記登録済み端末は、
   前記秘密鍵と前記サービスサイトにアクセスするためのＵＲＬとを紐付けるサービスサイト一覧情報をAuthenticatorに有し、
   登録機能部は、
   前記サービスサイト一覧情報を取得し、当該サービスサイト一覧情報をもとに、前記登録済み端末の秘密鍵を用いて登録対象のサービスサイトへＦＩＤＯ認証するステップと、
   前記新規端末で新規に生成した暗号鍵のRegistrationを行うステップと、
   を実行する端末登録方法。

Images