JP2015519777A - マルチパーティシステムにおける安全な認証 - Google Patents

Abstract

ユーザデバイスは、ログイン要求を送信する。プロバイダサーバは、認証サーバからランダム数を受信し、かつ認証サーバへ他の情報を送信する。プロバイダサーバは、ランダム数をデバイスへ送信する。ランダム数は、第２のユーザデバイスへ転送され、第２のユーザデバイスは、これを認証サーバへ送信する。認証サーバは、第２のデバイスへプロバイダ認証ポリシ要件を送信し、かつさらに、他の情報を送信する。第２のデバイスは、ユーザ検証情報を認証サーバへ送信する。認証サーバは、送信された検証情報がサービスプロバイダの認証ポリシ要件に一致することを決定し、ユーザを認証するためにこの検証情報を、格納されたユーザの検証情報と比較する。第２のデバイスは、ユーザ認証情報で署名された、ランダム数および他の情報を含むメッセージを認証サーバへ送信する。認証サーバは、認証の通知および署名入りメッセージをプロバイダサーバへ送信する。【選択図】図３

Description

本発明は、認証に関する。より具体的には、本発明は、マルチパーティシステムにおけるマルチレベル認証を安全にしかつ単純化することに関する。

現時点で、インターネット認証は、パスワードに基づく認証を行っているが、パスワードおよびパスワードシステムは、不確かで、解明、想像が容易であり、かつ覆されやすい。パスワードの安全は、１）ユーザが自らのパスワードを記憶していること、および２）攻撃者がパスワードへアクセスしないこと、に依存している。インターネット上では、より安全なパスワードは記憶しにくいという理由で、「１２３４５」のようなありふれたパスワードがかなりの比率のユーザによって使用されている。他に、システムの安全性を高めるために試行されている解決手段には、ワンタイムパスワード（ＯＴＰ）が含まれるが、これは、帯域外方法（典型的には、トークン発生器が発送される前に、ユーザがコードを打ち込む、またはセットアッププロセスが実行される）を用いて、時間ベースである一回限りのトークンを生成する。最近まで、ＯＴＰは、ハードウェアトークンによって生成されていて、ユーザへ供給するには高価であった。最近の改善によって、ＯＴＰは、モバイルデバイス上で、ユーザが幾つかのシード数を記入することにより初期化されるソフトウェアアプリケーションとして配信されることが可能になっている。ＯＴＰは、推測可能なパスワードおよびブルート・フォース・アタックに対する防護を提供しているが、それでもなお、ウィンドウ内での再使用および盗用といった幾つかの攻撃を受けやすい（シードマテリアルが盗まれれば、誰でもＯＴＰを生成することができる）。他の、より強力な安全オプションは、「秘密」データ（即ち、秘密鍵）がユーザ制御を絶対に外れないことから恩恵が多大である公開／秘密鍵に依存する公開鍵インフラ（ＰＫＩ）であるが、ＰＫＩシステムは、典型的には、極めて複雑であって実施が困難であり、よって、巨大組織でしか使用されず、かつ鍵の無効化、各ユーザの設定、および期限切れ他になった場合の鍵の管理、といった多くのオーバーヘッド問題を引き起こす。

認証の安全性を高めることに加えて、より優れた認証システムは、ユーザにとって容易なものであるべきである。追加の安全質問の使用、より長いパスワードの作成、他による、ＯＴＰ、ＰＫＩのようなありふれた安全強化は、ユーザ側をより複雑にする。ユーザは、詐欺行為を防止するための自身の認証データの管理も任されながらもシステムを単純に使用することができ、かつユーザ自身の選好に基づいて異なる認証強度を選択することができることが理想的である。スマートフォンおよび他のユーザデバイスの性能は拡大し、今では、セッション／認証データをチャネル間で、例えばブラウザとスマートフォンとの間で転送することが可能である。これにより、安全な認証をより強化することができるようになる。

本発明の所定の態様によれば、複数の異なるユーザは何れも、複数の異なるネットワーク・サービス・プロバイダの何れに対しても、例えばインターネットであるネットワークを介して認証されることが可能である。

システムは、Ｑサーバと称されることもある認証サーバを含み、かつサーバクラスタの形式である可能性もある。認証サーバは、例えば銀行、ブローカー、商業者、他である複数の異なるサービスプロバイダの各々のプロバイダ識別子を、該当するサービスプロバイダのプロバイダ認証ポリシ要件に関連づけて格納するために、例えばソフトウェアでプログラムされる論理によって構成される。プロバイダ認証ポリシ要件は、ユーザを認証するために１つまたは複数のファクタが使用され、この場合の第１のファクタは認証情報であり、かつ他のファクタは検証情報であることを要求してもよい。任意のファクタには、例えば、パスワード、誕生日等の他の知識ベースデータ、トークンおよび／または生体データが含まれてもよい。認証サーバは、アプリケーションユーザの検証情報に関連づけて、複数の異なるユーザの各々の１つまたは複数のユーザ識別子も格納する。

パーソナル、ラップトップまたはタブレットコンピュータ、またはスマートフォン等のスマートモバイル通信デバイス等の第１のデバイスは、複数の異なるユーザのうちの第１のユーザにより操作可能であって、ネットワークを介して複数の異なるサービスプロバイダのうちの第１のサービスプロバイダへログイン要求を送信するための論理で構成される。第１のサービスプロバイダに関連づけられるネットワークサーバは、ログイン要求を受信し、かつネットワークを介して認証サーバへランダム数要求を送信しかつ場合により、他のランダム数である可能性もありかつ活性ｉｄとして特徴づけられることもある他の情報を送信するための論理で構成される。認証サーバは、さらに、送信されたランダム数要求に応答して、ランダム数を、ネットワークを介してネットワークサーバへ送信するように構成される。ネットワークサーバは、さらに、送信されたログイン要求に応答して、認証サーバから受信されたランダム数を、ネットワークを介して第１のデバイスへさらに送信するように構成される。効果的には、ランダム数は、セッション識別子として機能することが可能である。

第１のデバイスと同じデバイスであってもよく、異なるデバイスであってもよい第２のデバイスは、第１のユーザによって操作され、かつ第１のデバイスにより受信されたランダム数であって、前記さらに送信されたランダム数（即ち、ネットワークサーバにより第１のデバイスへ送信されたランダム数）を第２のデバイスへ転送する入力を受信するように構成される。実施態様によっては、第１のデバイスは、効果的には、前記さらに送信されたランダム数、即ちネットワークサーバにより第１のデバイスへ送信されたランダム数、を視覚的に表示するようにさらに構成されてもよい。このような場合、前記さらに送信されたランダム数は、光学コードの形式であることが特に効果的であり得る。そうであれば、第２のデバイスは、効果的にはカメラを含み、かつ受信される入力であって、前記さらに送信されたランダム数を転送する入力は、カメラを介して、提示された光学コードのデジタル画像として受信されることが可能である。あるいは、実施態様によっては、第１のデバイスは、さらに、ネットワークサーバから受信されるランダム数であって、前記さらに送信されたランダム数を印刷するように構成されることが特に効果的である場合がある。そうであれば、第２のデバイスは、効果的にはカメラを含み、かつ受信される入力であって、前記さらに送信されたランダム数の入力は、カメラを介して、印刷されたランダム数のデジタル画像として受信されることが可能である。さらに他の実施態様において、ランダム数は、他の方法を介して、例えばオーディオコードまたは近距離無線通信によって、さらに転送されてもよい。ある代替的な実施態様において、ランダム数は、認証サーバによって生成され、かつ例えばログインまたは登録を開始するために、認証サーバから第２のユーザデバイスへ直に送信されることが可能である。このような場合、第１のデバイスから第２のデバイスへランダム数を転送する必要はない。

また、第２のデバイスは、ネットワークを介して認証サーバへ、入力されたランダム数および第１のユーザからの認証要求を送信するようにも構成される。即ち、ランダム数は、認証サーバからネットワークサーバ、第１のユーザデバイスへ送信され、次いで第２のユーザデバイスへ入力されて認証サーバへ送信し返される。第２のユーザデバイスは、好ましくは、Ｑａｐｐと称されることもあるアプリケーションを用いる必要な論理によって構成される。

第２のデバイスによるランダム数および認証要求のこの送信および受信の後、認証サーバは、さらに、ネットワークを介して第２のデバイスへ、格納された第１のプロバイダの識別子、場合によりもともとネットワークサーバにより認証サーバへ送信された他の情報、および格納されかつ関連づけられた第１のプロバイダの認証ポリシ要件を送信するように構成される。第２のデバイスは、さらに、送信された第１のプロバイダの認証ポリシ要件に応答して、第１のユーザの識別子およびユーザが入力した検証情報を送信するように構成される。送信された検証情報が、送信された第１のプロバイダの認証ポリシ要件の受信前、または受信後に、ユーザによって第２のデバイスへ入力され得ることは認識されるであろう。受信前であれば、第２のデバイスは、典型的には、入力された検証情報を格納し、次にこれを、必要に応じて、認証サーバから受信される該当プロバイダ認証要件に基づいて検索する。

認証サーバは、さらに、送信された第１のユーザの識別子を格納された第１のユーザの識別子と照合し、かつ送信された検証情報が格納された第１のサービスプロバイダの認証ポリシ要件に一致することを決定するように構成される。例えば、ポリシ要件が声紋を要求しているにも関わらず指紋が提供される場合、一致は存在せず、よって、送信された検証情報は格納されたポリシ要件に一致しない、という決定が下される。同様に、ポリシ要件はパスワードおよびトークンを要求しているが、パスワードしか提供されなければ、一致は存在しない。認証サーバは、第１のユーザを認証するために、送信された検証情報を、先に、例えば第１のユーザの登録中に認証サーバへ提供されて第１のユーザの識別子に関連づけて格納されている検証情報と比較する。例えば、認証サーバは、第１のユーザを認証するために、送信されたパスワードおよびデジタル写真を、第１のユーザの識別子に関連づけて格納されているパスワードおよびデジタル写真と比較する場合もある。

第２のデバイスは、さらに、ネットワークを介して認証サーバへ、ネットワークサーバと共有される第１のユーザの認証情報で署名され、（第１のユーザデバイスにより受信されて第２のユーザデバイスへ入力された）ランダム数および（認証サーバから受信された）前記さらに送信された他の情報を含むメッセージを送信するように構成される。認証サーバは、さらに、ネットワークを介してネットワークサーバへ、第１のユーザの認証の通知を送信し、かつさらに第２のデバイスによって先に送信された署名入りメッセージを送信するように構成される。認証情報が認証サーバとも共有されれば、認証サーバは、次に、第２のデバイスによって送信された署名入りメッセージへ認証情報を適用してランダム数および他の情報を検査し、かつこれにより、さらに第１のユーザを認証することができる。

第１のユーザの認証情報は、最も典型的には、複数の異なるサービスプロバイダのうちの第１のプロバイダのみに関連づけられて他のサービスプロバイダには関連づけられない第１のユーザの認証情報であることは理解されるべきであるが、これは、必ずしも必須ではない。実施態様によっては、第２のデバイスは、さらに、ネットワークを介して認証サーバへ第１のユーザの認証情報を送信するように構成されることが有利となる。このような場合、認証サーバは、さらに、送信された第１のユーザの認証情報を第１のユーザの識別子に関連づけて格納するように、かつ第１のユーザをさらに認証するために、第２のデバイスから受信した、送信された署名入りメッセージにおけるランダム数および他の情報を、格納されている第１のユーザの認証情報を受信された署名入りメッセージへ適用することによって、検査するように構成される。さらに、ユーザ認証情報が公開／秘密鍵ベースであって認証サーバと共有される場合、認証サーバは、各ネットワークエンティティが署名および証書を、暗号化された通信がネットワークサーバまで流れる前に検証することを手助けすることもできる。これにより、認証サーバは、正規のユーザおよびプロバイダのみが通信できかつ保証する通信が端から端まで暗号化されることを保証する中間ＰＫＩ管理ポータルとして行動することができる。

効果的には、署名入りメッセージの内容を検証するために使用される格納された第１のユーザの認証情報は、第１のユーザの秘密／公開鍵ペアのうちの公開鍵である。そうであれば、第１のユーザの秘密／公開鍵ペアのうちの秘密鍵は、好ましくは第１のユーザにのみ知られ、かつ送信される署名入りメッセージは、秘密鍵で署名される。このような場合、認証サーバは、ネットワークを介してネットワークサーバへ、認証の通知および受信された署名入りメッセージと共に証書を送信する。証書は、第１のユーザの公開鍵を含み、かつ認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名される。好ましくは、第１のユーザの秘密／公開鍵ペアは、複数のサービスプロバイダのうちの第１のプロバイダのみに関連づけられかつ他のプロバイダには関連づけられない秘密／公開鍵ペアである。

少なくとも幾つかの実施態様においては、認証サーバに、第２のユーザデバイス上に格納された認証情報の安全性において１つの役割を果たさせることが望ましい場合がある。このような実施態様において、第２のデバイスは、さらに、第１のユーザの秘密データを生成し、秘密データを複数の部分に分割し、第１のユーザの認証情報を秘密データで暗号化し、暗号化された認証情報を格納し、かつ複数の秘密データ部分のうちの第１の部分を、ネットワークを介して認証サーバへ送信するように構成される。認証サーバは、さらに、送信された第１の秘密データ部分を格納し、かつ検証情報に基づいて第１のユーザを認証した後に、格納された第１の秘密データ部分を、ネットワークを介して第２のデバイスへ送信するように構成される。第２のデバイスは、さらに、認証サーバによって送信された第１の秘密データ部分を他の秘密データ部分と結合して秘密データ全体を取得し、かつ取得された秘密データで、格納されている暗号化された認証情報を復号するように構成される。このような場合、署名入りメッセージは、復号された認証情報で署名される。

第１のユーザの認証情報が認証サーバによって格納されるか否かに関わらず、大部分ではなくとも多くの実施態様において、認証サーバは、さらに、第１のユーザの認証情報が危険に曝されているという通知を受信して受け付け、かつこの通知の受信に応答して、第１のユーザの認証情報を無効にするように構成されることが好ましい。例えば、第１のユーザの認証情報は、盗まれた、またはハッキングされたという理由で、または第２のユーザデバイスが紛失または盗まれたという理由で危険に曝される可能性もある。認証サーバは、格納されている認証情報を削除する、またはフラグ付けすること、またはユーザ識別子を、その識別子に関連づけられる格納されていない認証情報は無効であるという表記とともにフラグ付けすることによって、認証情報を無効にしてもよい。

認証情報が危険に曝されているとして報告されかつ無効にされた後、第１のデバイスは、ネットワークを介して第１のサービスプロバイダへ他のログイン要求を送信し続けてもよい。このような場合、ネットワークサーバは、ネットワークを介して認証サーバへ、他のランダム数（以下、本セクションにおいて第２のランダム数と称する）を求める他の要求を送信し、かつさらに他の情報（以下、本セクションにおいて第２の他の情報と称する）も送信する。認証サーバは、送信された要求に応答して第２のランダム数を、ネットワークを介してネットワークサーバへ送信し、かつネットワークサーバは、さらに、送信された他のログイン要求に応答して、認証サーバによって先に送信された第２のランダム数を、ネットワークを介して第１のユーザデバイスへ送信する。

第２のデバイス、または第２のデバイスが盗まれていれば代替品である第２のデバイスは、ネットワークサーバにより第１のユーザデバイスへ先にさらに送信されていた第２のランダム数を、今回は第２のデバイスへ転送する入力を、再度受信し、かつ入力された第２のランダム数および第１のユーザの他の認証要求を、ネットワークを介して認証サーバへ送信する。この送信の後、認証サーバは、再度、格納されている第１のプロバイダ識別子、場合によりネットワークサーバにより自身に送信された第２の他の情報、および格納されかつ関連づけられている第１のプロバイダの認証ポリシ要件を、ネットワークを介して第２の、または代替デバイスへ送信する。再度送信された第１のプロバイダの認証ポリシ要件に応答して、第２の、または代替デバイスは、再度、第１のユーザの識別子およびユーザが入力した検証情報を送信する。認証サーバは、再度送信された第１のユーザの識別子を格納された第１のユーザの識別子と照合し、再度送信された検証情報が、格納された第１のサービスプロバイダの認証ポリシ要件に一致することを決定し、かつ第１のユーザを認証するために、再度送信された検証情報を第１のユーザの識別子に関連づけて格納されている検証情報と比較する。しかしながら、認証サーバが危険に曝されたユーザ認証情報を無効にするように構成される実施態様では、認証サーバは、ここで、格納されている第１のユーザの認証情報が無効であると決定するようにも構成される。認証サーバは、さらに、格納されている第１のユーザの認証情報が無効であると決定した後、ネットワークを介して第１のサービスプロバイダへ、検証情報に基づく第１のユーザの認証の通知、および第１のユーザの認証情報の無効性の通知を送信するようにも構成される。

認証サーバは、効果的にはさらに、格納されている第１のユーザの認証情報が無効であると決定した後、ネットワークを介して第２の、または代替ユーザデバイスへ、代替認証情報要求を送信するように構成されてもよい。このような場合、第２の、または代替デバイスは、さらに、送信された要求に応答して代替認証情報を、ネットワークを介して認証サーバへ送信するように構成される。認証情報が公開／秘密鍵であれば、認証サーバは、さらに、受信された代替認証情報の証書を生成し、かつネットワークを介して第２のデバイスへ、生成された証書を第１のサービスプロバイダによる第１のユーザの登録に使用するために送信するように構成される。先に述べたように、認証サーバは、認証情報を格納するようにも構成されてもよく、この場合、認証サーバは、送信された代替認証情報を第１のユーザの識別子に関連づけて格納する。

第２の、または代替デバイスは、ネットワークを介して認証サーバへ、第１のユーザの代替認証情報で署名された、第２のランダム数および第２の他の情報を含む他のメッセージを送信することによって、ログインプロセスを継続する。認証サーバは、先に論じたような実施態様に依存して、格納されている第１のユーザの代替認証情報を、受信された他の署名入りメッセージへ適用することにより、第２のランダム数および第２の他の情報を検査して第１のユーザをさらに認証する場合もあれば、このような検査およびさらなる認証を実行しない場合もある。しかしながら、認証サーバがメッセージの内容を検査するか否かに関わらず、認証サーバは、典型的には、第１のユーザの認証通知および他の署名入りメッセージの双方を、ネットワークを介してネットワークサーバへ送信する。

また、ユーザは、複数の他のネットワークエンティティに対する認証に使用される単一の認証情報を有する場合もあれば、複数の他のネットワークエンティティのうちの各々に対する認証のための異なる認証情報を有する場合があることも理解されるべきである。異なる認証情報が使用されれば、第２のデバイスは、さらに、複数の認証情報、潜在的には各プロバイダにおけるアカウント毎に１つの認証情報を格納するように、かつ特有のアカウントまたはプロバイダサービスへアクセスする際に適正な認証情報を用いるように実行される。

このような場合、第１のデバイスは、他のログイン要求を、ネットワークを介して第２のサービスプロバイダへ送信する。複数の異なるサービスプロバイダのうちの第２のサービスプロバイダに関連づけられる他のネットワークサーバは、ネットワークを介して認証サーバへ、他のランダム数（以下、本セクションにおいて第３のランダム数と称する）の要求を送信し、かつさらに他の情報（以下、本セクションにおいて第３の他の情報と称する）も送信するように構成される。認証サーバは、送信されたランダム数要求に応答して第３のランダム数を、ネットワークを介して他のネットワークサーバへ送信する。他のネットワークサーバは、さらに、送信された他のログイン要求に応答して、送信された第３のランダム数を、ネットワークを介して第１のデバイスへ送信する。

第２のデバイスは、さらに送信された第３のランダム数、即ち他のネットワークデバイスによって第１のユーザデバイスへ送信された第３のランダム数、を第２のデバイスへ転送する入力を受信し、かつ入力された第３のランダム数、場合により他のネットワークサーバによって送信された第３の他の情報、および第１のユーザの他の認証要求を、ネットワークを介して認証サーバへ送信する。この後、認証サーバは、格納されている第２のプロバイダ識別子、および格納されてかつ関連づけられた第２のプロバイダの認証ポリシ要件を、ネットワークを介して第２のデバイスへ送信する。

第２のデバイスは、送信された第２のプロバイダの認証ポリシ要件に応答して、第１のユーザの他の識別子、およびユーザが入力した他の検証情報を、ネットワークを介して認証サーバへ送信する。先に述べたように、プロバイダ認証ポリシ要件は、認証のために、パスワード、他の知識ベースデータ、トークンおよび／または生体データ等の１つまたは複数のファクタを要求する。認証サーバは、送信された第１のユーザの他の識別子を格納されている第１のユーザの他の識別子と照合し、もしあれば送信された他の検証情報が、格納されている第２のサービスプロバイダの認証ポリシ要件に一致することを決定する。認証サーバは、第１のユーザを認証するために、もしあれば送信された他の検証情報と、もしあれば第１のユーザの他の識別子に関連づけて格納されている検証情報との比較も行う。

第２のデバイスは、第１のユーザの他の認証情報で署名された他のメッセージであって、送信された第３のランダム数およびさらに送信された第３の他の情報、即ち認証サーバによって第２のデバイスへ送信された第３の他の情報、を含む他のメッセージを、ネットワークを介して認証サーバへ送信する。認証サーバは、次に、ネットワークを介して他のネットワークサーバへ、第１のユーザの認証の他の通知を送信し、かつさらに、受信された他の署名入りメッセージを送信する。

全てではないとしても幾つかの実施態様においては、ユーザがユーザ独自の認証ポリシ要件を確立できることも、それが該当プロバイダのそれに劣らず厳しいものである限り、また、好ましい場合がある。このような実施態様においては、かつ、先に述べた第１のユーザによる第１のサービスプロバイダへのログインから再度判断すると、第２のデバイスは、さらに、第１のユーザの認証ポリシ要件を、ネットワークを介して認証サーバへ送信するように構成される。

認証サーバは、さらに、送信された第１のユーザの認証ポリシ要件を格納し、格納されている第１のプロバイダの認証ポリシ要件を、格納された第１のユーザの認証ポリシ要件と比較し、かつこの比較に基づいて、任意の追加的な認証ポリシ要件を決定するように構成される。また認証サーバは、さらに、決定された任意の追加的な認証ポリシ要件を、ネットワークを介して第２のデバイスへ、第１のプロバイダの認証ポリシ要件と共に送信するようにも構成される。また認証サーバは、さらに、第２のデバイスにより送信された検証情報が、決定された任意の追加的な認証ポリシ要件に一致することを決定するようにも構成される。したがって、第１のユーザの第１のプロバイダへのログインにおいて、認証サーバがこのように構成されていれば、受信された検証情報は、任意の追加的な認証ポリシ要件に一致する検証情報を含むことになり、これもまた、第１のユーザを第１のプロバイダに対して認証するために、格納されている検証情報と比較される。

所定の実施態様においては、トランザクション承認を準備することが有益である場合がある。このような実施態様では、ネットワークサーバは、さらに、ネットワークを介して認証サーバへ、第１のサービスプロバイダの識別子、トランザクション識別子、認証要件およびトランザクションに関するメッセージを送信するように構成される。メッセージは、認証情報を用いて、例えば第１のユーザの秘密／公開鍵ペアのうちの公開鍵を用いて暗号化される。先に述べたように、第１のユーザの秘密／公開鍵ペアのうちの秘密鍵は、第１のユーザにのみ知られる。メッセージは、第１のサービスプロバイダの秘密／公開鍵ペアのうちの秘密鍵で署名もされる。第１のサービスプロバイダの秘密／公開鍵ペアのうちの公開鍵は、第１のユーザに知られている。

認証サーバは、さらに、ネットワークを介して第２のデバイスへ、送信されたトランザクション識別子、トランザクション承認、および認証情報および検証情報要件等の認証要件、および暗号化された署名入りメッセージをさらに送信するように構成される。これに応答して、第２のデバイスは、さらに、トランザクション承認、および送信された認証要件を満たすことが要求される場合には検証情報、を、ネットワークを介して認証サーバへ送信するように構成される。

認証サーバは、さらに、受信されたトランザクション承認および任意の受信された認証情報に基づいて、識別されたトランザクションが第１のユーザによって承認されること、かつ要求されれば、例えば検証情報に基づいて第１のユーザが真正であることを決定するように構成される。また認証サーバは、さらに、この決定の通知を、ネットワークを介してネットワークサーバ、または第１のデバイスへ、もしくは双方へ送信するようにも構成される。

実施態様によっては、認証サーバは、プロバイダによるユーザの登録に関与することが望ましい場合がある。このような実施態様においては、認証サーバは、さらに、複数の異なるサービスプロバイダの各々のプロバイダ識別子を、該当するサービスプロバイダのプロバイダ・登録データ要件に関連づけて格納するように構成される。

第２のデバイスは、さらに、ユーザが入力したユーザ識別セット、ユーザが入力した登録データ、および受信された識別セットにおける個々の識別に関連づけられるべき入力された登録データのうちでユーザが選択した特定のデータ、を受信するように構成される。また第２のデバイスは、さらに、個々の識別を、その識別に関連づけられるべく選択された特定の登録データに関連づけて格納するようにも構成される。

第１のデバイスは、さらに、ネットワークを介して登録要求をネットワークサーバへ送信するように構成される。ネットワークサーバは、さらに、ネットワークを介して認証サーバへ、他のランダム数（以下、本セクションにおいて第４のランダム数と称する）の要求を送信するように構成される。認証サーバは、さらに、送信された他のランダム数の要求に応答して、第４のランダム数を、ネットワークを介してネットワークサーバへ送信するように構成される。

ネットワークサーバは、さらに、送信されたログイン要求に応答して、送信された第４のランダム数を、ネットワークを介して第１のデバイスへさらに送信するように構成される。第２のデバイスは、さらに送信された第４のランダム数、即ちネットワークサーバによって第１のユーザデバイスへ送信された第４のランダム数、を第２のデバイスへ転送する入力を受信するようにさらに構成される。また第２のデバイスは、さらに、入力された第４のランダム数、および第１のサービスプロバイダによって登録されるべき第１のユーザの要求を、ネットワークを介して認証サーバへ送信するようにも構成される。これに応答して、認証サーバは、さらに、格納されている第１のプロバイダ識別子、および格納されてかつ関連づけられた第１のプロバイダの登録データ要件を、ネットワークを介して第２のデバイスへ送信するように構成される。

第２のデバイスは、場合により、さらに、格納されているユーザ識別のうちの１つを選択するユーザ入力を受信し、かつ選択されて入力された識別の受信に応答して、選択されたユーザ識別に関連づけて格納されている特定の登録データを自動的に検索するように構成される。その他、第２のデバイスは、第１のプロバイダが用いるべきユーザ識別のユーザ入力、および必要な登録データを受信するように構成される。また第２のデバイスは、さらに、検索された、または入力された登録データを、ネットワークを介して認証サーバへ送信するようにも構成される。認証サーバは、さらに、送信された登録データが、格納されている第１のサービスプロバイダの登録データ要件に一致することを決定するように、かつ第１のサービスプロバイダによって第１のユーザを登録するために、送信された登録データを、ネットワークを介してネットワークサーバへさらに送信するように構成される。

第２のデバイスは、さらに、第１のプロバイダによって使用されるべき新しい認証情報を、認証サーバを介してネットワークサーバへ送信するように構成される。送信される認証情報がユーザの秘密／公開鍵ペアのうちの公開鍵であるような事例では、第２のデバイスは、認証サーバへ証書要求も送信する。これに応答して、認証サーバは、認証サーバの秘密／公開鍵ペアのうちの秘密鍵でユーザの公開鍵に署名することにより、証書を生成する。認証サーバは、次に、証書を第２のデバイスへ送信する。ユーザの秘密／公開鍵ペアのうちの秘密鍵は、ユーザにのみ知られること、および認証サーバの秘密／公開鍵ペアのうちの公開鍵は、ユーザおよび第１のプロバイダの双方に知られることは、認識されるであろう。

所定の実施態様において、認証サーバは、プロバイダ認証情報の証書権限保有機関として行動することが望ましい場合がある。このような実施態様において、ネットワークサーバは、さらに、登録要求および第１のサービスプロバイダの秘密／公開鍵ペアのうちの公開鍵を、ネットワークを介して認証サーバへ送信するように構成される。第１のサービスプロバイダの秘密／公開鍵ペアのうちの秘密鍵は、ネットワークサーバにのみ知られる。認証サーバは、さらに、送信された第１のプロバイダの公開鍵を格納し、かつ認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された、第１のプロバイダの公開鍵を含む証書を、ネットワークを介してネットワークサーバへ送信するように構成される。認証サーバの秘密／公開鍵ペアのうちの公開鍵は、ネットワークサーバに知られている。

認証サーバが証書権限保有機関として行動する実施態様において、または他の所定の実施態様において、認証サーバは、ユーザ認証情報の証書権限保有機関として行動することが望ましい場合がある。これらの実施態様において、第２のデバイスは、さらに、登録要求および第１のユーザの秘密／公開鍵ペアのうちの公開鍵を、ネットワークを介して認証サーバへ送信するように構成される。第１のユーザの秘密／公開鍵ペアのうちの秘密鍵は、第２のデバイスにのみ知られる。認証サーバは、さらに、送信された第１のユーザの公開鍵を格納し、かつ認証サーバの秘密鍵で署名された、第１のユーザの公開鍵を含む証書を、ネットワークを介して第２のデバイスへ送信するように構成される。認証サーバの秘密／公開鍵ペアのうちの公開鍵は、第２のデバイスに知られている。

本発明の上述の態様が、ハードディスク、コンパクトディスクまたは他のタイプのディスク、またはメモリ等の非一時的記憶媒体上に格納される、プログラムされたアプリケーションまたはａｐｐ等の例えばソフトウェア形式である論理であって、プロセッサによって読取り可能であるように構成され、故に上述の機能および／または動作を実行するようにプロセッサを動作させる論理を用いて実施され得ることは理解されるべきである。また、本発明の上述の態様は、上述の機能および／または動作を実行するための論理を伴って構成されるプロセッサと、プロセッサの指令通りにデータを格納するように構成される、例えばディスクまたはメモリであるデータストアとを有する、クラスタ内に複数のサーバを含むネットワークサーバ上、または適宜スマート通信デバイス上で実施され得ることも理解されるべきである。

当業者には、以後の詳細な説明を含む本開示から、ならびに本発明の実施によって、本発明のさらなる目的、優利な点および新規特徴が明らかとなるであろう。以下、本発明の説明を、特定の実施形態を参照して行うが、本発明がこれらの実施形態に限定されないことは理解されるべきである。本明細書に記載される教示内容へアクセスする一般的な当業者には、追加的な実施、変更および具現化、ならびに他の利用分野が認識されるであろうが、これらは、本明細書において開示されかつ請求の範囲に記載された本発明の範囲に含まれ、かつ本発明は、これらに関して重要な効用を有する。

これらの図面は各々、描写しているシステムの実施形態例を表している。
図１は、主要なアーキテクチャ構成部品を例示する。 図２は、ログイン画面の一例を例示する。 図３は、ユーザ（ブラウザおよび携帯電話の双方）と、認証サーバと、ネットワークプロバイダとの間の通信を例示する。 図４は、モバイル・ユーザ・デバイス上の主要サブシステムを例示する。 図５は、認証サーバ上の主要サブシステムを例示する。 図６は、分割鍵システムおよびハイレベル・データ・フローを例示する。 図７は、ユーザと、認証サーバと、プロバイダとの間の相互作用の例を例示する。 図８は、システム内の様々なデータのためのデータ制御エリアを例示する。 図９は、ユーザ（ブラウザおよび携帯電話の双方）と、認証サーバと、ネットワークプロバイダとの間の通信を例示する。 図１０は、紙ベースの登録プロセスの例を例示する。 図１１は、通知システムの通信フローの例を例示する。

概観
第１の認証フレームワーク
本発明の態様によれば、ネットワーク接続を有するユーザのモバイルデバイス、例えばスマートフォン４００またはタブレットと、様々な暗号および認証オペレーション１０１を実行することができるソフトウェアアプリケーションとを含む認証フレームワーク、図１参照、が提供される。また、ウェブサイトまたは端末サーバのようなネットワークサービス１０３も含まれる。アクセスソフトウェアは、ウェブブラウザ１０２のようなネットワークサービスに繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。アクセスソフトウェアは、ユーザにより提供される認証情報が、現在のネットワークサービスに関するものであることを検証するための情報を含む安全データを、ユーザのモバイルデバイスへ確実に送信できる信用のある構成部品を有してもよい。アクセスソフトウェアの信用のある構成部品は、ブラウザプラグインであってもよい。信用のある構成部品により提供される安全情報には、ネットワークサーバのアドレスまたはＵＲＬ（ウェブサービスの場合）がさらに含まれてもよい。認証サーバ１００は、ネットワークへ取り付けられ、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによる到達が可能である。

アクセスソフトウェアとモバイルデバイスのソフトウェアとの間の、走査されるＱＲコードまたは近距離無線通信システムのような第１の転送接続部１０６は、認証セッション識別子（ＩＤ）を転送するために使用され、かつセッションを起動するための追加情報を含んでもよい。第１の転送接続部は、同じネットワークサービスへ接続しているアクセスソフトウェアとモバイル・ソフトウェア・アプリケーションとの間の検証を可能にするより完全な通信チャネル（例えば、ブルートゥース、近距離無線、ＵＳＢ接続、他）によって増強されてもよい。第１の転送接続部上で受信されるセッションＩＤは、ＱＲコードの光学ディスプレイを介して転送されてもよい。その場合、セッションＩＤの評価は、ＱＲコードをカメラで読み取ることと、ＱＲコードを復号することを含んでもよい。

モバイル・デバイス・ソフトウェアと認証サーバとの間の第２の転送接続部１０７は、セッションの活性に関する安全チェックの転送を実行し、かつユーザの認証情報およびネットワークサービスをチェックする。認証サーバは、詐欺行為および異常検出システム５０４を含んでもよい。ユーザの認証情報は、公開／秘密鍵システムを用いる非対称公開鍵暗号化に基づくものであってもよく、ユーザの認証情報は、アクセスされるネットワークサービスに固有のものであってもよい。

認証の間に公開／秘密鍵システムが使用される場合、これは、認証サーバとネットワークサービスとの間の認証、および認証サーバとユーザ・モバイル・ソフトウェアとの間の認証を可能にする通信鍵／証書セットを含んでもよい。また、これは、ユーザとネットワークサービスとの間の認証を可能にするユーザ検証鍵／証書セットも含んでもよい。また、ユーザ検証鍵セットは、ユーザ間の検証鍵、および複数のサービスを通じて用いるための単一の鍵／証書、またはユーザ−サービスペア毎の固有の鍵、も含んでもよい。

さらに、認証サーバは、認証データを検証しかつ期限切れ、紛失その他無効の証書に対処するプロセスを決定するために使用されることも可能である。また、認証サーバは、詐欺行為検出および監査を実行してもよい。最後に、認証サーバにより、１つまたは複数の証書署名権限保有機関が包含され、かつ証書を承認するために使用されることも可能である。好ましくは、証書署名権限保有機関は３つ、即ち、ネットワークサービスの認証情報のためと、ネットワークサービスに対するユーザの認証情報のためと、認証サーバに対するユーザの認証情報のため、の３つが使用される。紛失した認証情報に対処するプロセスには、紛失した認証情報を無効化することが含まれてもよい。

安全チェックは、さらに、生体データ、トークンベースの認証データまたは知識ベースの追加的ファクタ等の追加の認証ファクタを含んでもよい。生体データがこれらのファクタのうちの１つであれば、これは、デバイス上のカメラを用いる手認識、ユーザ・モバイル・デバイスへ取り付けられたデバイスから収集される生体データ、ＵＳＢ指紋スキャナを用いる指紋認識を含むことも可能である。使用される追加的な認証ファクタは、パスワードおよび／または個人識別番号（ＰＩＮ）等の知識ベースの質問、または事前登録の電話番号のような検査可能な特性を含むことも可能である。使用される追加的な認証ファクタは、取り付けられたカードリーダで読み取られるスマートカード、近距離無線を介してアクセスされる安全なデータトークン、および／またはモバイルデバイスのＳＩＭカードから読み取られるデータ等の、モバイルデバイス上のトークン、またはモバイルデバイスへ取り付けられたトークンの何れかを含むことも可能である。

アクセスソフトウェアへの第３の転送接続部は、ユーザ認証が完了した時点をアクセスソフトウェアが認識できるようにし、よってアクセスソフトウェアと、認証サービス１０５またはネットワークサービス１０８の何れかとの間に存在してもよい。アクセスソフトウェアは、認証が完了すると、ログイン状態へ自動的に移動してもよい。
第２の認証フレームワーク

この認証フレームワークは、ネットワークを通じた様々なサービスと、これらのサービスのユーザとを含み、これらは、ユーザによる通信を可能にする様々な認証情報を有する。ユーザは、人ではなく、自動化されたプロセスである可能性もある。また、どのユーザサービス認証情報が有効であるか、紛失しているか、または期限切れであるかを示す、かつログインが許可されるかどうかの決定に使用可能な認証データも含まれる。関係者間の通信用に提供されるシステムは、伝統的なネットワークプロトコル、プロキシまたはリバースプロキシを含んでもよい。

また、１つまたは複数の階層的認証サーバも提供され、この階層的認証サーバの最上層は、個々の認証要求を、認証されるサービスに基づいて下位のレベルまたは層へリダイレクトすることができる。各認証サーバは、認証データを用いて、ユーザ認証情報がまだ有効かどうかに関する決定を下すことができる。階層的認証サーバは、認証要求を１つのサーバまたはサーバクラスタが処理する単一レベルのサーバであってもよい。下位層のサーバは、所望されれば、ファイアウォールまたは周辺ネットワークゲートウェイの背後に存在し、かつローカルまたは組織内ネットワーク上のサービスを扱うことも可能である。ログインは、例えば、認証情報が紛失としてマーキングされていて、もはや有効でない、という理由で拒絶されてもよい。
第３の認証フレームワーク

この認証フレームワークは、ウェブサイトまたは端末サーバのように、ネットワークへ接続される認証サーバと、到達可能なネットワークサービスとを含む。また、認証サーバ上にはユーザ認証情報セットも含まれ、その幾つかは、例えばユーザ認証情報が存在するデバイスは紛失している、という理由で無効とマーキングされてもよい。

アクセスソフトウェアは、ネットワークサービスへ到達するために使用される。ネットワークサーバと認証サーバとの間の通信システムは、ネットワークサービスに、ユーザは有効であるが、個々の認証情報は無効であるか、存在しないことを告げる。通信システムは、認証サーバから返されるＡＰＩオブジェクト内のメソッドクエリであっても、認証情報の有効性を返すカスタムプロトコルであってもよい。

追加的検証のためにアクセスソフトウェアを登録またはアラートページへリダイレクトする際には、簡易方法が実施される。簡易リダイレクト方法は、登録ページへのウェブ・リダイレクト・メッセージであっても、登録を目的としてカスタムアプリケーションを開始するためのアンドロイドのようなアプリケーション間通信であってもよい。ユーザは、サイト上で登録する、またはサイト上で登録し直す必要があるという理由でリダイレクトされてもよく、この場合、ユーザの登録情報は、ユーザにより承認された予め設定されている識別情報で記載されることも可能である。図８を参照されたい。ユーザ識別情報は、ユーザ・モバイル・デバイス８０６上、または認証サーバ上に格納されてもよい。識別情報は、ユーザが複数の識別（業務用、個人用、他）を有してこれらから選択できるようにする識別セットに予めグルーピングされてもよい。
データ機密保護システム

また、暗号化および復号化のための対称鍵を用いる暗号データ格納ロケーション（キーストアまたはデータストア）を含む、モバイルデバイス上のデータを保護するためのシステムも提供される。図６を参照されたい。ユーザが入力した秘密データは、６０１で複数の部分に分割され、ユーザが入力した秘密データの一部は、６０５で対称復号鍵の第１の部分を入手するために局所的に使用される。ユーザが入力する秘密データは、パスワードまたはパスフレーズ、生体テンプレートまたはマッチ、またはユーザが描く画像であってもよい。ネットワーク到達可能サーバは、６０４において、ユーザが入力した秘密データの第２の部分を用いて、復号のための対称鍵の第２の部分を検索する。例えば、パスワードの半分を用いて復号鍵の半分を含むデータのローカルブロックを復号すること等によって、パスワードのこの半分をシステム・レベル・データと結合して復号鍵の半分を入手してもよい。例えばログイン試行の失敗数を限定し得るネットワークサーバ上の詐欺行為検出ポリシ６０３は、復号鍵の第２の部分に対する不審な要求に警告を出し、またはこれに応答する。
認証サーバ

図７を参照すると、各ユーザについて、どのサービスに対して認証情報を有するか、アクセスするにはどのタイプの認証が必要か、および認証情報が有効かどうか、を明記するデータセットを含む認証サーバ７１３も提供される。サービス毎に、認証サーバ７１１を用いて最低限の安全ポリシが指定される。ポリシ管理ソフトウェア７００は、ユーザが、（ｉ）サービスの最低限の仕様に適合する限り、特定のサービスまたはサービスセットへのアクセスに必要な認証のタイプを修正し、（ｉｉ）その認証情報を削除し、または（ｉｖ）その他、そのユーザデータと相互作用すること、を目的として、その固有のレコードを更新できるようにする。ポリシ管理ソフトウェアは、ユーザのモバイルデバイス上またはユーザがアクセスするウェブサイト上に存在してもよい。修正は、新しい認証ファクタの追加（例えば、ログインにはＰＩＮだけでなく顔も必要であることを明示する）、またはファクタのより正確または限定的なものへの変更（例えば、手認識ではなく顔認識を用いる）を含む可能性もある。
第４の認証フレームワーク

本発明の態様によれば、認証フレームワークは、ネットワーク接続と様々な暗号および認証オペレーションを実行することができるソフトウェアアプリケーションとを含む、ユーザのモバイルデバイスを含む。また、ウェブサイトまたは端末サーバのようなネットワークサービスも含まれる。アクセスソフトウェアは、ウェブブラウザのようなネットワークサービスに繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。認証サーバは、ネットワークへ接続され、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによって到達可能である。所望されれば、認証サーバは、詐欺行為および異常検出システムを含むことが可能である。図９を参照されたい。識別子９０２は、ブラウザへ供給されて、モバイルデバイスのソフトウェアアプリケーションを一意に識別する。識別子は、電話番号またはユーザ名のようなユーザ毎の固有値であることも可能である。

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、セッションの活性の安全チェックと、ユーザおよびネットワークサービスの認証情報の転送とを実行する。ユーザの認証情報は、公開／秘密鍵システムを用いる非対称公開鍵暗号化に基づいてもよく、認証情報は、アクセスされているネットワークサービスに固有のものである可能性もある。安全チェックは、さらに、生体データ、トークンベースの認証データまたは追加的な知識ベースのファクタを含む、追加的な認証ファクタを含んでもよい。生体データは、ユーザのモバイルデバイスへ取り付けられるデバイスから収集されることも可能である。

アクセスソフトウェアへの第２の接続部は、認証が完了した時点をアクセスソフトウェアが認識できるようにする。第２の通信チャネルは、アクセスソフトウェアと認証サービスとの間であっても、アクセスソフトウェアとネットワークサービスとの間であってもよい。
第５の認証フレームワーク

この認証フレームワークは、ネットワーク接続と、様々な暗号および認証オペレーションを実行できるソフトウェアアプリケーションとを有する、ユーザのモバイルデバイスを含む。また、ウェブサイトまたは端末サーバのように、ネットワークサービスも含まれる。アクセスソフトウェアは、ウェブブラウザのようなネットワークサービスへ繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。認証サーバは、ネットワークへ接続され、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによって到達可能である。ブラウザセッションをモバイルデバイスのソフトウェアアプリケーションへ一意に結ぶための手段が提供される。これらの手段は、ブラウザから、ＱＲコードの光学ディスプレイを介する等、光学コードを介してソフトウェアアプリケーションへ伝達されてもよい。この伝達の処理は、ＱＲコードをカメラで読み取ること、およびＱＲコードを復号することを含むことも可能である。

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、安全チェック、ユーザの認証情報およびネットワークサービスの転送を実行し、かつ安全なメッセージングチャネルを提供する。安全なメッセージングチャネルは、（ｉ）ネットワークサービスからモバイルデバイスのソフトウェアアプリケーションへの一方向通信手段、または（ｉｉ）ネットワークサービスがモバイルデバイスのソフトウェアアプリケーションからの追加情報を問い合わせるための双方向通信手段であってもよい。安全なメッセージングチャネルは、暗号化されたメッセージデータ、承認要求またはポリシ情報のうちの１つまたはそれ以上を送信する能力を含む規定されたメッセージングプロトコルを有してもよい。

アクセスソフトウェアへの第２の接続部は、認証が完了した時点をアクセスソフトウェアが認識できるようにする。
認証登録システム

認証登録システムは、ネットワーク接続部と様々な暗号および認証オペレーションを実行できるソフトウェアアプリケーションとを有する、ユーザのモバイルデバイスを含む。図１０を参照されたい。また、登録セッションを一意に識別するためのコード１００８を含む、ネットワークサービス関連の個々のアカウントに関する印刷文書１０００も含まれる。認証サーバは、ネットワークへ接続され、よってモバイルデバイスのソフトウェアアプリケーションおよびネットワークサービスによって到達可能である。モバイルデバイスのソフトウェアアプリケーションに対して、登録セッションを一意に識別するための手段が含まれる。これらの手段は、印刷文書からソフトウェアアプリケーションへ、ＱＲコードを含む光学コードを介して伝達されてもよく、伝達の処理は、ＱＲコードをカメラで読み取ることと、ＱＲコードを復号することを含んでもよい。

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、安全チェックおよびユーザの認証の転送を実行する。ネットワークサービスへの第２の接続部は、登録が完了した時点をネットワークサービスが認識できるようにする。
（実施の形態）
マルチパーティ認証システム

マルチパーティ認証システムは、ネットワーク・サービス・プロバイダ１０３に対してユーザを検証するために、本質的に信用できない認証プロバイダ１００を用いる。システムは、様々なユーザ認証情報（例えば、公開／秘密鍵および証書）を保護しかつ保持する、モバイルタブレットまたはスマートフォン４００のような信用のあるユーザデバイスを包含し、かつ、生体ベース、知識ベース（即ち、パスワード）およびトークンベースを含む、可変数および可変タイプの認証情報を収集することができる。認証サービス１００は、ＷＡＮに渡るリアルタイムのスケーラブル認証を可能にするユーザ駆動の設定および制御を提供し、かつ紛失鍵の回復および簡易登録または再登録を可能にする。

次に、図に例示されている実施形態の説明を詳細に参照する。実施形態の説明は、図面および関連の説明を参照して行うが、発明の範囲を本明細書に開示される実施形態に限定する意図はない。逆に、参照の意図は、全ての代替案、変更および等価物を包含することにある。一般的な当業者には、本明細書に開示される実施形態に範囲を限定することなく、追加のデバイスを含む他の実施形態、または例示されたデバイスのコンビネーションが追加または組み合わせられ得ることが認識されるであろう。

本発明は、マルチパーティシステム（ユーザ、認証サービスプロバイダ１００およびネットワーク・サービス・プロバイダ１０３）を基礎とし、かつ下記の主要なアーキテクチャ構成部品を含む（図１から図５までのアーキテクチャ構成部品参照）：
・ネットワーク接続部４０２と、データ入力システム４０１と、様々な認証機能を実行できるようにするソフトウェア認証アプリケーションまたはａｐｐ（Ｑａｐｐ）１０１とを含むユーザ・モバイル・デバイス４００。Ｑａｐｐ１０１は、認証通信４０９を管理し、付加的な認証データ４０３および４０４を収集し、かつユーザ認証情報およびデータ４０５〜４０８を格納する。ユーザ・モバイル・デバイスは、スマートフォン、タブレットコンピュータ、ラップトップ、他を含む、任意のパーソナルデバイスであることが可能である。一実施形態は、セルラベースのネットワーキングおよびＷｉＦｉネットワーキングの双方を含むスマートフォンの使用である。モバイル・ユーザ・デバイスの第２の実施形態は、特殊化された認証デバイスである場合もある。理想的には、ユーザ・モバイル・デバイスには、生体データ４０４または追加的なトークンデータ４０３を収集するために使用されることが可能な（カメラ、マイク、他のような）追加センサ４０４も含まれる。
・ユーザがアクセスするためのログインを要求されているという情報を有する、ネットワーク・サービス・プロバイダ１０３（プロバイダ）。認証中のプロバイダの主たる役割は、ユーザを正しいプロバイダアカウントへマップすることである。場合により、プロバイダは、認証情報を再検査しかつ他の安全チェックを実行することができる。ある実施形態は、ユーザがそのアカウントに関する情報を得るためにログインできるようにする、ｅバンキング・ウェブサイトのようなウェブサイト１０３である。第２の実施形態は、（Ｗｉｎｄｏｗｓログイン画面のような）ネットワーク対応デスクトップログインである場合もある。
・ユーザのネットワークサービス・アクセス・ソフトウェア。これは、ユーザが通信チャネル１０８を介してログインするために相互作用するソフトウェアである。ウェブサイトの場合、アクセスソフトウェアは、ウェブブラウザ１０２であり、他のタイプのネットワークサービスは、特殊化されたアクセスポータルを有する場合もある。理想的には、これは、アクセスソフトウェアとモバイルデバイス上の認証アプリケーションとの間でデータセットを転送する能力を有するものと思われる。図２を参照されたい。ある実施形態は、２次元的バーコードシステムである視覚的ＱＲコード２００を示すことであり、他のオプションには、オーディオコード、近距離無線通信、他が含まれる。以後の説明では、第１のチャネル１０６（即ち、アクセスソフトウェア（即ち、ブラウザ）と認証アプリケーションとの間）における情報転送にＱＲコードの使用を想定している。少なくとも幾つかの実施において、ネットワークサービスは、一意のユーザＩＤを収集する能力を有するべきである。図９を参照されたい。実施の例は、ｉ）９０２において、ユーザがウェブサイト上のフィールドへデータを直接入力すること、ｉｉ）ＩＤがクッキーまたは他のブラウザ記憶ロケーションに格納されること、またはｉｉｉ）ユーザのモバイルデバイス（接続されたＵＳＢ、近距離場、他）との通信手段、を含む場合もあり、この場合、ユーザのモバイルデバイスは一意のユーザＩＤを提供する。
・様々なサービスを提供する認証サーバ１００（Ｑサーバ）。Ｑサーバは、５０１および５０５を含めて、ユーザおよびプロバイダの様々な認証情報が正しく設定されかつ使用されることを保証する中間ＰＫＩ管理ポータルとして行動し、生体ベースおよびトークンベースのオプションを含む追加的な認証形式５０２を処理し、紛失した電話の報告、またはポリシ調停システム５０３を介する認証のアップグレードを含めて、ユーザが自身の認証を管理することを可能にし、場合により、ユーザ識別を管理し、かつ認証要求および使用される認証データに関する詐欺行為検出５０４を行う。ある実施形態では、認証サーバは、ネットワーク接続デバイスが通信チャネル１０４、１０５および１０７を介して接続することを可能にしかつ５０６により管理される、様々な情報を要求または送信する単一のインターネット到達可能ホスト５００またはサーバクラスタである。第２の実施形態において、認証サーバは、認証に関する決定がサーバ間に流れることを可能にするサーバの階層より成ってもよい。この実施形態では、下位レベルのサーバは、認証サービスを、ファイアウォールまたは他のネットワークおよび安全境界背後の組織または企業ネットワークへ提供してもよい。ある実施形態では、Ｑサーバは、認証データを紛失する安全リスクを制限するために、プロバイダから分離したサーバ上に収容される。

各関係者の役割は、システム全体に信用を広げることから、一関係者が危険に曝されても、システム全体に対する危険は限定されることが可能である。図７を参照されたい。例えば、本発明の１つの強みは、ユーザがそのモバイルデバイスを失っても、７０５において認証情報を容易に取り消すことができることにあり、認証情報は、アクセスに際してユーザに（パスワードのような）監査可能な秘密データを入力するように要求する場合もあって、安全なサイトは、アクセスに際して生体データを要求する。さらに、これらの制御は何れも、プロバイダの介入または変更を必要としない。安全上の他の利点は、フィッシング攻撃の間、ユーザ認証データが絶対にプロバイダ（またはプロバイダを装った者）へ転送されず、よって認証情報の盗難は不可能であることにある。最後に、Ｑサーバが危険に曝されても、Ｑサーバはユーザの個人的な認証情報へのアクセスを持たないことから、Ｑサーバからの全データを有する攻撃者であっても、ユーザになることはできず、またはプロバイダへの追加アクセスを得ることはできない。さらに、認証サーバは認証ゲートウェイとして行動することから、システム内部の多くのイベントは、完全に透明的に、またはユーザシーンの背後で発生することが可能である。例えば、モバイルデバイス紛失後のプロバイダへの再登録は、ユーザ側で何ら相互作用を追加することなく発生することが可能である。また、認証サーバシステムの一実施形態が事実上認証サーバセットより成ることも可能であり、そのうちの幾つかは、ファイアウォールまたは他の周辺デバイス背後の組織ネットワーク上に存在し、かつ認証要求は、特定のどの認証サーバが責任を負うべきかをアクセスされているネットワーク・サービス・プロバイダに基づいて決定すべくサーバ間で調整される。

図７は、可能なユーザ制御エリアおよび管理エリア７１４および７１５のうちの幾つかを描いている。第１のセクション７１６は、７１０上でサーバへ伝達される特定のプロバイダへアクセスするためにどの程度の認証が所望されるかに関するユーザポリシ７００が、ユーザがプロバイダのサイトへアクセスするための究極の要件７０２を作成すべく、７１１上で伝達されるプロバイダ自身のポリシ７０１を用いて分析される、認証サーバ７１３で行われるポリシ調停を例示している。次の３つのセクション７１７、７１８および７１９は各々、ユーザが７０３でそのパスワードの変更を希望し、７０５でその認証情報を失い、または７０７で認証情報が期限切れになっても、７０９に示すように、プロバイダを関係させる必要のあるアクティビティではないことを示している。通信は、認証サーバ７１３とユーザ制御エリア７１４との間で、７０３から７０８までを介して発生する。

図８は、１つまたは複数のプロバイダ８０１および識別８０６の複数のセットに渡って複数のアカウントを維持するユーザａｐｐ８００の能力を示す。アカウント情報は、ユーザ認証要件も含む。ユーザ識別８０６は、複数のデータレコードを含んでもよい。認証サーバ７１３は、次に、ポリシ管理の項目において論じたように、８１３において、ユーザが設定したアカウント毎に、ユーザとプロバイダとの間の認証要件を調停する。認証サーバ７１３は、また、複数のユーザエリアと複数のプロバイダエリア８１１および８１２との間の通信を促進する。例えば、第１のユーザ／プロバイダペアの場合、情報は、ユーザエリア７１４からチャネル８０７を介してチャネル８０９上を第１のプロバイダエリア８１１へ流れる。第２のユーザ／プロバイダペアは、類似するチャネル８０８および８１０のセット上へ異なるデータを送信する。プロバイダは各々、認証設定オプション８０３および８０５を含む固有のアカウントデータ８０２および８０４のセットを保持する。

アーキテクチャに加えて、異なる関係者間で発生する通信セットが存在する。システムとの一般的な相互作用の１つは、ユーザがウェブサイトにログインする時点である。下記は、ログインの一実施形態の高レベルビューである。
１．ユーザは、本発明のログインシステムを実装するウェブサイトへ進む。図２は、ログインがどのようなものに見えるかを示すスクリーンショットである。通常のアカウントログインの選択に加えて、Ｑコードを有するＱＲコード２００が表示されている。Ｑコードは、ヘッダブロック（後述する）と、コードが有効である限り全ユーザに渡って一意であることが保証されかつ認証セッションの簡易識別子として作用するセッションＩｄ（Ｑｓｉｄ）とを含む。
２．次に、図３を参照すると、ユーザは、そのスマートフォン側でＱａｐｐを起動してＱコード３０２をスキャンする。これにより、認証サーバ（Ｑサーバ）１００との通信３０３が開始され、３０４で提供されるユーザおよびプロバイダのポリシに依存して、ユーザは、ｐｉｎ、トークンデータおよび／または生体データを含み得る追加的な認証情報３０５を入力する。より高位の安全サイト、例えばＰＣバンキングを目的とする場合、ユーザは、下記を経る場合もある。図３は、ログイン例を示す。
ｉ．「プロバイダＸへのログインを希望しますか」というメッセージが現れる。これにより、ユーザは、ユーザが試行しているログイン先と、１０２における接続先のロケーションとが同じである点を検証することができる。
ｉｉ．ユーザは、ログインを承認し、次にその秘密データを入力するが、サイト１０３が３ファクタ認証を要求すれば、ユーザは、何らかの形式の生体データ（顔写真、手の画像または音声サンプル等）を提出しなければならない場合もある。
ｉｉｉ．次に３０６において、セッション情報、セッション検証、承認および生体データがＱサーバ１００へ提出されて検証される。シーン背後の３０７で認証を承認すれば、Ｑサーバは、プロバイダへ通知し（よってサイトは、ユーザのチャレンジ／応答の独立した検証を実行することができる）、かつユーザブラウザは、自動的にリフレッシュされかつログインされる。
３．これで、ユーザはログインされ、３０２におけるＱＲコードのスキャンを除けば、情報を入力する必要はなく、あるいは、ウェブサイト上のリンクをクリックする必要もない。これにより、事実上透明で、完全に自動化された、しかも安全な認証システムとなる。

下記は、ログインの他の実施形態を示す高レベルビューである。図９を参照されたい。
１．９０１において、ユーザは、本発明のログインシステムを実装するウェブサイトへ進む。従来のユーザ名およびパスワードフィールドの代わりに、ウェブサイトは、９０２においてユーザがその一意のユーザＩＤを入力するための単一フィールドを有する。一意のＩＤは、ユーザ名のように割り当てられることも可能であり、または電話番号のようなものであることも可能である。ユーザは次に、提出をクリックし、かつウェブサイトは、Ｑサーバからの連携で一意のセッションｉｄ（Ｑｓｉｄ）９００を割り当てて認証を開始する。第２の実施形態では、一意のＩＤは、クッキーに保存される、またはアクセス中にモバイルデバイスから検索される場合もある。また、ブラウザからＱｓｉｄまたはセッション固有の他の識別子を送信することにより、ブラウザとモバイルデバイスとを結びつけることも可能である。送信は、ユーザに表示されかつモバイルデバイスを介してスキャンされるＱＲコードの形式であることも可能である。
２．プロバイダは、９０３において、認証サーバへ一意のユーザＩＤおよびＱｓｉｄを伝達する。
３．認証サーバは、９０４において、一意のユーザＩＤに基づいてユーザのモバイルデバイスに接触する。認証サーバ（Ｑサーバ）によるこの伝達は、認証要件９０５を含む。ユーザおよびプロバイダのポリシに依存して、ユーザは、ｐｉｎ、トークンデータおよび／または生体データ９０６を含み得る追加的な認証情報を入力する。上述の図３の場合と同様に、ログイン例を示す図９も、ログインを終わらせる完成ステップ９０７および９０８を示している。
４．これで、ユーザはログインされ、その一意のユーザＩＤを提供することを除けば、情報を入力する必要はなく、あるいは、ウェブサイト上のリンクをクリックする必要もない。これにより、事実上透明で、完全に自動化された、しかも安全な認証システムとなる。
固有の安全およびアーキテクチャ問題

Ｑコードは、下記の情報、即ちそれが本発明の認証トークンであることを明示するヘッダタグ、および推測を事実上不可能にし、環境内での一意性を保証するに足る長さの、かつＱｓｉｄの再使用の発生を低頻度にするに足る長さのＱｓｉｄ、を含む。ある実施形態では、Ｑｓｉｄは、少なくとも１２８ビット長さのランダム数である。場合により、Ｑコードは、要求されるログイン／登録のタイプまたは代替認証サーバのようなセッション固有情報を含んでもよい。

Ｑｓｉｄに加えて、プロバイダからＱサーバを介してＱａｐｐへ送られる他の情報である活性ＩＤ（Ｑ活性）も存在する。ある実施形態では、Ｑ活性は、プロバイダにより発生されるランダム数である。Ｑ活性は、１）攻撃者はＱｓｉｄおよびＱ活性数字の双方を知る必要があることから、Ｑｓｉｄの再使用をより困難にする、および２）プロバイダがＱ活性を選べることから、Ｑサーバによる攻撃のリプレイを不可能にする、という２つの主要な安全機能を提供する。ある実施形態において、プロバイダがＱ活性ランダム数の生成を希望するか、Ｑサーバを信頼するかは、設定上のオプションである。

第２の実施形態では、ユーザのアクセスソフトウェア（即ち、ウェブサービスのためのブラウザ）も、プラグイン技術、またはユーザがＱｓｉｄを登録したプロバイダ（即ち、ウェブサイト）に属することを検証するための他の技術を有する。このプラグインは、Ｑａｐｐとユーザのブラウザとの間で情報を安全に交換するために使用されることも可能である。これには、ＵＲＬ、セッション鍵または通信に署名しかつ／または通信を保護するための他の情報の検証が含まれる場合もある。ユーザが（スパムリンク、ＵＲＬのミスタイプ、他から）間違ったサイトへ行ってしまい、しかもプロバイダのウェブサイトにいるものと確信しているが、実は攻撃者が実行するサイトにいるという中間者攻撃の場合、ユーザにその間違いを警告する唯一の確実な方法は、ブラウザにおいて、Ｑサーバに関わるユーザの意向を検証することである。これは、ブラウザのプラグイン、またはデスクトップ上のスタンドアロンプログラムとして実行されることが可能である。

異なる実施形態では、スマートフォンに格納されるユーザ認証情報のうちの幾つか、または全てが、プロバイダまたは潜在的に他のユーザとの通信に使用される秘密鍵および証書を含む暗号鍵ストアに格納される。ユーザ認証情報は、公開／秘密鍵ペア、パスワード、生体テンプレート、ワンタイムパスワード・シード、他を含む、ユーザを検証するための任意の情報またはトークンを含むことも可能である。

鍵ストアの復号に当たって、ある実施形態は、６０１および６０６において、鍵ストアが失われてもブルートフォースが復号鍵を推測することを防止するために、かつＱサーバが鍵ストアへのアクセスを有することを防止するために、一意の分割鍵システムを用いる。図６を参照されたい。本発明は、下記の分割鍵システム、即ち、ユーザが入力する秘密データが複数の部分に分割され、２つの部分、ＡおよびＢを用いることが一実施形態である、分割鍵システムを含む。秘密データは、パスワード、ｐｉｎ、生体テンプレート、ユーザが描く画像、他を含む任意タイプのユーザデータであることが可能である。パスワードの部分Ａは、６０５において、復号鍵の部分Ａを生成するために局所的に使用される。様々な実施形態において、部分Ａは、ローカルシステム上で他のブロックを復号するために使用される場合もあれば、スマートカードの一意の製造番号のようなシステム情報と組み合わされる場合もあり、あるいは部分Ａをより長くするために、または復号するにはより分かりにくいものにするためにハッシュされる、または別段で修正される場合もある。部分Ａは絶対に電話から離れないことから、ユーザは、復号鍵に対する制御を保全する。秘密データの部分Ｂは、６０２において、暗号化されかつ認証されたチャネル上で（ユーザの通信鍵を用いて）Ｑサーバへ送信され、Ｑサーバは、６０４において、復号鍵の部分Ｂを送り返す。異なる実施形態において、鍵の部分Ｂは、データベースから検索され、秘密データの部分Ｂからハッシュとして生成され、または他のユーザ／ハードウェア固有情報と結合される場合もある。Ｑサーバは、部分Ｂの使用を監視できることから、６０３において、設定回数の試行失敗後にアカウントをロックし、ユーザに警告し、または不審な挙動に別段の応答をすることが可能である。

ある実施形態では、ユーザ認証情報は、公開／秘密鍵および証書システム（ＰＫＩ）に基づく。このシステムの利点は、ユーザの認証情報である秘密鍵が絶対にスマートフォンを離れず、よって登録において証書の署名かつシステムへの検証を行えることにある。これらの証書は、個々に配りかつ制御することができ、ユーザは、プロバイダ毎に別々の認証情報で認証を行うことができる。さらに、他の認証情報ペア、例えばユーザ対ユーザの認証情報も、別々に生成されかつ保持されることが可能である。ある実施形態は、異なる３タイプの証書を使用するが、これらは、異なる３つの署名権限保有機関、即ち１）プロバイダの証書権限保有機関（ＣＡ）−プロバイダとＱサーバとの間の通信に用いるためのプロバイダ証書に署名する、２）ユーザのＣＡ−プロバイダに関連するその認証情報の検証に用いるためにユーザにより生成されるユーザ通信証書およびユーザ対プロバイダ証書に署名する、および３）ＱサーバのＣＡ−ユーザおよびプロバイダに対し、ユーザおよびプロバイダが正規のＱサーバと対話していることを検証するために、Ｑサーバ上で使用される証書に署名する、によって署名される。第２の実施形態では、ユーザは、単一のユーザ対全プロバイダ証書を有する場合もあり、かつ署名権限保有機関は、単一のＣＡまたは階層的ＣＡ構成に統合される可能性もある。

本発明において、ユーザは、生体データを含む複数形式の認証データを用いることが可能である。認証システムにおける現行の最新技術は、何らかの形式の知識、生体およびトークンファクタを組み合わせるが、これらのファクタのうちの１つのみを設定することは、本発明なしでは複雑になる。スマートフォンおよび他のタイプのモバイルデバイスは、複数のセンサおよび他のデータ入力方法を有することから、下記のような全ての従来的認証タイプからデータを収集することが可能である。
・人を示すもの：正面のカメラで撮った顔認識、後向きカメラで撮った手認識、マイクで撮った話者認識、他のような生体的オプションを含む。電話によっては、指紋リーダのような特殊化された入力を内蔵したものがあり、かつスマートフォンには、追加のケイパビリティを許容するデバイスを取り付け可能であることが多い。
・知っているもの：パスワード、安全質問、話者認識の間に話される語句、画面に描かれる画像、電話の震動パターン、他を含む。
・所有するもの：最も自明なものは、電話またはモバイルデバイス自体である。しかしながら、このカテゴリには、例えば電話に関連づけられるトークン、取り付けられるｕｓｂデバイス、近距離無線オプションを介して発見されるトークン、カードリーダで読み取られるカードデータ、デバイスのＳＩＭカードからのデータ、安全なコプロセッサまたはデータロックボックス内のデバイス自体に格納される安全なデータ、他も包含されることが可能である。

本発明は、プロバイダおよびユーザが、必要とされる場合に個別ベースで柔軟性および追加的安全性を与える１つまたは複数タイプの認証を用いることができるようにする。Ｑサーバは、様々な生体的またはトークンオプションの登録、生体テンプレート等の安全なデータの格納、異なる形式の認証を標的とする詐欺行為検出、およびログイン認証と登録されたデータとの比較を含む、追加的ファクタの安全管理を実行する。Ｑａｐｐは、認証データの収集を管理し、かつＱサーバへの提出前に、データに関して一連の前処理ステップを実行してもよい。前処理の目的は、主として、画像がぼけている、受信されない、他である場合にユーザへ迅速にフィードバックを与える提出の質を保証することにあるが、前処理は、送信されるデータサイズを制限しかつ提出データを潜在的に整理する（ヘッドを画像中心に合わせる、他）ためにも使用される。また、Ｑａｐｐは、Ｑサーバ上で実行される主たる詐欺行為検出に加えて実行される一連の詐欺行為検出機能も有する場合がある。Ｑサーバは、追加的な認証ファクタを保持するものの、鍵ストア４０６へのアクセスを持たないことから、ユーザであると偽ることはできない。この信用分離は、ユーザによる自身の認証に対する制御を危うくすることなく、集中化された制御および管理を可能にする。このアーキテクチャの他の利点は、プロバイダが一切変更を行う必要なしに、新たな形式の認証をユーザへ展開できることにある。

本発明のアーキテクチャは、プロバイダが新規ユーザの追加を希望する際の簡易的な設定も可能にする。プロバイダは、認証データを事前に設定する必要がなく、例えば、一時的なパスワードを割り当てる必要がない。これにより、プロバイダに、サポートを希望する認証ポリシのタイプにおいてより大きい柔軟性を持たせることができる。例えば、プロバイダは、２ファクタを要求すべく認証のアップグレードを希望すれば、単にサーバ側のグローバルなポリシを変更し、かつユーザは、２ファクタによる認証の要求され始める。プロバイダは、全て認証サーバにより処理される新規ファクタの登録データを収集しようとして各ユーザへと戻る必要がない。単純化された識別および登録と組み合わされた場合、プロバイダは、そのシステム上に如何なるアカウントも事前設定する必要がない。

ある実施形態では、従来のユーザを、ネットワークに渡る様々なサービスに対して認証される必要があるバッチシステムのような自動プロセスで置換することが可能であると思われる。システムは動作するものの、生体認証または知識ベースの認証ファクタと同等の所定のオプション構成部品が可能とはならない。

また、本発明は、プロバイダとユーザとの間の、認証サーバおよびユーザ・モバイル・デバイス上のＱａｐｐを通じた安全なチャネルを介する安全な形式の通信も可能にする。この安全な通信チャネルは、プロバイダが極めて重要な通知を、「購入が完了しました」または「送金が完了しました」といった情報を偽装または修正され得ない方式で送信できるようにする、信頼された方式で送信することを可能にする。データの暗号鍵は、関係者間で先に交換している公開証書または先に共有しているセッション鍵を含む任意の規格に基づくことも可能である。このタイプの通信は、ネットワーク上の任意の２ユーザ間の事前に確立されたユーザ対ユーザ認証情報を用いる安全な通信も可能にすると思われる。

「購入が完了しました」のような一方向要求は、ユーザからの応答を要求しないが、「Ｘの購入希望を確定しますか」のような双方向要求は、プロバイダがユーザからの応答を待てるようにする。したがって、ユーザは、取引を、その最終承認より前に安全な通信チャネルを介して検証することができる。検査プロセスは、ユーザがその時点でプロバイダにログインしていない場合でも発生する可能性があり、かつユーザが取引の「承認」を、追加的な認証データの提供と同時的に行うようにすることも可能である。
ログインプロセスの詳細な実施の例−図３参照

・ユーザは、３０１において、デスクトップまたはモバイルブラウザを介してウェブサイトへ進む。
・ウェブサイト１０３（プロバイダ）は、チャネル１０４上で認証サーバ１００からセッションＩＤ（Ｑｓｉｄ）３００を入手し、かつ局所的にセッション固有ランダム数（Ｑ活性）３００を生成する。プロバイダは、パフォーマンスを理由として、ＱサーバからＱｓｉｄセットを事前キャッシュすることも可能性である。Ｑ活性は、認証サーバ上で生成されることも可能である（安全リスクは幾分か高まる）。Ｑ活性コードがプロバイダにより生成されれば、プロバイダは、Ｑｓｉｄの付与に伴ってＱ活性コードを認証サーバへ送信する。
・プロバイダは、表示されるＱコードに組み込まれたＱｓｉｄをユーザに示す。Ｑコードは、サーバにより生成されかつブラウザに画像として示されるか送信され、かつブラウザ側のジャバスクリプトにより生成される画像として表示される。Ｑｓｉｄは、第三者がＱｓｉｄを盗用していれば、競合状態を防止するために、ＳＳＬまたは他のトランスポート暗号化を用いて暗号化されるべきである。少なくとも幾つかの実施態様では、ユーザは、その一意のユーザＩＤをプロバイダへブラウザを介して入力あるいは提供し、ログインプロセスを開始する。プロバイダは、次に、一意のユーザＩＤ、ＱｓｉｄおよびＱ活性を暗号化チャネル上で認証サーバへ送信する。
・バックグラウンドにおいて、ユーザのブラウザは、暗号化チャネル１０５上で認証サーバをＱｓｉｄで絶えずポーリングし、認証が完了した時点を識別する。
・ユーザは、３０２において、Ｑコードをその認証アプリケーション（Ｑａｐｐ）を用いてスキャンする。ユーザは（Ｑａｐｐポリシに基づいて）、認証アプリケーションの開始前にその秘密データを入力する必要がある場合もあれば、ない場合もある。Ｑａｐｐは、Ｑコードを復号し、それが適正なコードであることを確信し、次にＱｓｉｄを抽出する。
・Ｑａｐｐは、クライアント−認証ＳＳＬ上で認証サーバへ接続し（よってＱサーバは、Ｑａｐｐユーザを検査することができる）、認証サーバの証書を検査し、次に、ステップ３０３においてＱｓｉｄを送信する。
・認証サーバは、Ｑａｐｐへセッションデータ３０４を送り返す（あるいは、直前に記載した２ステップが実行されなければ、認証サーバは、一意のユーザＩＤに基づいてユーザのモバイルデバイスへ接続し、Ｑａｐｐは、双方向の認証ＳＳＬ接続部上でセッションデータによりログイン要求を送信する）。セッションデータには、下記が含まれる。
・Ｑ活性数字、およびセッションのタイプ（ログインまたは登録）。
・ユーザが接続しようとしているプロバイダの識別名、ロゴおよび読取り可能な名前。任意選択の実施形態は、プロバイダの鍵で署名されたプロバイダの証書およびＱ活性を送信し、プロバイダの検証を可能にするが、より高いＣＰＵオーバーヘッドを要する。
・要求されるプロバイダの認証ポリシ（なし、パスワード、生体データ、他）。
・Ｑａｐｐは、プロバイダの認証ポリシと組み合わせてユーザの許可４０８および４０５をチェックし（常時的通知を希望するか、常時そのパスワードをタイピングするか、他）、次に、ユーザに適切な情報３０５について尋ねる。例えば、ユーザは、３ファクタ認証用にパスワードおよび生体データを入力する必要があるものとする。
・ユーザは、その秘密データをＱａｐｐへ入力する。
・Ｑａｐｐは、秘密データのネットワーク成分を認証サーバへ、暗号化されかつ検証されたチャネル上で送信する。
・認証サーバは、秘密データのネットワーク成分を検証し、ブルートフォースによる推測および他のタイプの攻撃を防止するために詐欺行為検出を実行し、次に、復号鍵の半分Ｂを送り返してユーザ電話側の鍵ストアをアンロックする。
・Ｑａｐｐは、分割鍵の半分Ｂを受信し、これを秘密データの半分Ａおよび安全に関連のない電話からの潜在的に他の情報（例えば、デバイスの一意のＩＤ、他）と組み合わせ、かつ組み合わされた鍵を用いてアプリケーション内の安全な鍵ストアをアンロックする。鍵ストアは、ユーザが通信するプロバイダ毎の秘密鍵を収容する。
・Ｑａｐｐは、次に、要求される任意の追加的な生体データ（例えば、手の画像）についてユーザにプロンプトする。
・Ｑａｐｐは、次に、３０６において、下記を含む認証のフルパケットをＱサーバへ送り返す。
・Ｑｓｉｄ−セッションＩＤ。
・ユーザｉｄ、Ｑｉｄは、通信証書に内蔵されていて、Ｑサーバによりクライアント認証ＳＳＬ接続に基づいて入手可能である。異なる実施形態では、Ｑｉｄは、ユーザ／プロバイダペア毎に一意であることが可能性であり、Ｑａｐｐのインストール毎に一意であることも可能である。
・特有のプロバイダに関する、ユーザ証書により署名されたＱｓｉｄおよびＱ活性。
・生の生体データ（例えば、顔または手のｊｐｇ画像）。
・認証サーバは、次に、下記のチェックを含むユーザパッケージの検証を行う。
・ユーザの通信証書は、有効である。証書が取り消されておらず（ユーザが電話を紛失した場合に発生し得る）、通用し（証書は期限切れとなり、リフレッシュする必要がある）かつ実際に存在する（新規ユーザまたは攻撃者が有効な証書を有することはない）点を確認する。
・Ｑｓｉｄは、有効である。これには、攻撃（攻撃者によるＱｓｉｄ再使用の試行等）またはブルートフォース・スキャン（攻撃者によるランダムＱｓｉｄの送信等）のチェックが含まれてもよく、かつこれが期限切れになっていない、サイトへのマッピングは有効である、他を確認するチェックも含まれる。
・ユーザは、プロバイダがＱｓｉｄでマッピングされたアカウントを有する。マッピングは、ＱｉｄからＱｓｉｄに登録されたプロバイダまで存在する。ユーザがアカウントを保有していなければ、認証サーバは、「このサイトには登録されていません」というメッセージをユーザへ送り返す。このタイプのチェックは、フィッシング攻撃を無効にするために使用される方法の１つである。
・生体データは、先にユーザによって登録されたデータに照らして検査される。生体データでは、様々な詐欺行為検出ステップが実行される場合もあれば、実行されない場合もある。
・署名入りのＱｓｉｄおよびＱ活性は、有効であり、かつ正しい証書により署名されている。
・認証サーバ（ユーザのオリジナルブラウザによってポーリングされている）は、ユーザのブラウザへ有効なログイン信号を送り返す。
・ブラウザは、プロバイダの受信された認証承認ロケーションへ接続する。
・プロバイダは、次に、認証サーバへ（暗号化されかつ検証されたチャネル上で）接続し、承認３０７の確定について尋ねる。認証サーバは、プロバイダへ下記のデータ、即ちＱｉｄ、署名入りのＱｓｉｄおよびＱ活性を含むユーザ証書、Ｑサーバへ送られた認証の有効性（例えば、ユーザはｐｉｎおよび顔で首尾良く認証されている）、を含むメッセージ「有効なログインを受信しました」を送り返す（この好適な方法は、具体的には、生体データまたは他の認証データをプロバイダへ送信しないことに留意されたい）。
・場合により、プロバイダは、次に、ローカルポリシに基づいて署名を承認または再検査することができ、かつ証書に関して、ログイン証書を登録証書に照らし合わせることを含む追加的な安全チェックを実行することができる。承認されると、ユーザは、ウェブサイトへログインされる。
登録プロセスの詳細な実施の例

１）Ｑサーバに対するユーザ登録
ユーザは、Ｑａｐｐをそのスマートフォンにダウンロードする。Ｑａｐｐが最初に開始される際に、ユーザは、新しいアカウントを生成することができ、または下記のようにシステムに登録することができる。
１．ユーザは、名前、電話番号、ｅメール、他を含み得る様々な登録情報を入力する。
２．場合により、ユーザは、顔画像、音声プリント、パスワード、他のような生体登録データを入力する。
３．ユーザは、「提出」をクリックし、Ｑａｐｐは、ＱサーバへユーザＩＤ（Ｑｉｄ）要求を送信する。要求は、ユーザがまだ登録されていないことを検査し、かつ場合により帯域外検証を実行する（ユーザへｅメールを送信する等）ために、例えばｅメールアドレスである登録データの様々な部分を含んでもよい。
４．Ｑａｐｐは、Ｑサーバから一意のユーザｉｄ（Ｑｉｄ）およびＱサーバの公開証書の返送を受信する。Ｑａｐｐは、一意の公開／秘密鍵ペア、ユーザの通信証書（Ｑｉｄを含む）および証書署名要求を生成する。
５．Ｑａｐｐは、次に、Ｑサーバへ、証書署名要求、登録データおよび任意の生体データを含む登録データを送信する。
６．認証サービスが提出を承認するものと想定して、認証サービスは、ユーザの通信鍵の署名入り証書を送り返し、かつユーザデータをシステムに登録する。この情報は、次に、Ｑａｐｐ内に保存される。

２ａ）プロバイダへのユーザ登録
ユーザが、プロバイダサービスへ接続し、かつ登録することを選択すると、ユーザに、ユーザが供給する必要のある任意の情報を含むプロバイダの既存の登録ページ、およびＱコードが提示される。
・登録プロセスの第１の部分は、ログインプロセスと同じである。これは、Ｑａｐｐがセッションデータの返送を受信し、かつそのセッションデータが登録セッションであるという識別子を含むと分岐する。
・Ｑａｐｐは、ユーザに、「プロバイダＸが登録を要求しています」という登録を承認するためのメッセージを示す。ユーザが承認すれば、Ｑａｐｐは、ユーザに、必要な任意の追加的認証（例えば、顔認識、他）を入力するように要求する。
・Ｑａｐｐは、ユーザとプロバイダとの間で用いるための公開／秘密鍵ペアを生成する。
・Ｑａｐｐは、証書署名要求を送る。
・認証サーバは、適宜、パラメータおよび生体データを検証し、かつ証書署名要求に署名する。
・認証サーバは、次に、Ｑａｐｐへ、プロバイダに関する公開証書（オプション）およびユーザに関する署名入り証書を送り返す。認証サーバは、次に、証書を（ユーザ、プロバイダ）ペアに関連づける。
・オリジナルのブラウザページ上のＱコード画像または他の視覚的表示は、奏効した登録を示して更新される。これでユーザは、その登録をプロバイダへ提出することができる。
・プロバイダは、セッションＩＤに基づいてセッションを検証し、首尾良く検証されれば、ユーザの公開証書およびユーザＩＤ（Ｑｉｄ）を保存する。セッションＩＤが有効でなければ、これは単に認証サーバを用いることなくプロバイダサイト上で登録されたユーザである可能性もあり、よってこのセッションＩＤが使用されたことはない。

２ｂ）第２の登録実施の形態−識別の追加
プロバイダサイトにおけるユーザ登録をユーザ側でより容易にするための一方法は、ユーザが再入力しなければならない情報量を簡約することである。図８を参照されたい。本発明は、８０６において、ユーザが１つまたは複数の「識別」、例えば業務上および個人的な識別、を生成できるようにする。各識別は、識別に関連づけられるデータセット、例えば名前、ｅメールアドレス、郵便宛先、他を有する。よって、ユーザは、登録の間、ある識別からの情報を用いてプロバイダの登録情報に記入するオプションを有する。この単純化された登録オプションは、ユーザがログインＱコードをスキャンし、またはその一意のユーザＩＤをプロバイダの書式に入力し、かつユーザにアカウントがないことをＱサーバが認識した場合に、もたらされてもよい。ある実施形態では、識別情報は、Ｑサーバ上に格納されることが可能であり、かつ第２の実施形態では、識別が専らモバイル・ユーザ・デバイス上に格納されることが可能である。さらに、識別情報の管理は、情報の記憶装置に対して局所的に実行されることが可能であり、または、サーバ、認証サーバ、ユーザのデスクトップコンピュータ、他を含む他のサーバまたはデバイス上でリモート合意によって実行されることも可能である。
・登録プロセスの第１の部分は、ログインプロセスと同じである。これは、Ｑａｐｐがセッションデータの返送を受信し、かつそのセッションデータが登録セッションであるという識別子を含むと分岐する。
・Ｑａｐｐは、ユーザに、「プロバイダＸへのログインを保有していません。登録を希望しますか？」という登録を承認するためのメッセージを示す。プロバイダにより要求される登録情報のタイプ（名前、誕生日、他）は、特性セットとしてＱサーバによりＱａｐｐへ送信される。Ｑａｐｐは、次に、「プロバイダＸを登録するために、次の情報、即ち名前、ｅメール、他を希望します」といったメッセージをユーザに示す。ユーザは、次に、その識別セットから、プロバイダに使用したいものを選択することができ、必要なフィールドが、予め設定された識別データを用いて記入される。場合により、ユーザには、データを提出前に編集する選択肢が与えられてもよい。ユーザは、提出されるデータに対する完全な制御を保全し、しかも、クリックしてプロセスを登録することができる−潜在的に、如何なる新規データもタイピングする必要はない。
・次に、登録プロセスは、正常に進行する。

３）Ｑサーバへのプロバイダ登録
これは、ユーザ登録より遙かに低頻度での発生が予期され、よって、署名鍵およびプロセスは、よりマニュアルであることが可能性である。これは、本質的に上述のステップと同じステップを辿るが、プロバイダが（提供されるスクリプトを用いて）その鍵を生成し、かつ返されるデータをそのプロバイダ設定の一部として保存する点が異なる。プロバイダは、認証ＣＡおよびユーザＣＡ証書の返送を受信する。
紛失電話プロセスの詳細な実施の例

図７を参照されたい。ユーザ証書は、提案するシステムを用いてログイン前に検証されていることから、７０５においてユーザが電話の紛失を報告すると、全ての証書は、即座に無効化されることが可能である。これは、詐欺行為が検出された場合、またはユーザが、自分の電話が危険に曝されているかもしれないと考える場合にも使用されることが可能である。ユーザ支援を促進するためには、鍵が無効にされるだけでなく、Ｑサーバのサービスを用いてその旧プロバイダにより再登録を単純化しかつ管理することが可能である（実際に、Ｑサーバを信頼していれば、ユーザを再検証するためにプロバイダが何かする必要はない）。異なる実施形態では、認証情報を無効にする方法は、鍵の取消し、削除またはデータの無効化を含む。

ユーザは、その電話の紛失を、Ｑサーバのウェブサイトを呼び出す、またはこれにログインすることによって報告する。ユーザは、秘密データの半分Ｂを用いることができ、または、新しい電話を有していれば、生体オプションを用いてログインすることができる。
・認証サービスが無効になる（または、全てのユーザ鍵を無効とマーキングする）。
・ユーザが無効化された鍵を用いてログインしようとすれば、ログインは拒絶される。
再検証

・ユーザは、そのアカウントの再セットアップへ進むと、Ｑａｐｐ上で「既存のアカウントへログイン」を選択し、かつｅメールアドレス、生体データおよび秘密データのネットワーク部分を含む、ログインのための詳細を記入する。適切な情報が、認証サーバ上へ送信され、生体情報および他のログイン情報が正しいことを確かめるために検証される。
・認証が有効であれば、認証サーバは、ユーザの旧ユーザＩＤ（Ｑｉｄ）を送り返す。正常な登録は、Ｑａｐｐによる鍵ペア、証書、他の生成を続ける。
・次に、ユーザが、以前その認証情報を有していたサイトへログインしようとする場合、ユーザは、通常のログインプロセスに従うが、認証サーバは、そのユーザに関する現行の認証情報が発見されず、ユーザが既に認証情報を取り消していることを確認し、かつ新しい認証情報を生成するようにＱａｐｐに接触する点が異なる。認証情報が生成されると、ユーザのオリジナルブラウザが接触され、ユーザが再登録を行っていることが告げられる。ブラウザの戻りコードを用いてブラウザへ通知することにより、ユーザに対するリダイレクトを自動的に発生させることができる。ユーザに完全に透明な再登録オプションを与える能力は、認証フレームワーク、およびブラウザとプロバイダとの間の専用通信によって有効化される。これは、プロバイダにユーザを再登録ページへリダイレクトする機会を与え、再登録ページにおいて、プロバイダはユーザを再検査するために追加質問（例えば、好きなペットの名前、他）をすることができる。プロバイダは、このステップをスキップして、単に新しい認証情報を受け入れることもできる。認証情報が受け入れられると、ユーザは、ログインする。認証サーバも、この新しい認証情報を「受け入れる」ように、プロバイダにより接触される。
ポリシ設定の詳細な実施の例

プロバイダおよびユーザが選択できるポリシのオプションおよび設定は、幾つか存在する。その各々が、ログインまたはログインプロセスを検証するために行われるステップに僅かに影響する。例えば、プロバイダは、ユーザの鍵は暗号鍵ストアに格納されるべきであり、または、ユーザのログインに際して２ファクタを用いる必要がある点を明示することができる。ユーザは、鍵が暗号化されて格納されるべきかどうかを指定することもできる。Ｑａｐｐは、ユーザおよびプロバイダ仕様の双方を満たす最小限の設定を選択する。これは、ユーザ関連オプションの各々が、安全性に対する「アップグレード」として作用することを意味する。ポリシ管理は、ＱａｐｐまたはＱサーバを用いてユーザポリシを変更できる例について配分することができる。一方で、Ｑサーバまたはプロバイダは、プロバイダポリシを変更するためにアクセスを有する場合もある。ある実施形態では、プロバイダのみが、プロバイダポリシを更新することができる。ある実施形態では、Ｑａｐｐのみが、ユーザポリシを変更することができる。他の実施形態では、ユーザは、Ｑサーバ上でウェブサイトのようなインタフェースからそのポリシを変更することも可能性である。本発明では、ユーザは、多数の個別レコードの保全を担当する管理者またはスーパーユーザを有するのではなく、その個々のポリシ情報およびレコードに対する制御を与えられる。
ユーザポリシ

・全ての鍵を暗号化する。この場合、システム上でＱａｐｐが開始される度に、ユーザはその秘密データを入力する必要がある。
・設定された期間に亘って、認証が有効のままである（即ち、メモリに格納されている）ことを可能にする。これにより、ユーザは、その秘密データを入力する、またはその画像を撮る回数を、限定することができるようになる。可能な設定として、画面を保存する度、またはおそらくは１時間おき、が含まれる。固有の生体データまたは特殊トークンは、有効であり続ける固有の最大時間枠を有してもよい。
・ユーザは、特定鍵８０１のポリシを（Ｑａｐｐアプリケーション上、またはＱサーバウェブサイト上の何れかで）直接管理することができる。これには、特定のサイトを、認証を要求するように「アップグレード」することが含まれることになろう。例えば、プロバイダがその時点で２ファクタ（電話および秘密データ）を要求していれば、ユーザは、生体ファクタを追加するように要件をアップグレードすることができ、そうなれば、このユーザに関しては、３ファクタ認証の提供なしに特定のプロバイダにおけるそのアカウントがアクセスされることはない。
・他の実施形態では、ユーザは、プロバイダ証書およびＱ活性署名ブロックを受信し、かつＱａｐｐにおいてこの署名を検証することを選択することも可能性である。
プロバイダポリシ

本発明は、プロバイダがＱサーバを信用してプロバイダチェックの大部分をスキップすることを可能にする設定オプションを含み、またはプロバイダがユーザからのあらゆるもの（追加の認証ファクタを除く）を再検証することを可能にする。下記は、プロバイダ上で使用可能な主要設定のうちの幾つかである。
・ユーザ認証情報を再検証する。これには、ユーザ認証情報が登録の間に承認されたものと同じであること、証書が期限切れでないこと、認証の間に返された署名入りデータが、先に同意された証書を用いて署名されていること、の検証が含まれる。
・Ｑｓｉｄの取得時点で、Ｑサーバに作成させるのではなく、プロバイダ固有のＱ活性を生成する。（これにより、Ｑサーバによるリプレイ攻撃の実行が防止される。）
・再登録をオンまたはオフにする。これによりプロバイダは、ユーザに、再検査について、鍵を紛失して再登録される必要があるのか、と質問することができる。オフにされれば、プロバイダは、Ｑサーバが認証検査を実行しているものと信用する。
・ユーザのブラウザに、ユーザのブラウザがプロバイダに最初に接続する際に与えられるクッキーを用いて、Ｑコードを見たブラウザがログインしたブラウザと同じであることを検証する。

４）プロバイダに対する書類による既存ユーザ登録
ＱＲコードを介してユーザのモバイルデバイスへ送信されるＱｓｉｄを用いることの１つの優位点は、既存のプロバイダアカウントの最初の登録が、メーラまたは書類による開始によって実行され得ることにある。これの優位点は、登録プロセスがプロバイダの通知（口座明細書または公共料金勘定書等）を介して、または初期セットアップの間（銀行口座開設または住宅融資を受けるために出かけるとき等）に開始される可能性もあることにある。図１０を参照されたい。この登録プロセスの下では、下記のステップが発生する：
・プロバイダが、アカウントをセットアップしている場合、または既存ユーザの登録を希望する場合、プロバイダは、用紙１０００上に、ユーザとプロバイダアカウントとが認証サーバを介して相互に関連づけられることを可能にする一意のＱコード１００８をプリントする。Ｑコードは、ヘッダブロック（後述する）と、１００１においてサーバにより同意された登録Ｉｄ（ＱＥｉｄ）とを含み、ＱＥｉｄは、登録コードが有効である限り全ユーザに渡って一意であることが保証され、かつ登録セッションの簡易識別子として作用する。
・１００２において、ユーザは、認証アプリケーション（Ｑａｐｐ）１０１を用いてＱコードをスキャンする。ユーザは、（Ｑａｐｐポリシに基づいて）認証アプリケーションを開始する前にその秘密データを入力する必要がある場合もあれば、ない場合もある。Ｑａｐｐは、Ｑコードを復号し、これが適正なコードであることを確認し、次に、Ｑｓｉｄを抽出する。
・１００３において、Ｑａｐｐは、（ＱサーバがＱａｐｐユーザを検査できるように）クライアント−認証ＳＳＬ上で認証サーバへ接続し、認証サーバの証書を検査し、次に、Ｑｅｉｄを送信する。
・認証サーバは、Ｑａｐｐへ、下記を含むセッションデータ１００４を送り返す。
・Ｑ活性数字およびセッションのタイプ（ログインまたは登録）。
・ユーザが接続しようとしているプロバイダの識別名、ロゴおよび読取り可能な名前。任意選択の実施形態は、プロバイダの鍵で署名されたプロバイダの証書およびＱ活性を送信し、プロバイダの検証を可能にするが、より高いＣＰＵオーバーヘッドを要する。
・要求されるプロバイダの認証ポリシ（なし、パスワード、生体データ、他）。
・Ｑａｐｐは、ユーザに、「プロバイダＸが登録を要求しています」という登録を承認するためのメッセージを示す。ユーザが承認すれば、Ｑａｐｐは、ユーザに、必要な任意の追加的認証１００５（例えば、顔認識、他）を入力するように要求する。
・Ｑａｐｐは、ユーザとプロバイダとの間で用いるための公開／秘密鍵ペアを生成する。
・Ｑａｐｐは、証書署名要求および他の任意選択の認証情報１００６を送る。
・認証サーバは、適宜、パラメータおよび生体データを検証し、かつ証書署名要求に署名する。
・認証サーバは、次に、Ｑａｐｐへ、プロバイダに関する公開証書（オプション）およびユーザに関する署名入り証書を送り返す。認証サーバは、次に、証書を（ユーザ、プロバイダ）ペアに関連づける。
・次に、認証サーバは、１００７において、新たに生成されたユーザ−プロバイダ証書を含む登録情報をプロバイダへ送る。プロバイダは、プロバイダが絶えずＱサーバをポーリングすること、両者が絶えず接続されていること、またはＱサーバがプロバイダへ直に接続する能力を有することを含み、任意数のアーキテクチャを介して接触されてもよい。プロバイダは、登録ＩＤに基づいてセッションを検証し、首尾良く検証されれば、ユーザの公開証書およびユーザアカウントＩＤ（Ｑｉｄ）を保存する。

ユーザは、次に、追加の検証情報をタイピングすることなく認証システムへ登録され、これで、簡易なマルチファクタ認証でログインすることができる。第２の実施形態では、プロバイダは、再登録プロセスと同様に、ここで他の検証層を提供することによって、ユーザが初回使用で追加情報を入力するように要求してもよい。
通知プロセスの詳細な実施の例

１）プロバイダは、ユーザへメッセージを送る。
ユーザ−プロバイダの関係性が（登録プロセスを介して）設定されると、プロバイダは、固有のユーザアカウントに関連づけられる一意のユーザアカウントＩＤを有する。図１１を参照されたい。プロバイダにおいて、検証されるべき、またはユーザへメッセージ送信されるべきイベントが発生すれば、下記のプロセスが発生する：
・プロバイダは、１１００において、Ｑサーバへ、プロバイダに既に格納されかつプロバイダ証書、メッセージで署名されたユーザの証書で暗号化されることが可能なユーザのアカウントＩＤ（Ｑｉｄ）、トランザクションＩＤおよびメッセージを送信する。要求は、ユーザがトランザクションを承認する必要があるかどうか、および承認のために何らかの認証が要求されるかどうかを明示するヘッダも含む。トランザクションＩＤは、配信または承認を検査すべく、後に特定のトランザクションを識別するために使用される。第２の実施形態では、メッセージに関してユーザを正しく識別するために、Ｑｉｄの代わりに、既にログインしているユーザのＱｓｉｄが使用されることが可能性である。
・１１０１において、Ｑサーバは、ユーザ・モバイル・デバイスのＱａｐｐへの接続を開始する。接続開始は、プッシュ機構、オープン・ネットワーク・ポート上で発生することも可能性であり、またはＱａｐｐは、モバイルデバイスのアーキテクチャおよび利用可能なサービスに依存して、定期的にＱサーバをポーリングする、またはＱサーバへ接続されたままになることも可能である。
・Ｑサーバは、Ｑａｐｐへ、トランザクションＩＤ、メッセージブロックおよびポリシ要件を含むメッセージ要求を送る。Ｑａｐｐは、次に、１１０２において、メッセージを復号し、メッセージをユーザに示し、要求されれば、検証のために承認および追加的な認証情報を入手する。
・Ｑａｐｐは、次に、１１０３において、応答を生成してこれをＱサーバへ送り返し、Ｑサーバは、１１０４において、これをプロバイダへ転送して返す。応答には、ユーザの承認回答、追加的な認証情報およびメッセージが示されたことの検査が含まれてもよい。ある実施形態では、プロバイダは、１つまたは複数のメッセージに応答して、Ｑサーバを絶えずポーリングしてもよい。第２の実施形態では、ユーザのブラウザは、ユーザが検査を要求したトランザクションを開始した後にＱサーバをポーリングし、完了すると、ブラウザは、プロバイダに通知のステータスをチェックするように告げる。第３の実施形態では、Ｑサーバは、プロバイダへ直に接続する。

これと同じプロセスは、Ｑサーバ上にアカウントを有していて既に証書を交換している２ユーザ間でメッセージを共有するために使用されることも可能である。

Claims (19)

1. 複数の異なるユーザを複数の異なるサービスプロバイダに対して認証することができるネットワークシステムであって、
   （ｉ）前記複数の異なるサービスプロバイダの各々のプロバイダ識別子を、該当するサービスプロバイダのプロバイダ認証ポリシ要件に関連づけて格納し、かつ（ｉｉ）前記複数の異なるユーザの各々のユーザ識別子を、該当するユーザの検証情報に関連づけて格納するように構成される認証サーバと、
   前記複数の異なるユーザのうちの第１のユーザによって操作可能であり、かつネットワークを介して前記複数の異なるサービスプロバイダのうちの第１のサービスプロバイダへログイン要求を送信するように構成される第１のデバイスと、
   前記第１のサービスプロバイダに関連づけられ、かつ前記ネットワークを介して前記認証サーバへ、（ｉ）ランダム数要求と、（ｉｉ）他の情報と、を送信するように構成されるネットワークサーバであって、前記認証サーバは、前記送信されたランダム数要求に応答して、ランダム数を、前記ネットワークを介して前記ネットワークサーバへ送信するように構成され、前記ネットワークサーバは、前記送信されたログイン要求に応答して、前記送信されたランダム数を、前記ネットワークを介して前記第１のデバイスへさらに送信するようにさらに構成される、ネットワークサーバと、
   前記第１のユーザによって操作可能であり、かつ（ｉ）前記さらに送信されたランダム数を前記第１のデバイスから自身へ転送する入力を受信するように、かつ（ｉｉ）前記入力されたランダム数および前記第１のユーザの認証要求を、前記ネットワークを介して前記認証サーバへさらに送信するように、構成される第２のデバイスと、を備え、
   前記認証サーバは、前記第２のデバイスによる前記ランダム数および認証要求の送信の後、前記ネットワークを介して前記第２のデバイスへ、前記格納された第１のプロバイダの識別子、および前記格納されかつ関連づけられた第１のプロバイダの認証ポリシ要件を送信し、かつ前記送信された他の情報をさらに送信するように、さらに構成され、
   前記第２のデバイスは、前記送信された第１のプロバイダの認証ポリシ要件に応答して、第１のユーザの識別子およびユーザが入力した検証情報を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、
   前記認証サーバは、前記送信された第１のユーザの識別子を前記格納された第１のユーザの識別子と照合し、前記送信された検証情報が前記格納された第１のサービスプロバイダの認証ポリシ要件に一致することを決定し、かつ前記第１のユーザを認証するために、前記送信された検証情報を前記第１のユーザの識別子に関連づけて格納されている前記検証情報と比較するように、さらに構成され、
   前記第２のデバイスは、前記ネットワークを介して前記認証サーバへ、前記転送されたランダム数および前記さらに送信された他の情報を含み、前記第１のユーザの認証情報で署名されたメッセージを送信するように、さらに構成され、かつ、
   前記認証サーバは、前記ネットワークを介して前記ネットワークサーバへ、前記第１のユーザの認証の通知を送信し、かつ受信された、前記署名入りメッセージをさらに送信するように、さらに構成される、ネットワークシステム。
2. 前記第１のユーザの認証情報は、前記複数の異なるサービスプロバイダのうちの前記第１のプロバイダのみに関連づけられて他のサービスプロバイダには関連づけられない前記第１のユーザの認証情報であり、
   前記ランダム数は、セッション識別子であり、かつ、
   前記他の情報は、他のランダム数である、請求項１に記載のネットワークシステム。
3. 前記第２のデバイスは、前記第１のユーザの認証情報を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、かつ、
   前記認証サーバは、前記第１のユーザの認証情報を前記第１のユーザの識別子に関連づけて格納するように、かつ前記第１のユーザをさらに認証するために、前記送信された署名入りメッセージにおける前記ランダム数および前記他の情報を、前記格納された第１のユーザの認証情報を前記受信された署名入りメッセージへ適用することによって検査するように、さらに構成される、請求項１に記載のネットワークシステム。
4. 前記格納された第１のユーザの認証情報は、前記第１のユーザの秘密／公開鍵ペアのうちの公開鍵であり、前記第１のユーザの秘密／公開鍵ペアのうちの秘密鍵は、前記第１のユーザにのみ知られ、かつ前記送信される署名入りメッセージは、前記秘密鍵で署名され、かつ、
   前記認証サーバは、さらに、前記ネットワークを介して前記第１のサービスプロバイダへ、前記第１のユーザの公開鍵を含みかつ前記認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された証書を、認証の前記通知および前記受信された署名入りメッセージと共に送信する、請求項３に記載のネットワークシステム。
5. 前記第１のユーザの秘密／公開鍵ペアは、前記複数のサービスプロバイダのうちの前記第１のプロバイダのみに関連づけられかつ他のプロバイダには関連づけられない第１のユーザの第１の秘密／公開鍵ペアである、請求項４に記載のネットワークシステム。
6. 前記認証サーバは、前記第１のユーザの認証情報が危険に曝されているという通知を受信し、かつ前記受信された通知に応答して、前記格納された第１のユーザの認証情報を無効にするように、さらに構成される、請求項３に記載のネットワークシステム。
7. 前記第１のデバイスは、前記ネットワークを介して前記第１のサービスプロバイダへ他のログイン要求を送信するように、さらに構成され、
   前記ネットワークサーバは、前記ネットワークを介して前記認証サーバへ、（ｉ）他のランダム数を求める他の要求、および（ｉｉ）さらに他の情報、を送信するように、さらに構成され、前記認証サーバは、前記送信された他のランダム数要求に応答して他のランダム数を、前記ネットワークを介して前記ネットワークサーバへ送信するように、さらに構成され、前記ネットワークサーバは、前記送信された他のログイン要求に応答して、前記送信された他のランダム数を、前記ネットワークを介して前記第１のデバイスへさらに送信するように、さらに構成され、
   前記第２のデバイスは、前記さらに送信された他のランダム数を前記第１のデバイスから自身へ転送する入力を受信し、前記転送された他のランダム数および前記第１のユーザの他の認証要求を、前記ネットワークを介して前記認証サーバへさらに送信するように、さらに構成され、
   前記認証サーバは、前記第２のデバイスによる前記他のランダム数および他の認証要求の送信の後に、前記格納された第１のプロバイダの識別子および前記格納されかつ関連づけられた第１のプロバイダの認証ポリシ要件を、前記ネットワークを介して前記第２のデバイスへ再度送信し、かつ前記送信されたさらに他の情報をさらに送信するように、さらに構成され、
   前記第２のデバイスは、前記再度送信された第１のプロバイダの認証ポリシ要件に応答して、前記第１のユーザの識別子およびユーザが入力した検証情報を、前記ネットワークを介して前記認証サーバへ再度送信するように、さらに構成され、かつ、
   前記認証サーバは、前記再度送信された第１のユーザの識別子を前記格納された第１のユーザの識別子と照合し、前記再度送信された検証情報が前記格納された第１のサービスプロバイダの認証ポリシ要件に一致することを決定し、前記第１のユーザを認証するために、前記再度送信された検証情報を前記第１のユーザの識別子に関連づけて格納されている前記検証情報と比較し、かつ、前記認証サーバが前記格納された第１のユーザの認証情報を無効にした後、前記格納された第１のユーザの認証情報が無効であると決定するように、さらに構成される、請求項６に記載のネットワークシステム。
8. 前記認証サーバは、前記格納された第１のユーザの認証情報が無効であると決定した後、前記ネットワークを介して前記第１のサービスプロバイダへ、前記検証情報に基づく前記第１のユーザの認証の通知、および前記第１のユーザの認証情報の無効性の通知を送信するように、さらに構成される、請求項に７記載のネットワークシステム。
9. 前記認証サーバは、前記格納された第１のユーザの認証情報が無効であると決定した後、前記ネットワークを介して前記第２のデバイスへ代替認証情報要求を送信するように、さらに構成され、
   前記第２のデバイスは、前記送信された代替認証情報要求に応答して代替認証情報を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、かつ、
   前記認証サーバは、前記送信された代替認証情報を前記第１のユーザの識別子に関連づけて格納し、前記送信された代替認証情報の証書を生成し、かつ前記ネットワークを介して前記第２のデバイスへ、前記生成された証書を前記第１のサービスプロバイダによる前記第１のユーザの再登録に使用するために送信するように、さらに構成される、請求項７に記載のネットワークシステム。
10. 前記第２のデバイスは、前記ネットワークを介して前記認証サーバへ、前記他のランダム数および前記さらに他の情報を含み、前記第１のユーザの前記代替認証情報で署名された他のメッセージを送信するように、さらに構成され、かつ、
    前記認証サーバは、（ｉ）前記格納された第１のユーザの代替認証情報を前記受信された他の署名入りメッセージに適用することにより、前記他のランダム数および前記さらに他の情報を検査して前記第１のユーザをさらに認証し、かつ（ｉｉ）前記第１のユーザの認証通知および前記他の署名入りメッセージを、前記ネットワークを介して前記ネットワークサーバへ送信するように、さらに構成される、請求項９に記載のネットワークシステム。
11. 前記第２のデバイスは、前記ネットワークを介して前記認証サーバへ前記第１のユーザの他の認証情報を送信するように、さらに構成され、かつ前記認証サーバは、前記受信された第１のユーザの他の認証情報を前記第１のユーザの他の識別子に関連づけて格納するように、さらに構成され、かつ、
    前記複数の異なるサービスプロバイダのうちの第２のサービスプロバイダに関連づけられ、かつ前記ネットワークを介して前記認証サーバへ、（ｉ）他のランダム数を求める要求と、（ｉｉ）さらに他の情報と、を送信するように構成される他のネットワークサーバをさらに備え、
    前記認証サーバは、前記送信された他のランダム数の要求に応答して、他のランダム数を、前記ネットワークを介して前記他のネットワークサーバへ送信するように、さらに構成され、
    前記第１のデバイスは、前記ネットワークを介して前記第２のサービスプロバイダへ他のログイン要求を送信するように、さらに構成され、
    前記他のネットワークサーバは、前記送信された他のログイン要求に応答して、前記送信された他のランダム数を、前記ネットワークを介して前記第１のデバイスへさらに送信するように、さらに構成され、
    前記第２のデバイスは、前記さらに送信された他のランダム数を前記第１のデバイスから自身へ転送する入力を受信するように、かつ前記入力された他のランダム数および前記第１のユーザの他の認証要求を、前記ネットワークを介して前記認証サーバへさらに送信するように、さらに構成され、
    前記認証サーバは、前記第２のデバイスによる前記他のランダム数および他の認証要求の送信の後、前記ネットワークを介して前記第２のデバイスへ、前記格納された第２のプロバイダの識別子および前記格納されかつ関連づけられた第２のプロバイダの認証ポリシ要件を送信するように、かつ前記送信されたさらに他の情報をさらに送信するように、さらに構成され、
    前記第２のデバイスは、前記送信された第２のプロバイダの認証ポリシ要件に応答して、前記第１のユーザの他の識別子およびユーザが入力した他の検証情報を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、
    前記認証サーバは、前記送信された第１のユーザの他の識別子を前記格納された第１のユーザの他の識別子と照合し、前記送信された他の検証情報が前記格納された第２のサービスプロバイダの認証ポリシ要件に一致することを決定し、かつ前記第１のユーザを認証するために、前記送信された他の検証情報を前記第１のユーザの他の識別子に関連づけて格納されている前記検証情報と比較するように、さらに構成され、
    前記第２のデバイスは、前記送信された他のランダム数および前記さらに送信されたさらに他の情報を含み、前記第１のユーザの他の認証情報で署名された他のメッセージを、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、かつ、
    前記認証サーバは、前記ネットワークを介して前記他のネットワークサーバへ、前記第１のユーザの他の認証通知を送信し、かつ前記受信された他の署名入りメッセージをさらに送信するように、さらに構成される、請求項３に記載のネットワークシステム。
12. 前記第２のデバイスは、前記ネットワークを介して前記認証サーバへ、第１のユーザの認証ポリシ要件を送信するように、さらに構成され、かつ、
    前記認証サーバは、前記送信された第１のユーザの認証ポリシ要件を格納し、前記格納された第１のプロバイダの認証ポリシ要件を前記格納された第１のユーザの認証ポリシ要件と比較し、前記比較に基づいて、任意の追加的な認証ポリシ要件を決定し、決定された任意の追加的な認証ポリシ要件を、前記ネットワークを介して前記第２のデバイスへ送信し、かつ、さらに、前記第２のデバイスにより送信された前記検証情報が決定された任意の追加的な認証ポリシ要件に一致することを決定するように、さらに構成される、請求項１に記載のネットワークシステム。
13. 前記第２のデバイスは、前記第１のユーザの秘密データを生成し、前記秘密データを複数の部分に分割し、前記第１のユーザの認証情報を前記秘密データで暗号化し、前記暗号化された認証情報を格納し、かつ前記複数の秘密データ部分のうちの第１の部分を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、
    前記認証サーバは、前記送信された第１の秘密データ部分を格納し、かつ前記格納された第１の秘密データ部分を、前記第１のユーザの認証後に、前記ネットワークを介して前記第２のデバイスへ送信するように、さらに構成され、
    前記第２のデバイスは、前記認証サーバにより送信された前記第１の秘密データ部分を前記他の秘密データ部分に結合して秘密データ全体を取得し、かつ前記格納されている暗号化された認証情報を前記取得された秘密データで復号するように、さらに構成され、かつ、
    前記署名入りメッセージは、前記復号された認証情報で署名される、請求項１に記載のネットワークシステム。
14. 前記ネットワークサーバは、前記ネットワークを介して前記認証サーバへ、前記第１のサービスプロバイダの識別子、トランザクション識別子、トランザクション認証要件および前記トランザクションに関するメッセージを送信するように、さらに構成され、前記メッセージは、前記第１のユーザの秘密／公開鍵ペアのうちの公開鍵を用いて暗号化され、前記第１のユーザの秘密／公開鍵ペアのうちの秘密鍵は、前記第１のユーザにのみ知られ、かつ前記メッセージは、前記第１のサービスプロバイダの秘密／公開鍵ペアのうちの秘密鍵で署名もされ、前記第１のサービスプロバイダの秘密／公開鍵ペアのうちの公開鍵は、前記第１のユーザに知られ、
    前記認証サーバは、前記ネットワークを介して前記第２のデバイスへ、前記送信されたトランザクション識別子、トランザクション認証要件、および暗号化された署名入りメッセージをさらに送信するように、さらに構成され、
    前記第２のデバイスは、前記トランザクション識別子、トランザクション認証要件および暗号化された署名入りメッセージの送信後、トランザクション承認及び認証情報のうちの少なくとも一方を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、かつ、
    前記認証サーバは、（ａ）前記トランザクション承認および前記認証情報のうちの前記受信された少なくとも一方に基づいて、（ｉ）前記識別されたトランザクションが前記第１のユーザによって承認されること、および（ｉｉ）前記第１のユーザが真正であること、のうちの少なくとも１つを決定するように、かつ（ｂ）前記決定の通知を、前記ネットワークを介して前記ネットワークサーバおよび前記第１のデバイスのうちの少なくとも一方へ送信するように、さらに構成される、請求項１に記載のネットワークシステム。
15. 前記第１のユーザデバイスおよび前記第２のユーザデバイスは、同じデバイスであり、
    前記ランダム数は、セッション識別子として機能し、かつ、
    前記他の情報は、他のランダム数である、請求項１に記載のネットワークシステム。
16. 前記第１のデバイスは、前記ネットワークサーバからの前記さらに送信されたランダム数を視覚的に表示するようにさらに構成され、
    前記さらに送信されたランダム数は、光学コードの形式であり、かつ、
    前記第２のデバイスは、カメラを含み、かつ前記さらに送信されたランダム数に一致する前記受信される入力は、前記カメラを介して、前記提示された光学コードのデジタル画像として受信される、請求項１に記載のネットワークシステム。
17. 前記認証サーバは、前記複数の異なるサービスプロバイダの各々の前記プロバイダ識別子を、前記該当するサービスプロバイダのプロバイダ・登録データ要件に関連づけて格納するように、さらに構成され、
    前記第２のデバイスは、（ｉ）ユーザが入力したユーザ識別セット、ユーザが入力した登録データ、および前記受信された識別セットにおける個々の識別に関連づけられるべき前記入力された登録データのうちでユーザが選択した特定のデータ、を受信し、かつ（ｉｉ）個々の識別を、その識別に関連づけられるべく選択された前記特定の登録データに関連づけて格納するように、さらに構成され、
    前記第１のデバイスは、前記ネットワークを介して登録要求を前記ネットワークサーバへ送信するように、さらに構成され、
    前記ネットワークサーバは、前記ネットワークを介して前記認証サーバへ、他のランダム数の要求を送信するように、さらに構成され、
    前記認証サーバは、前記送信された他のランダム数の要求に応答して、他のランダム数を、前記ネットワークを介して前記ネットワークサーバへ送信するように、さらに構成され、
    前記ネットワークサーバは、前記送信された登録要求に応答して、前記送信された他のランダム数を、前記ネットワークを介して前記第１のデバイスへさらに送信するように、さらに構成され、
    前記第２のデバイスは、前記さらに送信された他のランダム数を前記第１のデバイスから自身へ転送する入力を受信し、かつ、前記入力された他のランダム数、および前記第１のサービスプロバイダによって登録されるべき前記第１のユーザの要求を、前記ネットワークを介して前記認証サーバへさらに送信するように、さらに構成され、
    前記認証サーバは、前記第２のデバイスによる前記他のランダム数および登録要求の送信の後、前記格納された第１のプロバイダの識別子、および前記格納されかつ関連づけられた第１のプロバイダの登録データ要件を、前記ネットワークを介して前記第２のデバイスへ送信するように、さらに構成され、
    前記第２のデバイスは、前記格納されたユーザ識別のうちの１つを選択するユーザ入力を受信し、前記選択されて入力された識別に応答して、前記選択されたユーザ識別に関連づけて格納された前記特定の登録データを自動的に検索し、かつ前記検索された登録データを、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、
    前記認証サーバは、前記送信された登録データが、前記格納された第１のサービスプロバイダの登録データ要件に一致することを決定し、かつ前記第１のサービスプロバイダによって前記第１のユーザを登録するために、前記送信された登録データを、前記ネットワークを介して前記ネットワークサーバへさらに送信するように、さらに構成される、請求項１に記載のネットワークシステム。
18. 前記ネットワークサーバは、登録要求および前記第１のサービスプロバイダの秘密／公開鍵ペアのうちの公開鍵を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、前記第１のサービスプロバイダの秘密／公開鍵ペアのうちの秘密鍵は、前記ネットワークサーバにのみ知られ、かつ、
    前記認証サーバは、（ｉ）前記送信された第１のプロバイダの公開鍵を格納し、かつ（ｉｉ）前記認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された、前記第１のプロバイダの公開鍵を含む証書を、前記ネットワークを介して前記ネットワークサーバへ送信するように、さらに構成され、前記認証サーバの秘密／公開鍵ペアのうちの公開鍵は、前記ネットワークサーバに知られる、請求項１に記載のネットワークシステム。
19. 前記第２のデバイスは、登録要求および前記第１のユーザの秘密／公開鍵ペアのうちの公開鍵を、前記ネットワークを介して前記認証サーバへ送信するように、さらに構成され、前記第１のユーザの秘密／公開鍵ペアのうちの前記秘密鍵は、前記第２のデバイスにのみ知られ、かつ、
    前記認証サーバは、（ｉ）前記送信された第１のユーザの公開鍵を格納し、かつ（ｉｉ）前記認証サーバの秘密鍵で署名された、前記第１のユーザの公開鍵を含む証書を、前記ネットワークを介して前記第２のデバイスへ送信するように、さらに構成され、前記認証サーバの秘密／公開鍵ペアのうちの前記公開鍵は、前記第２のデバイスに知られる、請求項１８に記載のネットワークシステム。