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

Description

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

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

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

本発明の所定の態様によれば、複数の異なるユーザは何れも、複数の異なるネットワーク・サービス・プロバイダの何れに対しても、例えばインターネットであるネットワークを介して、認証サーバにより認証されることが可能である。これを行うために、認証サーバは、ユーザ毎に、そのユーザの識別子に関連づけて、例えばパスワード、他の知識ベースデータ、トークンおよび／または生体データを含む検証情報を格納すべく動作する。認証サーバは、該当するプロバイダの識別子に関連づけて、複数の異なるサービスプロバイダの各々の認証ポリシ要件も格納する。このような認証要件ポリシは、典型的には、サービスプロバイダが要求する、検証情報および認証情報の種類を含む１つまたは複数の種類の認証ファクタが、サービスプロバイダのネットワークサイト上で入手可能な所定の情報へのアクセスを求めているユーザの認証に使用されることを命じる。当業者は、単一のサービスプロバイダが、異なるアクセスレベル毎に異なる認証ポリシ要件を有し得ることを認識するであろう。また、ある特定のプロバイダの認証要件ポリシは、ユーザによるいかなるタイプの検証情報の提供をも要求しない場合があることも理解されるべきである。

プロバイダに対してユーザを認証するために、認証サーバは、ネットワークを介してプロバイダから情報の要求、最も典型的には、かつ以下の説明を目的として、ランダム数を受信し、かつこれに応答して、ネットワークを介してプロバイダへランダム数を送信する。好ましくは、ランダム数は、セッション識別子として機能する。認証サーバは、プロバイダへ、所望されれば、単一の要求に対して複数のランダム数を送信することも可能である点は、理解されるべきである。

認証サーバは、ネットワークを介してプロバイダから、同じくランダム数である可能性もある他の情報を受信する。前記他の情報を、活性識別子と称することもある。

サービスプロバイダへランダム数を送信した後、認証サーバは、ネットワークを介して要求ユーザからランダム数および認証要求を受信する。メッセージングプロトコルは、当業者には認識されるであろうが、容易に修正される可能性もあり、よって、プロバイダは、認証サーバへランダム数およびユーザＩＤを送ることによってログインを開始する可能性もある。これに応答して、認証サーバは、ネットワークを介して要求ユーザへ、格納されているプロバイダ識別子、受信した他の情報および格納されているプロバイダ認証ポリシ要件を送信する。これに対して、認証サーバは、ネットワークを介して要求ユーザから、ユーザ識別子および、場合により、送信された認証ポリシ要件が検証情報を要求しているか否かに依存して、例えばパスワード、他の知識ベースデータ、トークンおよび／または生体データを有する検証情報を受信する。

認証サーバは、次に、受信したユーザ識別子を、格納されている該当するユーザ識別子と照合し、要求ユーザからの任意の検証情報が、格納されているプロバイダ認証ポリシ要件に一致していること、即ちポリシにより要求されたタイプの検証情報が要求ユーザから受信されていることを決定し、かつ受信された任意の検証情報を、格納されている該当ユーザの検証情報と比較して、要求ユーザが該当ユーザであること、即ちこのユーザがまさしく、ユーザが言うところのユーザ自身であることを認証する。

認証サーバは、ネットワークを介して要求ユーザから、ユーザ認証情報を用いて署名された、ランダム数および他の情報を含むメッセージを受信する。認証サーバは、次に、ネットワークを介してプロバイダへ、ユーザの認証通知および前記署名入りメッセージを送信する。

好ましくは、認証サーバは、ネットワークを介して該当する各ユーザから、ユーザの認証情報を受信し、かつ受信したユーザ認証情報を、該当ユーザ識別子に関連づけて格納する。そうであれば、認証サーバは、要求ユーザを該当ユーザとしてさらに認証するために、格納されている該当ユーザ認証情報を受信された署名入りメッセージへ適用することによってランダム数および他の情報を効果的に検査することができる。各ユーザが、単一の認証情報を有しても、多くの異なる認証情報を有してもよいことは理解されるべきである。例えば、一ユーザは、如何なる性質のビジネスであれユーザの取引相手である複数の異なるサービスプロバイダによって使用される単一のユーザ認証情報を有してもよい。一方で、他のユーザは、このユーザの取引相手である各サービスプロバイダによって使用される異なる個々のユーザ認証情報を有してもよい。事実上、所望されれば、ユーザは、同一のサービスプロバイダのネットワークサイトにおける異なる情報へアクセスするために、異なるユーザ認証情報を有してもよい。

ある特に好適な実施態様では、格納されるユーザ認証情報は、該当ユーザの秘密／公開鍵ペアのうちの公開鍵である。受信されるユーザ認証情報は、該当する秘密／公開鍵ペアのうちの、ユーザのみが知る秘密鍵であり、受信される署名入りメッセージは、この秘密鍵で署名される。このような場合、認証サーバは、該当ユーザの公開鍵を含みかつ認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された証書を、認証通知および受信した署名入りメッセージと共に送信する。他のタイプのユーザ認証情報の場合と同様に、特定のユーザは、複数の異なるサービスプロバイダに対する認証を、単一の秘密／公開鍵ペアを用いて行ってもよく、複数の異なるサービスプロバイダの各々に対する認証を、異なる秘密／公開鍵ペアを用いて行ってもよい。

効果的には、認証サーバは、ネットワークを介して各ユーザから、該当ユーザの秘密データの複数の部分のうちの第１の部分を受信しかつこれを格納する。秘密データは、例えば、拡張および／またはハッシュ化されたパスワードである可能性もある。該当する検証情報（もしあれば）に基づいて要求ユーザが該当ユーザであることを認証すると、認証サーバは、次に、ネットワークを介して要求ユーザへ、格納されている該当する秘密データの第１の部分を送信し、かつこの秘密データの第１の部分の送信後に、署名入りメッセージが受信される。

本発明の他の有益な態様によれば、認証サーバは、先の記述と同様に、ネットワークを介してプロバイダからランダム数の要求を受信し、かつ他の情報を受信してもよく、かつこれに応答して、ネットワークを介してプロバイダへランダム数を送信する。この場合、ランダム数は、登録セッション識別子として機能する。ランダム数をサービスプロバイダへ送信した後、認証サーバは、ネットワークを介して要求ユーザからランダム数およびサービスプロバイダにおいて登録されるよう求める要求を受信する。これに応答して、認証サーバは、ネットワークを介して要求ユーザへ、格納されているプロバイダ識別子および格納されているプロバイダ認証ポリシ要件を送信する。認証サーバは、これに対して、ネットワークを介して要求ユーザから、ユーザ識別子、および場合により、送信された認証ポリシ要件が検証情報を要求しているか否かに依存して、パスワード、他の知識ベースデータ、トークンおよび／または生体データを有する検証情報、およびユーザとサービスプロバイダとの間で使用するための新しい認証情報を受信する。認証情報が公開／秘密鍵ペアである場合、公開鍵は、証書署名要求と共に認証サーバへ送信される。認証サーバは、次に、受信したユーザ識別子を、格納されている該当ユーザ識別子と照合し、要求ユーザからの任意の検証情報が、格納されているプロバイダ認証ポリシ要件に一致していること、即ちポリシにより要求されたタイプの検証情報が要求ユーザから受信されていることを決定し、かつ受信された任意の検証情報を、格納されている該当ユーザの検証情報と比較して、要求ユーザが該当ユーザであること、即ちこのユーザがまさしく、ユーザが言うところのユーザ自身であることを認証する。ユーザ認証情報が公開／秘密鍵ペアであれば、認証サーバは、ユーザへ署名入りの証書を送信する。

認証サーバは、ネットワークを介して要求ユーザへ、受信した他の情報を送信し、かつネットワークを介して要求ユーザから、新しいユーザ認証情報を用いて署名された、ランダム数および他の情報を含むメッセージを受信する。認証サーバは、次に、ネットワークを介してプロバイダへ、ユーザの登録の通知、ユーザ認証情報および署名入りメッセージを送信する。

本発明の他の有益な態様によれば、認証サーバは、該当ユーザから、ユーザの認証情報が危険に曝されている、という通知を受信してもよい。危うくされていれば、認証サーバは、受信した通知に応答して、格納されている該当ユーザ認証情報を無効にする。無効化は、認証情報の削除または認証情報を無効としてフラグを立てること、を含む様々な方法で実行されることが可能である。

例えば、先に論じた認証に使用される格納されたユーザ認証情報を、このような通知に基づいて無効にした後、認証サーバは、ネットワークを介して、先に論じた認証が行われた対象であるプロバイダからランダム数に対する他の要求を受信してもよい。これに応答して、認証サーバは、ネットワークを介してプロバイダへ、以下、本セクションにおいて第２のランダム数と称する他のランダム数を送信する。また、認証サーバは、ネットワークを介してプロバイダから、以下、本セクションにおいて第２の他の情報と称するさらに他の情報も受信する。認証サーバは、さらに、ネットワークを介して要求ユーザから、第２のランダム数および認証要求を受信する。

認証サーバは、第２のランダム数および認証要求の受信に応答して、ネットワークを介してこの要求ユーザへ、格納されているプロバイダ識別子、受信した第２の他の情報および格納されているプロバイダ認証ポリシ要件を再送信する。再送信されたこのプロバイダ認証ポリシ要件に応答して、認証サーバは、ネットワークを介してこの要求ユーザから、他のユーザ識別子、および場合により、再送信されたこの認証ポリシ要件が検証情報を要求しているか否かに依存して、例えばパスワード、他の知識ベースデータ、トークンおよび／または生体データを有する他の検証情報を受信する。

認証サーバは、次に、受信した他のユーザ識別子を、格納されている上述のものと同じユーザ識別子（即ち、先に認証されたものと同じユーザの識別子）と照合し、この要求ユーザからの他の検証情報が、もしあれば、格納されている上述のものと同じプロバイダ認証ポリシ要件に一致することを決定し、かつ、受信した任意の他の検証情報を、格納されている該当ユーザ検証情報と比較して、この要求ユーザが先に認証されたものと同じユーザであることを認証する。しかしながらこの場合、認証サーバは、さらに、ユーザの認証情報が危うくされているという通知を認証サーバが受信するより前にこの同じサービスプロバイダに対してユーザを認証する上で有効であった格納されている該当ユーザ認証情報は、もはや無効であることを決定する。

格納されている該当ユーザ認証情報が無効であると決定した後、認証サーバは、様々な方法へと進むことができる。認証サーバは、ネットワークを介してプロバイダへ、例えば受信した検証情報に基づいて、要求ユーザが先と同じユーザであるという認証通知だけでなく、認証サーバは、ユーザ認証情報の無効に起因して該当ユーザをさらに認定することができない、という通知も送信してもよい。

あるいは、または追加的に、格納されている要求ユーザの認証情報が無効であることを決定した後、認証サーバは、ネットワークを介して要求ユーザへ、差替認証情報要求を送信してもよい。これに応答して、認証サーバは、ネットワークを介して要求ユーザから差替認証情報を受信し、かつこれを格納する。受信した認証情報が公開鍵であれば、認証サーバは、受信したユーザ差替認証情報の証書を生成し、かつこれを、プロバイダによる再登録においてこのユーザが使用するために、ネットワークを介して要求ユーザへ送信してもよい。

またさらに、差替認証情報を受信した後、認証サーバは、効果的には、ネットワークを介して要求ユーザから、要求ユーザにより認証情報を用いて署名された、第２のランダム数および第２の他の情報を含む他のメッセージを受信してもよい。認証サーバは、要求ユーザを同じユーザ（即ち、先に最初に認証されたユーザ自身）としてさらに認証するために、この第２のランダム数および第２の他の情報を、受信した他の署名入りメッセージに、格納されている差替認証情報を適用することによって検査する。また、認証サーバは、ネットワークを介してプロバイダへ、要求ユーザの認証通知および他の署名入りメッセージを送信する。

先に述べたように、異なるサービスプロバイダに対する認証を行うために、同一のユーザが異なる認証情報を有してもよい。上述の認証されたユーザがこの種のユーザであれば、認証サーバは、ネットワークを介してこの同じユーザ（即ち、先に認証されたユーザ自身）から、このユーザの他の認証情報も受信し、かつこの受信した他の認証情報、および場合により、このユーザの他の識別子に関するこのユーザ自身の検証情報を格納する。また、認証サーバは、前記他のプロバイダの識別子に関連づけて、複数のサービスプロバイダのうちの他のサービスプロバイダの認証ポリシ要件を格納する。

認証サーバは、次に、ネットワークを介して前記他のプロバイダから、ランダム数に対する他の要求を受信する。これに応答して、認証サーバは、ネットワークを介して前記他のプロバイダへ、以下、本セクションにおいて第３のランダム数と称するさらに他のランダム数を送信する。また、認証サーバは、ネットワークを介して前記他のプロバイダから、以下、本セクションにおいて第３の他の情報と称するさらに他の情報を受信する。

認証サーバは、ネットワークを介して要求ユーザから、第３のランダム数、およびこの要求ユーザの認証要求を受信する。これに応答して、認証サーバは、ネットワークを介してこの要求ユーザへ、格納されている他のプロバイダの識別子、受信した第３の他の情報および前記他のプロバイダの認証ポリシ要件を送信する。

送信された他のプロバイダの認証ポリシ要件に応答して、認証サーバは、ネットワークを介してこの要求ユーザから、他のユーザ識別子、および場合により、送信された他のプロバイダの認証ポリシ要件が検証情報を要求しているか否かに依存して、例えばパスワード、他の知識ベースデータ、トークンおよび／または生体データを有する他の検証情報を受信する。認証サーバは、次に、受信した他のユーザ識別子を、格納されている他のユーザ識別子と照合し、この要求ユーザから受信した他の任意の検証情報が、格納されている他のプロバイダの認証ポリシ要件に一致することを決定し、かつ、受信した他の検証情報を、格納されている該当ユーザ検証情報と比較して、この要求ユーザが先に認証されたユーザ自身であることを認証する。

認証サーバは、ネットワークを介してこの要求ユーザから、認証情報を用いて署名された、第３のランダム数および第３の他の情報を含む他のメッセージを受信する。認証サーバは、場合により、この要求ユーザが同じユーザであることをさらに認証するために、この第３のランダム数および第３の他の情報を、格納されている同じユーザの他の認証情報をこの受信した他の署名入りメッセージへ適用することによって検査する。認証サーバは、次に、ネットワークを介して前記他のプロバイダへ、要求ユーザの認証通知および受信した他の署名入りメッセージを送信する。

本発明のさらに他の好適な態様によれば、認証サーバは、ネットワークを介してユーザから、ユーザ認証ポリシ要件を受信し、かつこれを格納することができる。このような場合、認証サーバは、次に、格納されている該当するプロバイダの認証ポリシ要件を、格納されている該当するユーザの認証ポリシ要件と比較し、この比較に基づいて、ユーザが要求する任意の追加的な認証ポリシ要件を決定することができる。認証サーバは、ネットワークを介して要求ユーザへ、決定された任意の追加的認証ポリシ要件を、送信されたプロバイダ識別子およびプロバイダ認証ポリシ要件と共に送信する。また、認証サーバは、ユーザを認証するために、要求ユーザから受信された検証情報が、送信された任意の追加的な認証ポリシ要件に一致することも決定しなければならない。

本発明のさらに他の態様によれば、認証サーバは、ネットワークを介して第２のネットワークエンティティ、例えばサービスプロバイダから、第１のネットワークエンティティ、例えばユーザの識別子、トランザクション識別子、トランザクションの承認および認証要件、および例えばトランザクションの詳細を含む可能性もあるトランザクション関連メッセージを受信することにより、ネットワークを介して第１のネットワークエンティティにトランザクションを通知するように動作される。メッセージは、第１のネットワークエンティティの認証情報によって暗号化される。認証情報が第１のネットワークエンティティの秘密／公開鍵ペアのうちの公開鍵であれば、第１のネットワークエンティティの秘密／公開鍵ペアのうちの秘密鍵は、前記ネットワークエンティティにのみ知られる。メッセージは、第２のネットワークエンティティの秘密／公開鍵ペアのうちの秘密鍵によっても署名される。第２のネットワークエンティティの秘密／公開鍵ペアのうちの公開鍵は、第１のネットワークエンティティに知られる。

認証サーバは、ネットワークを介して第１のネットワークエンティティへ、受信したトランザクション識別子、トランザクションの承認および認証要件および暗号化された署名入りメッセージを送信する。これに応答して、認証サーバは、ネットワークを介して第１のネットワークエンティティから、何が要求されているかに依存して、トランザクション承認、または検証情報および／または認証情報等の認証情報、またはこれらの双方を受信する。認証サーバは、次に、受信した任意の認証情報に基づいて、第１のネットワークエンティティが真正であることを決定する。認証サーバは、ネットワークを介して第２のネットワークエンティティへ、前記決定の通知または受信したトランザクション、またはこれらの双方を送信する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (19)

1. ネットワークを介して、複数の異なるユーザのうちの任意のユーザを複数の異なるサービスプロバイダに対して認証することができる認証サーバを動作させる方法であって、
   第１のユーザの検証情報を、前記第１のユーザの識別子と関連づけて格納することと、
   前記複数のサービスプロバイダのうちの第１のプロバイダの認証ポリシ要件を、前記第１のプロバイダの識別子に関連づけて格納することと、
   前記ネットワークを介して前記第１のプロバイダへ、第１のランダム数を送信することと、
   前記ネットワークを介して前記第１のプロバイダから、第１の他の情報を受信することと、
   前記ネットワークを介して要求ユーザから、前記第１のランダム数と、そのユーザの認証要求とを受信することと、
   前記第１のランダム数および認証要求を受信した後、前記ネットワークを介して前記要求ユーザへ、前記格納された第１のプロバイダの識別子と、前記受信された第１の他の情報と、前記格納された第１のプロバイダの認証ポリシ要件とを送信することと、
   前記送信された第１のプロバイダの認証ポリシ要件に応答して、前記ネットワークを介して前記要求ユーザから、ユーザ識別子と、検証情報とを受信することと、
   前記受信された要求ユーザ識別子を前記格納された第１のユーザの識別子と照合することと、
   前記要求ユーザから受信された前記検証情報が、前記格納された第１のプロバイダの認証ポリシ要件に一致することを決定することと、
   前記要求ユーザが前記第１のユーザであることを認証するために、前記受信された要求ユーザ識別子を前記格納された第１のユーザの識別子と照合することと、前記要求ユーザから受信された前記検証情報が、前記格納された第１のプロバイダの認証ポリシ要件に一致することを決定することとが、成功したことを条件として、前記要求ユーザから受信された前記検証情報を前記格納された第１のユーザの検証情報と比較することと、
   前記ネットワークを介して前記要求ユーザから、前記要求ユーザの認証情報で署名された、前記第１のランダム数と前記第１の他の情報とを含むメッセージを受信することと、
   前記ネットワークを介して前記第１のプロバイダへ、前記第１のユーザの認証の通知と、前記受信された署名入りメッセージとを送信すること、を含む方法。
2. 前記要求ユーザの認証情報は、前記第１のユーザの、前記第１のプロバイダのみに関連づけられ、前記複数のサービスプロバイダのうちの他のプロバイダに関連づけられない認証情報であり、
   前記第１のランダム数は、セッション識別子であり、かつ、
   前記第１の他の情報は、第２のランダム数である、請求項１に記載の方法。
3. 前記ネットワークを介して前記第１のユーザから、前記第１のユーザの認証情報を受信することと、
   前記受信された第１のユーザの認証情報を格納することと、
   前記要求ユーザを前記第１のユーザとしてさらに認証するために、前記第１のランダム数および前記第１の他の情報を、前記格納された第１のユーザの認証情報を前記受信された署名入りメッセージに適用することによって検査すること、をさらに含む、請求項１に記載の方法。
4. 前記受信された第１のユーザの認証情報は、前記第１のユーザの秘密／公開鍵ペアのうちの公開鍵であり、前記第１のユーザの秘密／公開鍵ペアの秘密鍵は、前記第１のユーザにのみ知られ、かつ前記受信された署名入りメッセージは、前記秘密鍵で署名され、さらに、
   前記認証の通知および前記受信された署名入りメッセージと共に、前記第１のユーザの公開鍵を含みかつ前記認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された証書を送信することを含む、請求項３に記載の方法。
5. 前記第１のユーザの認証情報が危険に曝されているという通知を受信することと、
   前記受信された通知に応答して、前記格納された第１のユーザの認証情報を無効にすることと、
   前記格納された第１のユーザの認証情報を無効にした後、前記ネットワークを介して前記第１のプロバイダへ、第２のランダム数を送信することと、
   前記ネットワークを介して前記第１のプロバイダから、第２の他の情報を受信することと、
   前記ネットワークを介して要求ユーザから、前記第２のランダム数と、このユーザの認証要求とを受信することと、
   前記第２のランダム数およびこの認証要求を受信した後、前記ネットワークを介してこの要求ユーザへ、前記格納された第１のプロバイダの識別子と、前記受信された第２の他の情報と、前記格納された第１のプロバイダの認証ポリシ要件とを再送信することと、
   前記再送信された第１のプロバイダの認証ポリシ要件に応答して、前記ネットワークを介してこの要求ユーザから、他のユーザ識別子と、他の検証情報とを受信することと、
   前記受信された他のユーザ識別子を前記格納された第１のユーザの識別子と照合することと、
   前記受信された他の検証情報が、前記格納された第１のプロバイダの認証ポリシ要件に一致することを決定することと、
   この要求ユーザが前記第１のユーザであることを認証するために、前記受信された他のユーザ識別子を前記格納された第１のユーザの識別子と照合することと、前記受信された他の検証情報が、前記格納された第１のプロバイダの認証ポリシ要件に一致することを決定することとが、成功したことを条件として、前記受信された他の検証情報を前記格納された第１のユーザの検証情報と比較することと、
   前記格納された第１のユーザの認証情報が無効であることを決定すること、をさらに含む、請求項３に記載の方法。
6. 前記格納された第１のユーザの認証情報が無効であると決定した後、前記ネットワークを介して前記第１のプロバイダへ、前記要求ユーザが前記第１のユーザであるという認証の通知、および前記第１のユーザの認証情報が無効であることに起因して前記第１のユーザのさらなる認証は不能であることの通知を送信することをさらに含む、請求項５に記載の方法。
7. 前記格納された第１のユーザの認証情報が無効であると決定した後、前記ネットワークを介して前記要求ユーザへ、交換認証情報の要求を送信することと、
   前記送信された前記交換認証情報の要求に応答して、前記ネットワークを介して前記要求ユーザから、交換認証情報を受信することと、
   前記受信された交換認証情報を、前記第１のユーザの識別子に関連づけて格納することと、
   前記受信された交換認証情報の証書を生成することと、
   前記第１のプロバイダによる前記第１のユーザの再登録において用いるために、前記ネットワークを介して前記第１のユーザへ、前記生成された証書を送信すること、をさらに含む、請求項５に記載の方法。
8. 前記交換認証情報を受信した後、前記ネットワークを介して前記要求ユーザから、前記要求ユーザの認証情報で署名された、前記第２のランダム数および前記第２の他の情報を含む他のメッセージを受信することと、
   前記要求ユーザが前記第１のユーザであることをさらに認証するために、前記第２のランダム数および前記第２の他の情報を、前記格納された第１のユーザの交換認証情報を前記受信された他の署名入りメッセージに適用することによって検査することと、
   前記ネットワークを介して前記第１のプロバイダへ、前記第１のユーザの認証の通知および前記他の署名入りメッセージを送信すること、をさらに含む、請求項７に記載の方法。
9. 前記ネットワークを介して前記第１のユーザから、前記第１のユーザの他の認証情報を受信することと、
   前記受信された第１のユーザの他の認証情報および前記第１のユーザの検証情報を、前記第１のユーザの他の識別子に関連づけて格納することと、
   前記複数のサービスプロバイダのうちの第２のプロバイダの認証ポリシ要件を、前記第２のプロバイダの識別子に関連づけて格納することと、
   前記ネットワークを介して前記第２のプロバイダへ、第２のランダム数を送信することと、
   前記ネットワークを介して前記第２のプロバイダから、第２の他の情報を受信することと、
   前記ネットワークを介して要求ユーザから、前記第２のランダム数と、このユーザの認証要求とを受信することと、
   前記第２のランダム数およびこの認証要求を受信した後、前記ネットワークを介してこの要求ユーザへ、前記格納された第２のプロバイダの識別子と、前記受信された第２の他の情報と、前記格納された第２のプロバイダの認証ポリシ要件とを送信することと、
   前記送信された第２のプロバイダの認証ポリシ要件に応答して、他のユーザ識別子と、他の検証情報とを受信することと、
   前記受信された他のユーザ識別子を前記格納された他の第１のユーザの識別子と照合することと、
   この要求ユーザから受信された前記他の検証情報が、前記格納された第２のプロバイダの認証ポリシ要件に一致することを決定することと、
   この要求ユーザが前記第１のユーザであることを認証するために、前記受信された他のユーザ識別子を前記格納された他の第１のユーザの識別子と照合することと、この要求ユーザから受信された前記他の検証情報が、前記格納された第２のプロバイダの認証ポリシ要件に一致することを決定することとが、成功したことを条件として、前記受信された他の検証情報を前記格納された第１のユーザの検証情報と比較することと、
   前記ネットワークを介して前記要求ユーザから、当該要求ユーザの他の認証情報で署名された、前記第２のランダム数と前記第２の他の情報とを含む他のメッセージを受信することと、
   前記ネットワークを介して前記第２のプロバイダへ、前記第１のユーザの認証の通知と、前記受信された他の署名入りメッセージとを送信すること、をさらに含む、請求項１に記載の方法。
10. 前記ネットワークを介して前記第１のユーザから、第１のユーザの認証ポリシ要件を受信することと、
    前記受信された第１のユーザの認証ポリシ要件を格納することと、
    前記格納された第１のプロバイダの認証ポリシ要件を、前記格納された第１のユーザの認証ポリシ要件と比較することと、
    前記比較に基づいて、任意の追加的な認証ポリシ要件を決定することと、
    決定された任意の追加的な認証ポリシ要件を、前記ネットワークを介して前記要求ユーザへ送信することと、
    前記要求ユーザから受信された前記検証情報が、決定された任意の追加的な認証ポリシ要件に一致することも決定すること、をさらに含む、請求項１に記載の方法。
11. 前記ネットワークを介して前記第１のユーザから、前記第１のユーザの秘密データの複数の部分のうちの第１の部分を受信することと、
    前記受信された秘密データの第１の部分を格納することと、
    前記要求ユーザが前記第１のユーザであることを認証した後、前記格納された秘密データの第１の部分を、前記ネットワークを介して前記第１のユーザへ送信すること、を含み、
    前記署名入りメッセージは、前記秘密データの第１の部分の送信後に受信される、請求項１に記載の方法。
12. プログラムを記録したコンピュータ読み取り可能な記憶媒体であって、前記プログラムは、ネットワークを介して、複数の異なるユーザのうちの任意のユーザを複数の異なるサービスプロバイダのうちの任意のプロバイダに対して認証するためのものであって、前記プログラムは、コンピュータを、
    前記ネットワークを介して前記複数のプロバイダのうちの第１のプロバイダへ、第１のランダム数を送信し、
    前記ネットワークを介して前記第１のプロバイダから、第１の情報を受信し、
    前記ネットワークを介して要求ユーザから、前記第１のランダム数と、そのユーザの認証要求とを受信し、
    前記第１のランダム数および認証要求を受信した後、前記ネットワークを介して前記要求ユーザへ、第１のプロバイダの識別子と、前記受信された第１の情報と、第１のプロバイダの認証ポリシ要件とを送信し、
    前記送信された第１のプロバイダの認証ポリシ要件に応答して、前記ネットワークを介して前記要求ユーザから、ユーザ識別子と、検証情報とを受信し、
    前記受信された検証情報が、前記第１のプロバイダの認証ポリシ要件に一致することを決定し、
    前記要求ユーザが第１のユーザであることを認証するために、前記受信されたユーザ識別子に基づいて、かつ前記受信された検証情報が、前記第１のプロバイダの認証ポリシ要件に一致することを決定することが成功したことを条件として、前記受信された検証情報を前記複数のユーザのうちの前記第１のユーザの格納された検証情報と比較し、
    前記ネットワークを介して前記要求ユーザから、当該要求ユーザの認証情報で署名された、前記第１のランダム数と前記第１の情報とを含むメッセージを受信し、かつ、
    前記ネットワークを介して前記第１のプロバイダへ、前記第１のユーザの認証の通知と、前記受信された署名入りメッセージとを送信するように動作させる、記憶媒体。
13. 前記プログラムは、さらに、前記コンピュータを、
    前記要求ユーザを前記第１のユーザとしてさらに認証するために、前記受信されたユーザ識別子に基づいて、前記第１のランダム数および前記第１の情報を、前記第１のユーザの格納された認証情報を前記受信された署名入りメッセージに適用することによって検査するように動作させるべく構成される、請求項１２に記載の記憶媒体。
14. 前記格納された第１のユーザの認証情報は、前記第１のユーザの秘密／公開鍵ペアのうちの公開鍵であり、前記第１のユーザの秘密／公開鍵ペアの秘密鍵は、前記第１のユーザにのみ知られ、かつ前記受信された署名入りメッセージは、前記秘密鍵で署名され、かつ、
    前記プログラムは、さらに、前記コンピュータを、前記認証の通知および前記受信された署名入りメッセージと共に、前記第１のユーザの公開鍵を含みかつ前記認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名された証書を送信するように動作させるべく構成される、請求項１３に記載の記憶媒体。
15. 前記プログラムは、さらに、前記コンピュータを、
    前記第１のユーザの認証情報が危険に曝されているという通知を受信し、
    前記ネットワークを介して前記第１のプロバイダへ、第２のランダム数を送信し、
    前記ネットワークを介して前記第１のプロバイダから、第２の他の情報を受信し、
    前記通知を受信した後、前記ネットワークを介して要求ユーザから、前記第２のランダム数と、この要求ユーザの認証要求とを受信し、
    前記第２のランダム数および認証要求を受信した後、前記ネットワークを介してこの要求ユーザへ、前記第１のプロバイダの識別子と、前記受信された第２の他の情報と、前記第１のプロバイダの認証ポリシ要件とを再送信し、
    前記再送信された第１のプロバイダの認証ポリシ要件に応答して、前記ネットワークを介してこの要求ユーザから、他のユーザ識別子と、他の検証情報とを受信し、
    前記受信された他の検証情報が、前記第１のプロバイダの認証ポリシ要件に一致することを決定し、
    この要求ユーザが前記第１のユーザであることを認証するために、前記受信された他の検証情報を前記格納された第１のユーザの検証情報と比較し、かつ、
    前記ネットワークを介して前記第１のプロバイダへ、前記第１のユーザの認証の通知、および前記第１のユーザの認証情報が無効であるという通知を送信するように動作させるべく構成される、請求項１３に記載の記憶媒体。
16. 前記プログラムは、さらに、前記コンピュータを、
    前記ネットワークを介してこの要求ユーザへ、交換認証情報の要求を送信し、
    前記送信された前記交換認証情報の要求に応答して、前記ネットワークを介してこの要求ユーザから、交換認証情報を受信し、
    前記受信された交換認証情報を、前記第１のユーザの識別子に関連づけて格納し、
    前記受信された第１のユーザの交換認証情報の証書を生成し、
    前記第１のプロバイダによる前記第１のユーザの再登録において用いるために、前記ネットワークを介して前記第１のユーザへ、前記生成された証書を送信するように動作させるべく構成される、請求項１５に記載の記憶媒体。
17. 前記プログラムは、さらに、前記コンピュータを、
    前記生成された証書を送信した後、前記ネットワークを介してこの要求ユーザから、この要求ユーザの認証情報で署名された、前記第２のランダム数および前記第２の他の情報を含む他のメッセージを受信し、かつ、
    前記ネットワークを介して前記第１のプロバイダへ、前記他の署名入りメッセージを送信するように動作させるべく構成される、請求項１６に記載の記憶媒体。
18. 前記プログラムは、さらに、前記コンピュータを、
    前記ネットワークを介して前記第１のユーザから、第１のユーザの認証ポリシ要件を受信し、
    前記受信された第１のユーザの認証ポリシ要件を格納し、
    前記格納された第１のプロバイダの認証ポリシ要件を、前記格納された第１のユーザの認証ポリシ要件と比較し、
    前記比較に基づいて、任意の追加的な認証ポリシ要件を決定し、
    決定された任意の追加的な認証ポリシ要件を、前記ネットワークを介して前記要求ユーザへ送信し、かつ、
    前記要求ユーザから受信された前記検証情報が、決定された任意の追加的な認証ポリシ要件に一致することも決定するように動作させるべく構成される、請求項１２に記載の記憶媒体。
19. 前記プログラムは、さらに、前記コンピュータを、
    前記ネットワークを介して前記第１のユーザから、前記第１のユーザの秘密データの複数の部分のうちの第１の部分を受信し、
    前記受信された秘密データの第１の部分を格納し、かつ、
    前記要求ユーザが前記第１のユーザであることを認証した後、前記格納された秘密データの第１の部分を、前記ネットワークを介して前記第１のユーザへ送信するように動作させるべく構成され、
    前記署名入りメッセージは、前記秘密データの第１の部分の送信後に受信される、請求項１２に記載の記憶媒体。

Images