JP7774070B2 - マルチノードパーティに対するユーザ認証方法 - Google Patents

Description

発明の分野
本発明は、安全な方法で、かつユーザとＩＤプロバイダとの間の少ない相互作用で、マルチノードパーティに対してユーザを認証する方法に関する。本発明による方法は、さらに、その方法を適用するユーザに高いレベルのプライバシを提供する。

発明の背景
複数のユーザを持つほとんどのシステムでは、認証、権限付与、およびアカウンタビリティが主要なセキュリティメカニズムである。

本明細書では、「認証」という用語は、ユーザがシステムに対して自分自身を特定することを意味すると解釈されるべきものである。これは、例えば、ユーザがパスワードを入力したり、デジタル署名を提示したりすることによって直接行うことができる。あるいは、ユーザが何らかのサードパーティのＩＤプロバイダを使用して自身のＩＤを証明する、いわゆるフェデレーション認証を適用することもできる。この場合、ユーザはサードパーティのＩＤプロバイダに認証を要求し、サードパーティのＩＤプロバイダはデジタル署名されたＩＤトークンなどの形式で証明書を返す。その後、ユーザはこの証明書を使用して、システムに対する自分のＩＤを証明する。フェデレーション認証は、たとえば、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ（ＯＩＤＣ）プロトコルを使用して実行できる。

本明細書では、「権限付与」という用語は、様々なユーザのためにシステムの様々な部分へのアクセス権を管理する能力を意味すると解釈されるべきものである。これには、例えば、アクセス制御リスト（ＡＣＬ）および／またはアクセス制御マトリクス（ＡＣＭ）を使用することが含まれる。

本明細書では、「アカウンタビリティ」という用語は、システム内の様々なユーザによって行われたアクティビティを追跡する能力を意味すると解釈されるべきものである。これには、システムログや監査ログなどのアクティビティのログ記録が含まれる場合がある。

いくつかのシステムは複数のノード、例えば複数のサーバで構成されており、システムにアクセスするユーザは少なくともノードの最小しきい値数に対して認証されなければならない。これにより、どのノードも単一の信頼ポイントを構成せず、悪意のあるパーティはシステムに不正アクセスするために複数のノードを侵害する必要があるため、システムのセキュリティと信頼性が向上する。ただし、これにはユーザが各ノードに対して認証プロセスを実行する必要があり、その結果、認証プロセスが長くなり、ユーザエクスペリエンスが低下する。

さらに、各ノードはユーザのユーザＩＤの知識を得ることができる。これは、例えば、ユーザの行動に関する情報を推測し、ユーザＩＤをユーザの真のアイデンティティに結びつけるために使用されるかもしれない。これにより、ユーザのプライバシが侵害されたり、侵害されたりする危険性がある。

ＷＯ２００８／０２０９９１Ａ１では、認証されたフェデレーテッドＩＤ管理を提供する方法が開示されており、ＩＤプロバイダとサービスプロバイダの間の直接通信は回避されている。サービス要求を受信すると、サービスプロバイダはユーザとの間で安全なチャネルを開くことができる。サービスプロバイダとユーザは、ユーザの要求に対してランダムなセッションＩＤを共同で生成できる。ＩＤプロバイダは、認証が成功した後、安全なチャネルでユーザからセッションＩＤを与えられる。ユーザに関連付けられたアサーションは、ハッシュ化されたバージョンのセッションＩＤを使用してＩＤプロバイダによって生成される場合がある。情報漏洩を防ぐため、このアサーションは、署名され公証人サービスに提出される前に、ＩＤプロバイダによって盲検化されることがある。アサーションを送信する場合、ＩＤプロバイダは最初に公証人サーバに対して認証を行うことができ、これによりＩＤプロバイダが権限付与される。公証人サーバは、利用者の問い合わせに応じて、公証人のブラインド化された主張を利用者に返すことができる。ユーザは、サービスプロバイダに公証されたブラインド化されたアサートを渡すことができ、サービスプロバイダは、公証されたアサートのブラインドを解除して検証する。ＷＯ２００８／０２０９９１Ａ１で開示されている方法は、純粋に単一ノードパーティに対する認証に関連している。

発明の説明
本発明は、マルチノードパーティに向けてユーザを認証する方法を提供することを目的としており、この方法では、認証が簡単かつユーザフレンドリでありながら安全な方法で行われる。

本発明の更なる目的は、マルチノードパーティに向けてユーザを認証する方法を提供することであり、これによりユーザの高いプライバシが得られる。

第１の態様によれば、本発明は、少なくとも２つのノードを含むマルチノードパーティに対してユーザを認証する方法を提供し、その方法は以下のステップを含む。
－ユーザが、ユーザアプリケーションを介してマルチノードパーティのノードに接続するステップと、
－マルチノードパーティのノードの各々が、ノンスを生成し、ユーザアプリケーションにノンスを返すステップと、
－ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスとユーザの一意のＩＤに基づいて、ＩＤプロバイダに認証を要求するステップと、
－ＩＤプロバイダが、認証の要求に基づいてメッセージを生成し、該メッセージをユーザアプリケーションに提供するステップと、
－ユーザアプリケーションが、マルチノードパーティのノードの各々にシークレットフォームでメッセージを提供するステップと、
－マルチノードパーティのノードが、受信したメッセージのシークレットフォームに基づき、且つ安全なマルチパーティ計算（ＭＰＣ）によって、メッセージを検証するステップと、
－安全なマルチパーティ計算に基づいてユーザを認証するステップ。

したがって、本発明は、マルチノードパーティ、すなわち、少なくとも２つのノードを含むパーティに対してユーザを認証する方法を提供する。

この方法によれば、ユーザは最初にユーザアプリケーションを介してマルチノードパーティのノードに接触する。ユーザアプリケーションは、ユーザインタフェースとマルチノードパーティへのインターフェイスを持つことができる。ユーザインタフェースは、例えば、グラフィカルユーザインタフェース（ＧＵＩ）とすることができる。マルチノードパーティへのインターフェイスは、たとえば、ソフトウェア開発キット（ＳＤＫ）の形式にすることができる。

マルチノードパーティの各ノードは、ユーザからの接触に応答してノンスを生成し、ユーザアプリケーションにノンスを返す。したがって、ユーザアプリケーションは、マルチノードパーティのノードの各々から発信されるノンスを所有しており、ユーザからの要求に応じてノンスが生成される。

次に、ユーザアプリケーションは、マルチノードパーティのノードから受信したノンスとユーザの一意のＩＤに基づいて、ＩＤプロバイダに認証を要求する。

これに応答して、ＩＤプロバイダはメッセージを生成し、そのメッセージをユーザアプリケーションに提供する。メッセージは、認証の要求に基づいて生成されるため、マルチノードパーティのノードによって生成されるノンスと、ユーザの一意のＩＤに基づいて生成される。したがって、メッセージはマルチノードパーティのノード、特定のセッション、およびユーザに関連付けられる。

したがって、ユーザは認証を要求するために、すべてのノードの代わりに１回だけＩＤプロバイダに連絡する。つまり、ノードごとに個別の認証プロセスは必要ない。

従来技術の方法では、ユーザアプリケーションがＩＤプロバイダに認証を要求し、それによってＩＤプロバイダとの認証プロセスに従事する場合、通常、ユーザは特定のウェブページに移動し、キーボードでパスワードを入力し、指紋を提供し、および／またはＵＳＢトークンを使用してワンタイムパスワードを生成する必要がある。この結果、ユーザアプリケーションは、例えばＩＤトークンの形式でメッセージを取得する。ユーザは、このメッセージを別の相手に提供して、その相手に自分の身元を証明することができる。既知の手法では、ユーザは各ノードに同じメッセージを安全に送信できない。これは、悪意のあるノードがメッセージを別のノードに転送し、それによってユーザを偽装する可能性があるため、安全ではない。そのため、既知の技術を使用してマルチノードパーティに自分の身元を安全に証明するため、ユーザは、ノードごとに個別のメッセージを取得するべく、代わりに、ノードごとに１つのプロセスである複数の個別の認証プロセスに従事する必要がある。これにより、ユーザは、たとえば、１回だけではなく、各ノードに対して１回パスワードを入力する必要があるため、ユーザエクスペリエンスが低下する。本発明によれば、ユーザは、マルチノードパーティ内の各ノードに対して自身のアイデンティティを証明するために、すべてのノードに代わって、ＩＤプロバイダとの単一の認証プロセスに安全に従事することができ、それによってユーザエクスペリエンスが低下することがない。

メッセージは、例えば、ユーザの身元を確認するＩＤトークン、できればＩＤトークンの有効性を確認するデジタル署名を付与されたＩＤトークンの形式とすることができる。この場合、以下で詳しく説明するように、メッセージの検証には、デジタル署名がＩＤトークンの有効な署名であることの検証が含まれる場合がある。

ユーザアプリケーションは、メッセージを受信すると、複数ノードパーティの各ノードにシークレットフォームでメッセージを提供する。例えば、メッセージが暗号化された形式でノードに提供されたり、メッセージがマルチノードパーティのノード間で共有されたりすることがある。これについては後述する。どのような場合でも、どのノードも非シークレットフォームでメッセージ全体を受信することはないが、マルチノードパーティのノードは、安全なマルチパーティ計算（ＭＰＣ）などのマルチパーティ操作を介してメッセージを検証できる。

したがって、マルチノードパーティのノードは、受信したメッセージのシークレットフォームに基づいて、マルチパーティ検証操作によってメッセージを検証する。

最後に、マルチパーティ検証操作に基づいてユーザが認証される。ユーザを認証するステップは、メッセージを検証するノードのステップの一部を形成する場合がある。この場合、認証はマルチパーティ検証操作の統合部分であり、検証操作の結果がユーザの認証になる。マルチパーティ操作は、例えば、当該技術分野でよく知られている安全なマルチパーティ計算（ＭＰＣ）であってもよい。

本明細書では、「マルチパーティ検証操作」という用語は、メッセージが正しいことを検証する目的を持ち、２つ以上のノードが協力して実行する操作を意味すると解釈されるべきものである。したがって、どのノードも独自に検証を実行することはできず、どのノードも、ノードを単一の信頼ポイントにするメッセージに関する情報を取得しない。

したがって、検証、ひいてはユーザの認証は、マルチノードパーティのノード間で安全なマルチパーティ計算などのマルチパーティ検証操作を介して行われるため、どのノードもメッセージ全体やユーザの本当の身元に関する知識を得ることはない。これにより、ユーザのプライバシが保護され、権限のない、または悪意のある者が、ユーザの真のアイデンティティを含むメッセージにアクセスするリスクが最小限に抑えられる。

さらに、これは、ユーザが各ノードに対して個別に認証する必要なく得られる。これは、ユーザアプリケーションがすべてのノードから受信したすべてのノンスに基づいてＩＤプロバイダに認証を要求すること、すべてのノンスに基づいて１つのメッセージが生成されること、およびその後、メッセージがノードによって組み合わせて検証されること、つまりマルチパーティ検証操作によって検証されることによるものである。このように、ユーザにとって、プロセスは、マルチノードパーティに対してではなく、単一ノードパーティに対して認証が行われたように感じられ、したがって、ユーザビリティとユーザエクスペリエンスは、マルチノードパーティに対する従来の認証プロセスと比較して大幅に改善される。

この方法は、さらに、ＩＤプロバイダが、メッセージを暗号化するステップと、暗号化されたメッセージをユーザアプリケーションに提供するステップとを、更に含み得、ユーザアプリケーションがシークレットフォームでメッセージを提供するステップが、暗号化されたメッセージをマルチノードパーティのノードに提供することを含み得る。

この実施形態によれば、メッセージのシークレットフォームはメッセージの暗号化形式である。より具体的には、メッセージはＩＤプロバイダによって暗号化され、メッセージは暗号化形式でＩＤプロバイダからユーザアプリケーションに提供される。つまり、メッセージはユーザアプリケーションによって受信されたときにすでにシークレットフォームになっている。その後、ユーザアプリケーションは単純に暗号化されたメッセージをマルチノードパーティの各ノードに転送する。つまり、すべてのノードが同じ暗号化メッセージを受信する。ノードの少なくとも一部がマルチパーティ復号操作で連携している場合、ノードは暗号化されたメッセージの少なくとも一部を復号できる。ただし、どのノードもメッセージを独自に復号できない。マルチパーティ復号操作では、最小数のノードのサブセットでメッセージを復号できるしきい値条件が適用される場合がある。

この方法は、マルチノードパーティのノードが、共有の暗号キーを生成するステップを更に含み得、メッセージを暗号化するステップ、及び、暗号化されたメッセージを検証するステップが、共有の暗号キーによって行われ得る。

生成されるキーは、マルチノードパーティのノード間で共有される公開キーと秘密キーで構成される場合がある。公開キーは、認証の要求と共に、または認証を要求する前の別の手順で、ＩＤプロバイダに提供される場合がある。検証プロセス中に、マルチノードパーティのノードは、秘密キーの共有を使用し、安全なマルチパーティ計算などのマルチパーティ復号操作によって、暗号化されたメッセージを復号する。検証は、このマルチパーティ復号操作の一部として実行される。これにより、マルチノードパーティのどのノードも、復号されたメッセージ全体を所有することはない。

共有キーは、例えば、マルチパーティ操作、すなわち、少なくともいくつかのノードが協力する操作によって生成され、マルチノードパーティのノード間で秘密共有されることがある。

別の方法として、暗号キーは他の適切な方法で、場合によってはマルチノードパーティ以外の別のエンティティによって生成されることもある。

この方法は、マルチノードパーティにて、安全なマルチパーティ復号などの、マルチパーティ復号操作によって、受信メッセージを復号するステップを、更に含み得る。上記のように、これはマルチノードパーティのノード間で共有される秘密復号キーによって行われ、場合によってはしきい値条件の対象となり得る。

一方で、若しくは、更に、ユーザアプリケーションが、マルチノードパーティのノード各々にシークレットフォームでメッセージを提供するステップが、ユーザアプリケーションが、メッセージの共有を生成することと、マルチノードパーティのノードの各々にメッセージの少なくとも１つの共有を提供することを含み、マルチノードパーティのノードがメッセージを検証するステップは、受信した共有に基づいて実行され得る。

この実施形態によれば、メッセージのシークレットフォームは、マルチノードパーティのノード間でメッセージを共有する形式である。したがって、ユーザアプリケーションが非シークレットフォームでメッセージを受信しても、どのノードもメッセージ全体を受信しないため、どのノードも、ユーザの真のアイデンティティに関する知識を含むメッセージ全体に関する知識を取得しない。ただし、ノードは、メッセージのそれぞれの共有に基づいて、場合によってはしきい値条件に従って、マルチパーティ操作によってメッセージを再構築できる。

この方法は、メッセージの少なくとも一部を秘密に共有する形式で、メッセージの少なくとも一部をマルチノードパーティに保存するステップを、更に含み得る。

この実施形態によれば、ユーザの認証後、メッセージまたはメッセージの少なくとも一部がマルチノードパーティに保存される。ただし、これはマルチノードパーティのノード間で秘密の共有の形で行われるため、メッセージの格納部分全体を所有しているノードはない。したがって、ユーザのプライバシは維持され、どのノードも単一の信頼ポイントを構成しない。

この方法でメッセージ全体を格納することもできる。代わりに、メッセージの一部のみを格納することもできる。たとえば、メッセージがデジタル署名とともに提供されるＩＤトークンの形式である場合、ＩＤトークンのみが格納され、デジタル署名は格納されない。

この方法は、さらに以下のステップを含むことができる。
－マルチノードパーティのノードの各々が、セッションＩＤを生成して、該セッションＩＤをノンスとともにユーザアプリケーションに返すステップと、
－マルチノードパーティのノードの各々について、ユーザアプリケーションが、マルチノードパーティの所与のノードによって生成されたセッションＩＤを、該ノードに提供されたメッセージの共有と共に提供するステップと、
－各々のノードが、受信したセッションＩＤを検証するステップ。

この実施形態によれば、マルチノードパーティの各ノードは、受信したメッセージの秘密バージョンが、実際にはノードによって生成されたノンスに関連していることを保証することができる。これは、各ノードがセッションＩＤを生成し、生成されたノンスとともにこのセッションＩＤをユーザアプリケーションに返すことによって取得される。メッセージのシークレットフォームが後でユーザアプリケーションによってノードに提供されると、ユーザアプリケーションにはそれぞれのセッションＩＤが含まれる。これにより、所与のノードは、ユーザアプリケーションがメッセージのシークレットフォームとともに提供するセッションＩＤが、ノードからユーザアプリケーションにノンスとともに提供されたセッションＩＤと実際に同一であることを検証することができる。これにより、不正なパーティが誤った識別メッセージによってマルチノードパーティにアクセスするリスクが軽減される。

たとえば、各ノードは生成されたノンスとともにセッションＩＤを格納し、格納されたセッションＩＤと返されたセッションＩＤが一致する場合、および格納されたノンスに基づいてメッセージが生成されたことを検証できる場合にのみ、受信したメッセージを検証できる。

ノードは、受信したメッセージのシークレットフォームの妥当性を他の方法でチェックできる。たとえば、ユーザアプリケーションは、トランスポート層セキュリティ（ＴＬＳ）接続などの特定の接続を介してＩＤプロバイダに認証の要求を転送する場合があり、ＩＤプロバイダから受信したメッセージは、同じ接続を介して提供された場合にのみ有効として受け入れられる場合がある。

代わりに、マルチノードパーティがノンスに基づいてメッセージ認証コードを生成し、これをユーザアプリケーションに転送することもできる。メッセージ認証コードはメッセージと共に返される必要があり、返されたメッセージ認証コードがメッセージの生成に使用されたノンスと一致している場合にのみ、メッセージは有効として受け入れられる。

上記のいずれのシナリオでも、ＩＤプロバイダによってユーザアプリケーションに提供されたメッセージは、最初にマルチノードパーティのノードに接続した同じユーザによって、ユーザアプリケーションを介してマルチノードパーティに返されることが保証される。

この方法は、マルチノードパーティにアクセス可能な記憶場所に保存されたオブジェクトへのアクセスを、ユーザの認証に基づいて、及びアクセス権のセットに基づいて、ユーザに付与する又は拒否するステップを、更に含み得る。

この実施形態によれば、ユーザは、適切に認証され、一連のアクセス権が認証されたユーザがオブジェクトへのアクセス権を持つことを指定している場合、オブジェクトへのアクセス権を付与される。一方、ユーザが認証されていない場合、そのユーザには格納場所に格納されているオブジェクトへのアクセス権は付与されない。さらに、ユーザが認証された場合でも、そのユーザには、アクセス権のセットが指定する範囲までの所与のオブジェクトへのアクセスのみが許可される。

アクセス権のセットは、例えば、どのユーザがどのオブジェクトに対してどのアクションを実行する権限を与えられるかを指定するアクセス制御リスト（ＡＣＬ）またはアクセス制御マトリクス（ＡＣＭ）の形式とすることができる。

ストレージロケーションは、マルチノードパーティの一部を形成する場合もあれば、別のストレージロケーションである場合もある。後者の場合、マルチノードパーティは単にユーザのストレージロケーションへのアクセスを管理し、それによってストレージロケーションに格納されたオブジェクトへのアクセスを管理するだけである。

アクセス権のセットは、例えば、所与のユーザが保存場所に保存されているオブジェクトに対する他のユーザのアクセス権を定義する権限を与えられることを指定することができる。これにより、ユーザは他のユーザにアクセス権を委任できるようになる。

この方法は、さらに以下のステップを含むことができる。
－メッセージからユーザの一意のＩＤの共有を導出して、マルチノードパーティのノードにて、マルチパーティストア操作により、ユーザの一意のＩＤの共有を保存するステップと、
－各々のノードが、ユーザのアクティビティをログに記録し、記録されたアクティビティを一意のユーザＩＤの夫々の共有と共に保存するステップ。

前述のように、ＩＤプロバイダから受信するメッセージは、デジタル署名と共に提供されるＩＤトークンの形式である場合がある。この場合、ＩＤトークンにはユーザの一意のＩＤが含まれることがあり、これはメッセージから派生し、ノード間での秘密の共有などの共有の形式でマルチノードパーティに格納できる。

いずれの場合も、各ノードはユーザの一意のＩＤの共有を有しているが、どのノードもユーザの一意のＩＤ全体を所有していないか、またはそのＩＤに関する知識を取得していない。しかし、ユーザの一意のＩＤは、ノードが保持している共有から、また、マルチパーティ操作、すなわち、ノードが協力する操作を使用することによって導き出せる。

認証が成功したためにユーザにシステムへのアクセスが許可されると、マルチノードパーティのノードはユーザが実行したアクティビティをログに記録する。各ノードはさらに、ログに記録されたアクティビティを、ノードが所有しているユーザの一意のＩＤの共有に関連付ける。これは、ログに記録されたアクティビティをそれぞれの共有とともに格納するという意味である。したがって、各ノードは、記録されたアクティビティの記録を保持し、記録されたアクティビティは、一意のユーザＩＤのそれぞれの共有を介してアクティビティを実行するユーザにリンクされるが、ユーザの実際の身元は個々のノードに明らかにされない。

この方法は、さらに以下のステップを含むことができる。
－監査人が、マルチパーティの操作によりマルチノードパーティのノードからアクティビティ情報を検索するステップと、
－監査人が、検索した情報に基づいて、マルチノードパーティで実行されたアクティビティを監査するステップ。

この実施形態によれば、監査人は、ユーザの一意のＩＤの夫々の共有とともに、ノードによって保存されたログに記録されたユーザアクティビティへのアクセス権を得る。これは、マルチパーティ操作によって行われ、監査人は、ユーザの一意のＩＤの保存された共有に基づいて、記録されたアクティビティをユーザの実際のＩＤにリンクできる。その後、監査人は、この方法で取得されたアクティビティ情報に基づいて、マルチノードパーティで実行されたアクティビティの関連する監査を実行できる。繰り返しになるが、これはどのノードにもユーザの本当の身元を明かすことなく行われる。

取得されたアクティビティ情報は、所与のユーザの完全なアクティビティログの形式である場合もあれば、指定された時間間隔でマルチノードパーティにアクセスしたすべてのユーザの形式である場合もある。取得されたアクティビティ情報は、所与の特定のユーザの１つのセッションから生成される場合もあれば、同じユーザの複数のセッションから生成される場合もある。

別の方法として、検索されたアクティビティ情報は限定された形式である場合がある。つまり、保存されたアクティビティ情報の一部のみが監査人に使用可能になる。たとえば、監査人は特定のクエリに対する応答の取得のみを許可される場合がある。たとえば、監査人は、特定のユーザまたは特定のユーザグループが、所与の期間内に１つ以上の指定されたオブジェクトにアクセスしたかどうか、および／または１つ以上の指定されたアクティビティを実行したかどうかを照会できる。このようなクエリに対する応答は、単に「ｙｅｓ」または「ｎｏ」である場合がある。これにより、監査人は、ユーザの実際の身元に関する詳細な情報や個々のユーザのアクティビティに関する詳細な情報を含む、ユーザに関する詳細な情報を取得することなく、監査や統計の目的で関連するアクティビティ情報を取得することができる。別の方法として、監査人は、指定されたユーザまたは指定されたユーザグループのログに記録されたアクティビティの指定されたサブセットのみを取得することもできる。

この方法は、さらに以下のステップを含むことができる。
－偽名ユーザＩＤを生成し、該偽名ユーザＩＤをマルチノードパーティにてマルチパーティの保存操作により保存するステップと、
－ユーザのアクティビティをログに記録し、アクティビティと偽名ユーザＩＤを相互に関連付けるステップと、
－各々のノードが、ノードＩＤ、偽名ユーザＩＤ、及び関連するアクティビティに関する情報を、ログに提供するステップ。

この実施形態によれば、記録されたアクティビティは、実ユーザＩＤではなく、偽名ユーザＩＤに関連付けられる。これにより、マルチノードパーティのノードは、記録されたアクティビティを、アクティビティを実行するユーザの実際のＩＤに直接リンクできなくなる。さらに、ユーザがシステムにアクセスするたびに新しい偽名ユーザＩＤが生成される場合、ノードは２つの異なるセッション中に実行されたアクティビティを同じユーザにリンクすることもできない。これにより、ユーザのプライバシが向上する。

偽名ユーザＩＤは、マルチパーティ保存操作によって、ユーザの一意のＩＤにリンクする方法で保存することができ、その場合、適切なマルチパーティ操作を適用することによって、偽名ユーザＩＤに関連付けられたアクティビティをユーザの一意のＩＤにリンクし、それによってユーザの実際のＩＤにリンクすることが可能になる。

したがって、この実施形態によれば、各ノードは、ノードＩＤ、偽名ユーザＩＤおよび関連するアクティビティに関する情報をログに提供する。ログは、システムログや監査ログなどである。したがって、ログには各ノードから提供されたアクティビティ情報が含まれ、アクティビティ情報はアクティビティを記録したノードのノードＩＤと、アクティビティを実行したユーザの偽名ユーザＩＤに関連付けられる。

監査人などの別の関係者は、ログに記録された情報の少なくとも一部を取得するために、その後ログにアクセスすることができる。監査人には、監査人が偽名ユーザＩＤを一意のユーザＩＤにリンクするためのキーを提供することができる。キーは、たとえば、マルチノードパーティによって提供される可能性がある。これにより、監査人は、複数のセッション中に所与のユーザによって実行されたアクティビティに関する情報を、この情報がログに格納されている情報から直接利用できない場合でも、偽名ユーザＩＤと一意のユーザＩＤの間のマッピングに基づいて導き出すことができる。この場合、監査人は、アクティビティ情報がログから取得されるたびにマルチパーティ操作を適用する必要はない。

ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、次のステップで構成され得る。
－ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスとユーザの一意のＩＤに基づいて、第１のＩＤプロバイダからユーザの認証を要求することと、－第１のＩＤプロバイダが、認証の要求に基づいて第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
－ユーザアプリケーションが、第１のＩＤプロバイダから受信した第１のメッセージと、ユーザの一意のＩＤとに基づいて、第２のＩＤプロバイダからユーザの認証を要求することと、
－第２のＩＤプロバイダが、認証の要求に基づいて第２のメッセージを生成し、ユーザアプリケーションに第２のメッセージを提供すること。

この実施形態によれば、システムのセキュリティは、「チェーンされた」プロセスにおいて、複数回ＩＤプロバイダに認証を要求することによって向上する。より具体的には、ユーザアプリケーションは最初に、マルチノードパーティのノードから受信したノンスとユーザの一意のＩＤに基づいて、第１のＩＤプロバイダにユーザの認証を要求し、第１のＩＤプロバイダはそれに基づいて第１のメッセージを生成し、上記の方法でユーザアプリケーションにメッセージを提供する。ただし、ユーザアプリケーションは、受信した第１のメッセージをシークレットフォームでマルチノードパーティの各ノードに提供する代わりに、第１のメッセージとユーザの一意のＩＤに基づいて、第２のＩＤプロバイダにユーザの認証を要求する。したがって、第１のＩＤプロバイダによって生成された第１のメッセージは、第１の認証の要求中にマルチノードパーティのノードによって提供されたノンスが適用されたのと同様の方法で、第２のＩＤプロバイダからのユーザの認証の追加要求で適用される。

ユーザの第２の認証の要求に応答して、第２のＩＤプロバイダは第２のメッセージを生成し、ユーザアプリケーションに第２のメッセージを提供する。したがって、ユーザアプリケーションは、第１のＩＤプロバイダによって生成された第１のメッセージと、第２のＩＤプロバイダによって生成された第２のメッセージを有するものとなる。さらに、第２のメッセージは第１のメッセージに基づいて生成されたため、第１のメッセージに関する情報、および第１のＩＤプロバイダによって提供されたユーザの第１の認証に関する情報が含まれている。

次に、ユーザアプリケーションは、基本的に上記の方法で、第１のメッセージと第２のメッセージをシークレットフォームでマルチノードパーティのノードに提供する。ただし、第２のメッセージだけがユーザアプリケーションに提供される可能性も否定できない。

ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、更に、第２のメッセージと、ユーザの一意のＩＤとに基づいて、少なくとも第３のＩＤプロバイダからユーザの認証を要求し、それによってメッセージのチェーンを作成することを、含み得る。

この実施形態によれば、基本的に上記の方法で３つ以上のＩＤプロバイダから順次認証を要求することにより、システムのセキュリティをさらに向上させることができる。ユーザアプリケーションは、２つ以上、できればすべての受信メッセージをシークレットフォームでマルチノードパーティのノードに提供する。これは、単一のメッセージの形式で行うことができる（たとえば、ＩＤプロバイダから受信したメッセージから形成されるハッシュまたは連結メッセージ）。または、メッセージをマルチノードパーティのノードに個別に提供することもできる。この場合、ユーザアプリケーションは、最後のメッセージの受信を待つのではなく、各ＩＤプロバイダからメッセージを受信したときに、ノードにメッセージを提供できる。

次の認証の要求時に受信したメッセージが適用される限り、第１、第２、第３等のＩＤプロバイダが実際には同一のＩＤプロバイダであることは否定されない。

代わりに、ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップは、次のステップで構成され得る。
－ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスと、第１のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第１のユーザの認証を要求することと、
－ＩＤプロバイダが、第１のユーザの認証の要求に基づいて、第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
－ユーザアプリケーションが、ＩＤプロバイダから受信した第１のメッセージと、第２のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第２のユーザの認証を要求することと、
－ＩＤプロバイダが、第２のユーザの認証の要求に基づいて、第２のメッセージを生成し、第２のメッセージをユーザアプリケーションに提供すること。

これは上記の実施形態と同様であり、したがって、ここで述べたリマークも同様に適用できる。ただし、この実施形態では、複数のＩＤプロバイダで１人のユーザの認証を要求するのではなく、ＩＤプロバイダで複数のユーザの認証を要求する。これは、例えば、オブジェクトへのアクセス、デジタル署名の提供、トランザクションの実行など、実行されるアクションが複数のユーザの承認を必要とする場合に関連する可能性がある。

上記の実施形態と同様に、ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップは、更に、第２のメッセージと第３のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから少なくとも第３のユーザの認証を要求し、それによってメッセージのチェーンを作成することを、含み得る。

ユーザの認証が複数のＩＤプロバイダから要求される可能性は排除されない。例えば、第１のユーザの認証を第１のＩＤプロバイダに要求したり、第２のユーザの認証を第１のＩＤプロバイダとは異なる第２のＩＤプロバイダに要求したりすることができる。

この方法と上記の実施形態の利点は、ＩＤトークンのチェーンを、単一のユーザと単一のＩＤプロバイダによる通常の認証フローから逸脱することなく生成できることである。

第２の態様によれば、本発明は、少なくとも２つのノードを含むマルチノードパーティに対してユーザを認証する方法を提供し、その方法は以下のステップを含む；
－ユーザが、ユーザアプリケーションを介してマルチノードパーティのノードに接続するステップと、
－マルチノードパーティのノードの各々が、ノンスを生成し、ユーザアプリケーションにノンスを返すステップと、
－ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスに基づいて、結合されたノンスを生成し、結合されたノンスとユーザの一意のＩＤとに基づいてＩＤプロバイダに認証を要求するステップと、
－ＩＤプロバイダが、認証の要求に基づいてメッセージを生成し、該メッセージをユーザアプリケーションに提供するステップと、
－ユーザアプリケーションが、マルチノードパーティのノードの各々にメッセージを提供するステップと、
－マルチノードパーティのノードが、受信したメッセージに基づき、且つ検証の操作により、メッセージを検証するステップと、
－検証の操作に基づいてユーザを認証するステップ。

発明の第１の態様に係る方法は、発明の第２の態様に係る方法と同様であるため、同様の特徴についてはここでは詳述しない。したがって、上記の発明の第１の態様に関するリマークは、発明の第２の態様にも同様に適用できる。

本発明の第２の態様に係る方法では、ユーザは、基本的に本発明の第１の態様に関して上述したように、ユーザアプリケーションを介して、最初にマルチノードパーティのノードに接触する。

それに応じて、マルチノード当事者の各ノードは、基本的に発明の第１の態様に関して上述したように、ノンスを生成し、ユーザアプリケーションにノンスを返す。

その後、ユーザアプリケーションは、マルチノードパーティのノードから受信したノンスに基づいて、複合ノンスを生成する。したがって、結合されたノンスには、マルチノードパーティのノードによって生成された各ノンスからの情報が含まれる。ユーザアプリケーションはさらに、ユーザの一意のＩＤに基づいて、結合されたノンスａに基づいてＩＤプロバイダに認証を要求する。これは、本発明の第１の態様に関して上述したものと同様である。結合されたノンスは、例えば、個々のノンスを連結するか、ノンスをハッシュすることによって生成することができる。

次に、ＩＤプロバイダは、認証の要求に基づいて、それによって結合されたノンスとユーザの一意のＩＤに基づいてメッセージを生成する。本発明の第１の態様に関して上述したように、メッセージは、デジタル署名と共に提供されるＩＤトークンの形式であってもよい。どのような場合でも、メッセージは、結合されたノンスに依存するという意味で、結合されたノンスを反映し、それによって複数ノードパーティのノードによって生成されたノンスも反映する。ただし、ユーザアプリケーションとＩＤプロバイダの間の通信は、結合されたノンスのために、一方だけが認証を要求する状況に似た方法で行われる。つまり、各ノードがＩＤプロバイダにユーザの認証を要求する必要がないため、必要なアクションの数が減り、ユーザエクスペリエンスが向上する。さらに、ＩＤプロバイダの観点からは、このプロセスは単一のノードパーティに対して認証を実行するのと似ている。

ＩＤプロバイダはユーザアプリケーションにメッセージを提供し、ユーザアプリケーションはマルチノードパーティの各ノードにメッセージを提供する。マルチノードパーティのノードは、受信したメッセージに基づいて、検証操作によってメッセージを検証する。メッセージはマルチノードパーティのノードが生成したノンスから生成された複合ノンスに基づいて生成されるため、各ノードはメッセージが最初にノードがユーザアプリケーションに提供したノンスに対応するかどうかを確認することができる。

最後に、検証操作に基づいてユーザが認証される。

このように、認証はマルチノードパーティに対して行われるため、ユーザの認証は安全な方法で取得されるが、各ノードがＩＤプロバイダに認証を要求する追加の手順を導入することはなく、それによってユーザフレンドリな方法で取得される。

ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、次のステップで構成され得る。
－ユーザアプリケーションが、結合されたノンスとユーザの一意のＩＤとに基づいて、第１のＩＤプロバイダからユーザの認証を要求することと、
－第１のＩＤプロバイダが、認証の要求に基づいて、第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
－ユーザアプリケーションが、第１のＩＤプロバイダから受信した第１のメッセージとユーザの一意のＩＤとに基づいて、第２のＩＤプロバイダからユーザの認証を要求することと、
－第２のＩＤプロバイダが、認証の要求に基づいて第２のメッセージを生成し、ユーザアプリケーションに第２のメッセージを提供すること。

これについては、本発明の第１の態様を参照して既に詳細に説明した。

ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップは、更に、第２のメッセージとユーザの一意のＩＤとに基づいて、少なくとも第３のＩＤプロバイダにユーザの認証を要求し、それによりメッセージのチェーンを作成することを、含み得る。

これについては、本発明の第１の態様を参照して既に詳細に説明した。

代わりに、ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、次のステップで構成され得る。
－ユーザアプリケーションが、結合されたノンスと第１のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第１のユーザの認証を要求することと、
－ＩＤプロバイダが、第１のユーザの認証の要求に基づいて第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
－ユーザアプリケーションが、ＩＤプロバイダから受信した第１のメッセージと第２のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第２のユーザの認証を要求することと、
－ＩＤプロバイダが、第２のユーザの認証の要求に基づいて第２のメッセージを生成し、第２のメッセージをユーザアプリケーションに提供すること。

これについては、本発明の第１の態様を参照して既に詳細に説明した。

ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、更に、ユーザアプリケーションが、第２のメッセージと第３のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから少なくとも第３のユーザの認証を要求し、それによりメッセージのチェーンを作成することを、含み得る。

これについては、本発明の第１の態様を参照して既に詳細に説明した。

以下では、本発明を添付の図面を参照してさらに詳細に説明する。
図１～３は、本発明による方法の様々な実施形態を示す図である。 図１～３は、本発明による方法の様々な実施形態を示す図である。 図１～３は、本発明による方法の様々な実施形態を示す図である。 図４は、本発明の一実施形態による方法の一部を形成する、チェーンされた認証を示すブロック図である。

図面の詳細な説明
図１は、本発明の第１の実施形態による方法を示す図である。具体的には、本発明の第１の実施形態による方法を実行しながら、様々な関係者間の通信を図１に示す。

メソッドの実行に参加するパーティは、ユーザアプリケーション１、３つのノード２で構成されるマルチノードパーティ、およびＩＤプロバイダ３である。

最初に、ユーザの認証に先立ち、マルチノードアプリケーションのノード２とＩＤプロバイダ３との間に信頼関係が確立されているものとする。

また、ユーザアプリケーション１とＩＤプロバイダ３の間に初期の信頼関係があることを前提としている。この信頼関係により、ユーザアプリケーション１はＩＤプロバイダを認証でき、ユーザはＩＤプロバイダ３がユーザを認証できる資格情報を保持していることを意味する。

最後に、ユーザアプリケーション１が各ノード２を認証できるようにする初期の信頼関係を仮定する。最初は、ノードがユーザを認証できるとは仮定しないことに注意してください。これが本発明の目的である。

ユーザの認証を実行するために、ユーザアプリケーション１は最初に各ノード２に接続し、各ノード２との安全な一方向認証チャネルを確立する。これを受けて各ノード２はノンスとセッションＩＤを生成し、ユーザアプリケーション１に返す。

その後、ユーザアプリケーション１はユーザの認証の要求を生成し、これをＩＤプロバイダ３に転送する。認証の要求は、ノード２から受信したノンスから生成されたノンスで構成され、例えば、ノンスの組み合わせの形式である。

これに応答して、ＩＤプロバイダ３は、ユーザの一意のＩＤに基づいて、ユーザの一意のＩＤ（ｕｉｄ）と組み合わせたノンスを含むメッセージＭを生成する。また、メッセージＭのデジタル署名ｓも生成する。メッセージＭとデジタル署名ｓは、ユーザアプリケーション１に返される。

次に、ユーザアプリケーション１は、ＩＤプロバイダ３から受信したメッセージＭとデジタル署名ｓを、それぞれのセッションＩＤとともに各ノード２に提供する。

その後、各ノード２は、（１）デジタル署名がＭの有効な署名であること、（２）受信したセッションＩＤがノードが最初にユーザアプリケーションにノンスを提供したときに生成したセッションＩＤと一致すること、（３）メッセージＭが実際にはノード２が最初にユーザアプリケーション１に提供したノンスに基づいていることを確認する。

ユーザアプリケーション１は、ＩＤプロバイダ３に対して単一のクライアントとして機能し、ＩＤプロバイダ３の観点からは、１つのパーティ、つまりユーザアプリケーション１だけが認証される。これにより、ユーザの認証を完了させるために必要なラウンド数を最小限に抑えることができ、各ノード２への個別認証に関わる欠点なく、マルチノードパーティによる高い認証セキュリティを得ることができる。

各ノードの個々のセッションＩＤの使用と、署名付きメッセージＭに含まれるノンスが各ノードからの個々のノンスの組み合わせで構成されているという事実により、悪意のあるノードであっても、受信した情報を悪用して、クライアントであるかのように他のノードに対して認証を行うことはできない。

図２は、本発明の第２の実施形態による方法を示す図である。図２に示す方法は、図１に示す方法と非常に類似しているため、ここでは詳しく説明しない。

しかし、図２に示す方法では、マルチノードパーティのノード２が共有の暗号キーｋを生成し、ユーザアプリケーション１とＩＤプロバイダ３の間に確立された信頼関係を介して、その暗号キーｋがＩＤプロバイダ３と共有される。

認証の要求に応じてＩＤプロバイダ３が生成するメッセージは、暗号キーｋによって暗号化される。これにより、ユーザアプリケーション１はシークレットフォームでメッセージを受信する。さらに、ユーザアプリケーション１は、暗号化されたメッセージを受信すると、メッセージの秘密の共有を生成し、それぞれの共有をノード２に提供する。したがって、各ノード２はメッセージの秘密バージョンを受信する。

その後、ノード２はメッセージを検証するマルチパーティ操作を実行する。これはＭＰＣ ４で示されている。

したがって、どのノード２も、ユーザの真のアイデンティティや、ＩＤプロバイダ３によって提供されるメッセージ全体に関する情報を学習しない。これにより、利用者のプライバシが保たれる。

図３は、本発明の第３の実施形態による方法を示す図である。より具体的には、図３は、例えば、図１または図２を参照して上記の方法で、ユーザの認証が行われた後に行われる監査プロセスを示している。

ユーザアプリケーション１とマルチノードパーティのノード２との間では、最初にマルチパーティプロセス４によって認証処理が行われる。さらに、マルチノードパーティのノード２は、マルチパーティプロセス４を使用して、ユーザのランダムな偽名ＩＤを生成し、偽名ＩＤを格納する。

その後、ユーザのアクティビティはマルチノードパーティのノード２によって記録され、記録されたアクティビティは、偽名ＩＤとそれぞれのノードＩＤのそれぞれの共有とともに監査ログ５に保存される。その後、監査人は監査を行うために監査ログ５にアクセスすることができる。

図４は、本発明の一実施形態による方法の一部を形成する、チェーンされた認証を示すブロック図である。この方法は、例えば、図１または図２に示され、上記で説明されている方法の１つである。

ユーザアプリケーションは、マルチノードパーティの各ノードからノンスを受信すると、受信したノンスに基づいてハッシュ化ノンスを生成する。ハッシュされたノンスは、第１のＩＤプロバイダ３ａからのユーザの認証を要求するために、認証されるユーザの一意のＩＤとともに第１のＩＤプロバイダ３ａに提供される。これに応答して、第１のＩＤプロバイダ３ａは第１のＩＤトークンの形式で第１のメッセージを生成し、これをユーザアプリケーションに返す。

その後、ユーザアプリケーションは第１のＩＤトークンのハッシュを生成し、これをユーザの一意のＩＤとともに第２のＩＤプロバイダ３ｂに提供し、第２のＩＤプロバイダ３ｂからのユーザの認証を要求する。これに対して、第２のＩＤプロバイダ３ｂは第２のＩＤトークンを生成してユーザアプリケーションに返し、ユーザアプリケーションは第２のＩＤトークンのハッシュを生成する。

上記のプロセスが繰り返され、すなわち、第２のＩＤトークンのハッシュが第３のＩＤプロバイダ等に提供され、目的の数のＩＤプロバイダからユーザのＩＤトークンのチェーンが取得される。図４では、この最終的なＩＤプロバイダをｎ番目のＩＤプロバイダ３ｃとして示している。

その後、すべてのＩＤトークンがマルチノードパーティのノードに提供され、マルチノードパーティは上記のようにＩＤトークンのチェーンを検証する。

Claims (20)

1. マルチノードパーティに対するユーザの認証の方法であって、マルチノードパーティは少なくとも２つのノードで構成され、
   前記方法は、
   －ユーザが、ユーザアプリケーションを介してマルチノードパーティのノードの各々に接続するステップと、
   －マルチノードパーティのノードの各々が、ノンスを生成し、ユーザアプリケーションにノンスを返すステップと、
   －ユーザアプリケーションが、マルチノードパーティのノードの各々から受信したノンスとユーザの一意のＩＤに基づいて、ＩＤプロバイダに認証を要求するステップと、
   －ＩＤプロバイダが、認証の要求とノードの各々により生成されたノンスとに基づいてメッセージを生成し、該メッセージをユーザアプリケーションに提供するステップと、
   －ユーザアプリケーションが、マルチノードパーティのノードの各々にシークレットフォームでメッセージを提供するステップと、
   －マルチノードパーティのノードが、受信したメッセージのシークレットフォームに基づき、且つ、少なくとも２つのノードにより共同で実行される安全なマルチパーティ計算によって、メッセージを検証するステップと、
   －安全なマルチパーティ計算に基づいてユーザを認証するステップと
   を含む、方法。
2. ＩＤプロバイダが、
   メッセージを暗号化するステップと、
   暗号化されたメッセージをユーザアプリケーションに提供するステップと
   を更に含み、
   ユーザアプリケーションがシークレットフォームでメッセージを提供するステップが、暗号化されたメッセージをマルチノードパーティのノードに提供することを含む、
   請求項１に記載の方法。
3. マルチノードパーティのノードが、共有暗号鍵を生成するステップ
   を更に含み、
   少なくとも、メッセージを暗号化するステップが、共有暗号鍵によって行われる、
   請求項２に記載の方法。
4. マルチノードパーティにて、安全なマルチパーティ復号によって、受信メッセージを復号するステップ
   を更に含む、請求項２又は３に記載の方法。
5. ユーザアプリケーションが、マルチノードパーティのノードの各々にシークレットフォームでメッセージを提供するステップが、
   ユーザアプリケーションが、メッセージの共有を生成することと、マルチノードパーティのノードの各々にメッセージの少なくとも１つの共有を提供することとを含み、
   マルチノードパーティのノードがメッセージを検証するステップは、受信した共有に基づいて実行される、
   請求項１～４のいずれか一に記載の方法。
6. メッセージの少なくとも一部を秘密に共有する形式で、メッセージの少なくとも一部をマルチノードパーティに保存するステップ
   を更に含む、
   請求項１～５のいずれか一に記載の方法。
7. －マルチノードパーティのノードの各々が、セッションＩＤを生成して、該セッションＩＤをノンスとともにユーザアプリケーションに返すステップと、
   －マルチノードパーティのノードの各々について、ユーザアプリケーションが、マルチノードパーティの所与のノードによって生成されたセッションＩＤを、該ノードに提供されたメッセージの共有と共に提供するステップと、
   －各々のノードが、受信したセッションＩＤを検証するステップと
   を、更に含む、請求項１～６のいずれか一に記載の方法。
8. マルチノードパーティにアクセス可能な記憶場所に保存されたオブジェクトへのアクセスを、ユーザの認証に基づいて、及びアクセス権のセットに基づいて、ユーザに付与する又は拒否するステップ
   を更に含む、請求項１～７のいずれか一に記載の方法。
9. －メッセージからユーザの一意のＩＤの共有を導出して、マルチノードパーティのノードにて、マルチパーティの保存操作により、ユーザの一意のＩＤの共有を保存するステップと、
   －各々のノードが、ユーザのアクティビティをログに記録し、記録されたアクティビティを一意のユーザのＩＤの夫々の共有と共に保存するステップと
   を、更に含む、請求項１～８のいずれか一に記載の方法。
10. －監査人が、マルチパーティの操作によりマルチノードパーティのノードからアクティビティ情報を検索するステップと、
    －監査人が、検索した情報に基づいて、マルチノードパーティで実行されたアクティビティを監査するステップと
    を、更に含む、請求項９に記載の方法。
11. －偽名ユーザＩＤを生成し、該偽名ユーザＩＤをマルチノードパーティにてマルチパーティの保存操作により保存するステップと、
    －ユーザのアクティビティをログに記録し、アクティビティと偽名ユーザＩＤを相互に関連付けるステップと、
    －各々のノードが、ノードＩＤ、偽名ユーザＩＤ、及び関連するアクティビティに関する情報を、ログに提供するステップと
    を、更に含む、請求項９又は１０に記載の方法。
12. ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、
    －ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスとユーザの一意のＩＤに基づいて、第１のＩＤプロバイダからユーザの認証を要求することと、
    －第１のＩＤプロバイダが、認証の要求に基づいて第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
    －ユーザアプリケーションが、第１のＩＤプロバイダから受信した第１のメッセージと、ユーザの一意のＩＤとに基づいて、第２のＩＤプロバイダからユーザの認証を要求することと、
    －第２のＩＤプロバイダが、認証の要求に基づいて第２のメッセージを生成し、第２のメッセージをユーザアプリケーションに提供することと
    を含む、
    請求項１～１１のいずれか一に記載の方法。
13. ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップは、更に、
    ユーザアプリケーションが、第２のメッセージと、ユーザの一意のＩＤとに基づいて、少なくとも第３のＩＤプロバイダからユーザの認証を要求し、それによってメッセージのチェーンを作成すること
    を含む、請求項１２に記載の方法。
14. ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップが、
    －ユーザアプリケーションが、マルチノードパーティのノードから受信したノンスと、第１のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第１のユーザの認証を要求することと、
    －ＩＤプロバイダが、第１のユーザの認証の要求に基づいて、第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
    －ユーザアプリケーションが、ＩＤプロバイダから受信した第１のメッセージと、第２のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第２のユーザの認証を要求することと、
    －ＩＤプロバイダが、第２のユーザの認証の要求に基づいて、第２のメッセージを生成し、第２のメッセージをユーザアプリケーションに提供することと
    を含む、請求項１～１１のいずれか一に記載の方法。
15. ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップが、更に、
    第２のメッセージと第３のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから少なくとも第３のユーザの認証を要求し、それによってメッセージのチェーンを作成すること
    を含む、請求項１４に記載の方法。
16. マルチノードパーティに対するユーザの認証の方法であって、マルチノードパーティは少なくとも２つのノードで構成され、該方法は、
    －ユーザが、ユーザアプリケーションを介してマルチノードパーティのノードの各々に接続するステップと、
    －マルチノードパーティのノードの各々が、ノンスを生成し、ユーザアプリケーションにノンスを返すステップと、
    －ユーザアプリケーションが、マルチノードパーティのノードの各々から受信したノンスに基づいて、結合されたノンスを生成し、結合されたノンスとユーザの一意のＩＤとに基づいて、ＩＤプロバイダから認証を要求するステップと、
    －ＩＤプロバイダが、認証の要求と、結合されたノンスとに基づいてメッセージを生成し、該メッセージをユーザアプリケーションに提供するステップと、
    －ユーザアプリケーションが、マルチノードパーティのノードの各々にメッセージを提供するステップと、
    －マルチノードパーティのノードが、受信したメッセージに基づき、且つ検証の操作により、メッセージを検証するステップと、
    －検証の操作に基づいてユーザを認証するステップと
    を含む、方法。
17. ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップが、
    －ユーザアプリケーションが、結合されたノンスとユーザの一意のＩＤとに基づいて、第１のＩＤプロバイダからユーザの認証を要求することと、
    －第１のＩＤプロバイダが、認証の要求に基づいて、第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
    －ユーザアプリケーションが、第１のＩＤプロバイダから受信した第１のメッセージとユーザの一意のＩＤとに基づいて、第２のＩＤプロバイダからユーザの認証を要求することと、
    －第２のＩＤプロバイダが、認証の要求に基づいて第２のメッセージを生成し、ユーザアプリケーションに第２のメッセージを提供することと
    を含む、請求項１６に記載の方法。
18. ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップは、更に、
    第２のメッセージとユーザの一意のＩＤとに基づいて、少なくとも第３のＩＤプロバイダにユーザの認証を要求し、それによりメッセージのチェーンを作成すること
    を含む、請求項１７に記載の方法。
19. ユーザアプリケーションが、ＩＤプロバイダから認証を要求するステップは、
    －ユーザアプリケーションが、結合されたノンスと第１のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第１のユーザの認証を要求することと、
    －ＩＤプロバイダが、第１のユーザの認証の要求に基づいて第１のメッセージを生成し、第１のメッセージをユーザアプリケーションに提供することと、
    －ユーザアプリケーションが、ＩＤプロバイダから受信した第１のメッセージと第２のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから第２のユーザの認証を要求することと、
    －ＩＤプロバイダが、第２のユーザの認証の要求に基づいて第２のメッセージを生成し、第２のメッセージをユーザアプリケーションに提供することと
    を含む、請求項１６に記載の方法。
20. ユーザアプリケーションが、ＩＤプロバイダに認証を要求するステップが、更に、
    ユーザアプリケーションが、第２のメッセージと第３のユーザの一意のＩＤとに基づいて、ＩＤプロバイダから少なくとも第３のユーザの認証を要求し、それによりメッセージのチェーンを作成すること
    を含む、請求項１９に記載の方法。